Application programming interface for certificate management system

Abstract

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

Description

Technical Field

[0001] The present disclosure generally relates to systems, devices, and methods for securely generating and providing certain types of digital assets, such as security credentials and digital certificates. More specifically, the present disclosure relates to improved systems, devices, and methods for providing an application programming interface that enables secure configuration of digital assets in computerized devices and reduces or eliminates delays in configuring digital assets in computerized devices. Background Art

[0002] As computers become miniaturized and commoditized, manufacturers are producing a wider variety of devices that include any number of embedded computers and processors. The computer in a computerized device can control the device's operations; 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 connections that enable these devices to connect and exchange data via digital networks (including the Internet, cellular networks, and other wireless networks). Typically, each "thing" is uniquely identifiable by its embedded computing system and is able to interoperate within the existing Internet infrastructure. In the IoT sense, "things" can refer to a wide variety of computerized devices, such as household appliances, enterprise equipment used in commercial and enterprise environments, manufacturing machines, agricultural equipment, energy-consuming devices in homes and buildings (switches, power sockets, appliances, lighting systems, light bulbs, televisions, garage door openers, sprinkler systems, security systems, etc.), medical and healthcare equipment, infrastructure management equipment, robots, drones, and transportation equipment and vehicles.

[0004] In many examples, modern vehicles and transportation machinery (e.g., cars, trucks, aircraft, trains, boats, motorcycles, and scooters) contain several embedded processors or embedded computers in their subsystems and are computer-controlled in at least some aspects. Similarly, a growing number of modern transportation infrastructure devices (e.g., traffic lights, traffic cameras, traffic sensors, bridge monitors, and bridge control systems) contain at least one, and often multiple, embedded processors or embedded computer systems and are computer-controlled in at least some aspects. These computer-controlled elements of a transportation network typically communicate with each other, passing various types of information back and forth, and they can react, respond, change their operation, or otherwise rely on and use information received from or sent to other vehicles in vehicle-to-vehicle (V2V; also known as car-to-car (C2C)) communications and / or information received from or sent to infrastructure elements in vehicle-to-infrastructure (V2I; also known as car-to-infrastructure (C2I)) communications for safe, correct, efficient, and reliable operation. V2V and V2I systems together are often referred to as V2X systems or infrastructure. Specifically, if 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 a computerized device operate according to their software and / or firmware and data. To ensure secure and correct operation, the computerized device must be properly initialized and updated with the correct software, firmware, executable instructions, digital certificates (e.g., public key certificates), encryption keys, registration packages, pseudonym packages, etc. (hereinafter collectively referred to as "digital assets" or "software") as intended by the manufacturer, so that the IoT consists of devices executing authorized, known-good software and data. However, problems arise when unauthorized individuals or organizations (e.g., hackers) replace or change the software in the computerized device.

[0006] The onboard equipment (OBE) registration certificate acts as an OBE's passport, as it uses it to request other certificates—pseudonym and identity certificates. The authentication process authorizes the OBE to interface with the Secure Certificate Management Service (SCMS) and request the registration certificate during the bootstrapping process. Pseudonym certificates are short-lived and are primarily used for basic secure message authentication and misbehavior reporting. For privacy reasons, devices are given multiple certificates that are valid simultaneously, allowing them to change them frequently. The identity certificate used by the OBE is primarily used for authorization in V2I applications. An OBE only has one valid identity certificate for a given application at a time. The roadside unit (RSU) registration certificate acts as an RSU's passport, as it uses it to request application certificates. The authentication process authorizes the RSU to interface with the SCMS and request the registration certificate during the bootstrapping process. The application certificate used by the RSU is used to sign any transmitted wireless messages, such as signal phase and timing or traveler information messages. Because there are no privacy constraints on the RSU, the RSU only has one valid application certificate for a given application at a time. In general, certificates authorized by a registration certificate (including but not limited to pseudonym, identity, and application certificates) are classified as end-entity certificates. End-entity certificates are digital assets that authorize participation in certain ecosystems (e.g., V2X, C2C, or EV2G). When any type of end-entity certificate or collection of end-entity certificates is described throughout this document, they will be 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, as each computerized device is configured, conventional systems retrieve the digital assets of each computerized device from the external server. Any network connectivity issues can increase the time required to configure the computerized devices at the manufacturing facility. Furthermore, conventional systems use synchronous configuration techniques that can further increase the time required to configure the computerized devices.

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

[0009] As background, representational state transfer (REST) is an architectural style for designing networked applications that involves stateless transactions in a client-server configuration. RESTful applications use HTTP requests to publish data (create and / or update), read data (e.g., make queries), and delete data. The certificate management service (CMS) is used to register and configure on-board units (OBUs) and roadside units (RSUs) for the USDOT (United States Department of Transportation) vehicle to anything (V2X) infrastructure. IEEE 1609.2 is a standard that defines the secure message format and processing used by Wireless Access in Vehicular Environment (WAVE) devices, including methods for protecting WAVE management messages and methods for protecting application messages. IEEE 609.2 also describes the management functions necessary to support core security functions. X.509 is an internationally recognized standard for public key infrastructure systems that manages digital certificates, public key encryption, and secure communications with the Transport Layer Security (TLS) protocol. The system taught herein can support, for example, but not limited to, V2X, C2X (European standard), and EV2G. The system creates a registration request, and a REST API performs registration and initial configuration on behalf of the device, including polling the CMS to see if certificates are ready. The group readiness of client / end entity (EE) devices (e.g., a vehicle's OBU) can be determined, and the REST API enables management of downloaded ledgers (i.e., what certificates / registrations and configurations have been completed for a group of devices). In this specification, the term chips refers to any suitable hardware component within a computerized device to be configured, such as an on-board unit and a roadside unit. In some configurations, optional parameters of the chip, excluding the chip's own storage, are stored in off-chip storage (such as, but not limited to, flash storage), enabling registration and other certificates to be generated for the chip without storage.

[0010] In some implementations, a system for securely configuring at least one computerized device may include a certificate application programming interface (API) device, the 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 into the at least one computerized device, the digital assets comprising a registration package and an end-entity certificate package. In the context of the present teachings, secure communication refers to an encrypted communication channel in which one or more communicating entities are authenticated to the other communication channel. In some examples, the certificate API device is operable to receive a registration request for the at least one computerized device via an application programming interface (API), wherein the registration request enables vehicle-to-vehicle or vehicle-to-infrastructure communication. The certificate API device can be configured to generate a registration package for the at least one computerized device by obtaining the registration package from a certificate management service (CMS) via the API, and to generate an end-entity certificate package for the at least one computerized device by obtaining the end-entity certificate package from the CMS via the API. In addition, the credential API device can be configured to transmit the enrollment package and the end-entity credential package to the at least one computerized device via the API, the enrollment package and the end-entity credential package modifying the at least one computerized device to enable interchange of secure communications with the additional computerized device. The system can also include a CMS connected to the credential API device via a second secure communication channel and operable to provide the enrollment package and the end-entity credential package to the credential API device.

[0011] In some embodiments, the credential API device may be configured to receive a request for a computerized device status of at least one computerized device from a CMS via an API. The credential API device may also be configured to transmit a response to the request via the API, the response including metadata indicating whether a registration package for the at least one computerized device has been received from the CMS. In some examples, the credential API device is configured to receive a request for a registration status of a group of computerized devices from the CMS via the API, and transmit a response to the request via the API, the response including metadata indicating a 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 includes an electronic control unit of an automobile. In various implementations, the credential API device is configured to receive and retrieve an encapsulation or encryption key for matching the registration package and the application package in response to detecting that the at least one computerized device includes volatile memory. In some embodiments, the credential API device is configured to transmit the encapsulation key to the at least one computerized device. In some examples, the credential API device is configured to provide the registration package and the end-entity credential package to the at least one computerized device without requiring a connection to an external network.

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

[0014] In some embodiments, a method for securely configuring at least one computerized device may include receiving a registration request for the at least one computerized device via an application programming interface (API), wherein the registration request enables vehicle-to-vehicle or vehicle-to-infrastructure communication. The method may also include generating a registration package for the at least one computerized device by obtaining the registration package from a certificate management service (CMS) via the API, and generating an end-entity certificate package for the at least one computerized device by obtaining an end-entity certificate package from the CMS via the API. Furthermore, the method may include transmitting 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 interchangeable 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, in response to execution by a processor, cause the processor to: receive a registration request for at least one computerized device via an application programming interface (API), wherein the registration request enables vehicle-to-vehicle or vehicle-to-infrastructure communication. The plurality of computer-executable instructions may further cause the processor to: generate a registration package for the at least one computerized device by obtaining the registration package from a certificate management service (CMS) via the API, the registration package including one or more registration certificates. Furthermore, the plurality of computer-executable instructions may further cause the processor to: generate an end-entity certificate package for the at least one computerized device by obtaining an end-entity certificate package from the CMS via the API, the end-entity certificate package including one or more end-entity certificates. Furthermore, the plurality of computer-executable instructions may further 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 interchangeable secure communications with additional computerized devices. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0017] Figure 1 is a block diagram of an example operating environment for a credential management service, a credential API device, and a client device according to example embodiments described herein;

[0018] Figure 2 is a data flow diagram illustrating an example data flow between a client device, a credential API device, and a CMS according to example embodiments described herein;

[0019] Figure 3 is a process flow diagram of an example method for asynchronously transmitting an end-entity credential bundle to a plurality of computerized devices via a client device according to example embodiments described herein;

[0020] Figure 4 is a process flow diagram of an example method for asynchronously receiving registration bundles and credential bundles for a plurality of computerized devices via a client device according to example embodiments described herein; and

[0021] Figure 5 is a block diagram of an example of a computing system capable of hosting systems and methods according to example embodiments described herein. DETAILED DESCRIPTION

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

[0023] introduction

[0024] To ensure security and proper operation in the field, embedded devices (e.g., electronic control units (ECUs) used in vehicles) are initialized during the manufacturing process by configuring 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 plant that programs them into the ECUs are located in different geographical locations, often interconnected via unsecured internet communications. In the context of the present teachings, a secure channel is an encrypted communication channel in which one or more communicating entities are authenticated to the other communication channels. 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 modified by malicious parties or by accident. Often, different manufacturing plants and tenants (e.g., customers and clients) require different quantities of digital assets (e.g., digital certificate bundles of varying sizes). Therefore, to minimize manufacturing time, it is also desirable to minimize delays in providing these digital assets due to computing capacity bottlenecks or communication bandwidth limitations associated with large requests.

[0025] One of the shortcomings 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 the following technical problem: when a large request is made by a customer and received, subsequent requests that come to the certificate management system or service after the large request must wait for the large request to be completed before they are serviced. Traditional techniques for minimizing 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. The problem with this traditional approach is that allocating dedicated equipment is expensive, inefficient, and underutilizes computing resources and bandwidth because equipment dedicated to a given customer may be idle while other equipment dedicated to another customer is at maximum capacity. The systems, methods, and apparatus according to the present disclosure solve these and other problems of conventional certificate management systems and services, and can provide an effective multi-customer solution.

[0026] Configuration generally refers to the set of actions taken to prepare a computerized device with the appropriate data and software. It can also include the set of actions taken to correctly install the device in its operating environment, making it ready 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 appropriately customizing and configuring certain digital assets on the device (if necessary), which can be unique to each specific device. Actions can also include verifying that the computerized device is a legitimate device created by a legitimate device manufacturer and not a copy or counterfeit device.

[0027] Actions can also include correctly installing the device into its operating environment and testing it to verify that it operates correctly. The ability to securely configure only known-good devices is complicated by the fact that devices may be manufactured by one manufacturer and later installed into a larger system or device by another manufacturer. For example, an onboard unit (OBU) manufactured by a component manufacturer may be installed into a car manufactured by an automobile manufacturer. An improperly installed device may not operate correctly.

[0028] The techniques described in this article

[0029] 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 a software package from an external server or authentication management system, and provision of the software package 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 wait times for retrieving software packages and improve the efficiency of client devices installing 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 transfer rates, low download data transfer rates, and per-session upload / download limits (i.e., the total amount of megabytes or gigabytes that can be uploaded and / or downloaded during a network session). Device-specific information can be obtained in the early manufacturing stages, and then the required certificates can be calculated while the device is being manufactured, so that when the device reaches the end of the production line, the calculated certificate bundle is available for use with the device without delay. Thus, manufacturing pauses and delays caused by certificate preparation can be eliminated.

[0030] Disclosed herein are systems, methods, and devices for providing an application programming interface (API) that can fulfill requests from client devices to generate certain 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 certain 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 is capable of creating certificates for vehicle-to-vehicle and vehicle-to-infrastructure (V2X) devices, as well as car-to-car and car-to-infrastructure (C2X) devices. In various implementations, a system includes a certificate management device that implements asynchronous retrieval of digital assets requested by client devices. In some embodiments, the certificate management device is communicatively connected to the client device and to the CMS via any suitable network connection. The certificate management device may transmit a request to a certificate management service that generates certificates, such as enrollment certificates and end-entity certificates, in response to receiving a request for such certificates from a client device.

[0031] In various implementations, a 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 a plurality of clients, wherein each certificate request indicates a plurality of computerized devices that require a certificate along with their public keys for creating the certificate, a timestamp indicating when the certificate request was transmitted, and the specific client requesting the certificate. The API can transmit requests for certificates from one or more client devices to a 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 transmit the bundled digital assets to the client device to configure the computerized device. In some implementations, a group size corresponding to a subset of the plurality of computerized devices that require a certificate is tunable, having a default value of 1 or any other suitable value.

[0032] In some 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), wherein the OBU is configured to be installed in one or more of the following: a vehicle, a vessel (e.g., a ship), 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 the following: a vehicle, a vessel, 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 the following: a traffic control device, a pedestrian warning system, a wireless communication system or module, a digital billboard, and an electronic sign.

[0033] In some implementations, at least one client device, also referred to as a tester device, acts as a proxy between a certificate management service and at least one computerized device that requires a certificate. The tester device may be located at a manufacturer's location, such as a factory. According to such implementations, after the tester device receives the certificate from the certificate management service, the at least one computerized device may retrieve the certificate from the tester device. In other implementations, the plurality of clients may include at least one server that acts as a proxy between the certificate management service and the at least one computerized device that requires 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.

[0034] In another implementation, the API is a Representational State Transfer (REST) API or a Simple Object Access Protocol (SOAP), etc., and is operable to: receive certificate requests from multiple clients via a communication network; and transmit, on behalf of a certificate management service, enrollment certificates generated by an enrollment certificate authority of the certificate management service to the multiple clients via the communication network, wherein the certificate request includes a request for the enrollment certificate. According to some implementations, the API request also includes a request for an end-entity certificate, and the API is further operable to transmit, on behalf of the certificate management service, an end-entity certificate generated by the end-entity certificate authority of the certificate management service to the multiple clients via the communication network. According to some implementations, the enrollment certificate is a public key certificate that identifies the holder of the public key certificate as an authorized participant in an ecosystem including multiple computerized devices, and wherein each authorized participant in the ecosystem is capable of receiving 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 security-related instructions, location-related instructions, speed-related instructions, and direction or heading-related instructions.

[0035] 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 configuring digital assets (such as V2X certificates) within an end entity (EE), which is a type of computerized device. In some examples, each call to the service or API can be a synchronous HTTPS REST call that returns some immediate status or artifacts in JavaScript Object Notation (JSON) or any other suitable programming language. The configuration process of the present technology can be initiated using a registration request route with various options depending on the needs and constraints of the manufacturing process. In some implementations, to save time on the production line, this request can be made before initiating the manufacturing of the end entity. The request can still be made in real time, but this configuration process has the benefit of reducing latency on the line and ensuring that all required registration packages are ready to be downloaded locally. At any time, the status of a specific computerized device (e.g., a chipset or a single chip) can be requested to determine its readiness.

[0036] Initial registration requests can be made for individual chips or for a batch of chips. Either option allows status tracking via a group or batch identifier. Depending on the current load on the certificate management service (which is related to the number of initially configured assets (e.g., certificates)), the process of configuring a computerized device (such as an OBU) typically takes several minutes to complete. In various implementations, the entire registration and configuration process is a two-phase asynchronous process, where, for example, the registration certificate is retrieved in one phase and the end-entity certificate bundle is received in another phase. In another implementation, the basic EE assets required to create the registration certificate and the end-entity certificate are retrieved once, and then, at a later time, the registration and end-entity certificates are provided to the tester device via an API for programming. This flexibility allows for the time to generate and download the end-entity certificate bundle, but also allows for separate download locations for each phase. In some examples, if possible, a batch can be registered before manufacturing so that the configuration status can be guaranteed to be "READY" to reduce production line delays. Many options are available for downloading the final bundle, as the registration certificate injection and end-entity certificate configuration can occur at different locations. For example, the end-entity certificate can be downloaded at the OEM facility rather than at a Tier 1 site.

[0037] In this implementation, configuring the OBU pseudonym certificate from the certificate management service API can include collecting registration certificates and bootstrapping information, as well as configuring multiple weeks of anonymous pseudonym certificates. In different implementations, the API described herein abstracts the process from the device and makes individual requests on behalf of the device. The caller of the API (such as a client device) can monitor or poll the status of the chip request and, once completed, can download the final information bundle at once, rather than directly interacting with the CMS for all different downloads. The API conveniently bundles the boot and configuration information into two files that can be processed or decompressed by the client device and installed on the computerized device.

[0038] Figure 1 An example operating environment 100 is depicted, 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 a 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 one or more computing devices, etc. As shown, the client device 102 may submit a request for a certificate 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 some implementations, the computerized device 106 corresponds to one or more of the following: a vehicle, a vessel (e.g., a ship), 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 vessel, an aircraft, a spacecraft, a robot, a drone, a medical device, or an IoT device. Furthermore, for example, the computerized device 106 may correspond to an RSU of a vehicle control device (e.g., a traffic signal, a traffic light, or an electronic traffic sign), a digital billboard, a pedestrian alert system, a motorcycle sensor, a bicycle sensor, an electronic sign, a streetlight sensor, or a building warning sensor. In some embodiments, the client device 102 may be connected to the credential API device 108 via any suitable secure communication channel or secure transmission link. In some examples, the credential API device 108 may be connected to the CMS 104 via any suitable secure communication channel or secure transmission link.

[0039] In the operating environment 100, the credential API device 108 receives a request for a credential from the client device 102 via any suitable interface. For example, the credential API device 108 may implement an API based on a client presentation state transfer (REST) protocol or a simple object access protocol (SOAP). Figure 1 As shown, the certificate API device 108 can implement a public or private API, and the certificate management service 104 can be a V2X or C2X certificate management service. The certificate management service 104 accepts the request for the certificate, 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, depending on the processing power of the certificate management service 104, etc., the timeframe can be minutes, hours, or days.

[0040] In some embodiments, the credential management service 104 can return the result or generated credential to the computerized device 106 via the credential API device 108. For example, the computerized device 106 can receive code that enables the computerized device 106 to communicate directly with the credential 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 credential API device 108. In some embodiments, the computerized device 106 can communicate in a grid configuration, where the computerized device 106 acts as a client device 102 for additional downstream computerized devices 106.

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

[0042] In additional or alternative implementations, the components of the certificate management service 104 may vary depending on whether the certificate management service 104 is configured as a V2X or C2X certificate management service. For example, when the certificate management service 104 functions as a C2X certificate management service, the certificate management service 104 may include an Enrollment Authority (EA) configured to perform a role similar to that of the Enrollment Certificate Authority 114. Similarly, when the certificate management service 104 is embodied as a C2X certificate management service, the certificate management service 104 may include an Authorization Authority (AA) configured to perform 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.

[0043] In an example, the certificate management service 104 may be embodied as a CMS. Different implementations of the certificate management service 104 may be used for extremely high volume device transactions and certificate generation processing. In different implementations, the certificate management service 104 may be implemented using multiple servers, multiple hardware security modules (HSMs), multiple compute or compute engines, and multiple application platforms. In an example implementation, the application platforms may each include one or more virtual machines (VMs) for hosting a registration authority 112, a registration certificate authority 114, an end entity certificate authority 116, and link authorities 118 and 120. In additional or alternative implementations, the application platforms may each include one or more hardware platforms, such as, for example, an application server, a computer, or other computer hardware capable of hosting and executing software applications. Figure 1 In the example of , the application platform for registration certificate authority 114 may be one or more VMs running an application for registration certificate authority 114, and the application platform for end-entity certificate authority 116 may be one or more VMs operable to host and run an application for end-entity certificate authority 116. Similarly, the application platform for link authority 1 118 may be one or more VMs configured to host and run an application for link authority 1, and the application platform for link authority 2 120 may be one or more VMs operable to host and run an application for link authority 2. Non-limiting examples of certificate management service 104 may be implemented in a private data center, a cloud data center (such as, for example, Amazon Web Services (AWS) from Amazon), or in a hybrid of private and cloud data centers.

[0044] In some implementations, the certificate management service 104 can provide security certificates (e.g., registration certificates and end-entity certificates) for use by a manufacturer's tester device or a dealer appliance. In some implementations, the certificate management service 104 can interact with a digital asset management system (DAMS, not shown) to provide certificates to a dealer appliance (not shown) or the client device 102.

[0045] like Figure 1 As shown, the architecture of the certificate management service 104 includes an enrollment authority 112, a registration certificate authority 114, an end-entity certificate authority 116, a link authority 1 118, and a link authority 2 120. Each of these components can utilize a respective dedicated computing engine (not shown) to perform tasks. For example, the enrollment authority 112 can utilize the enrollment authority computing engine, the enrollment certificate authority 114 can utilize the enrollment certificate authority computing engine, the end-entity certificate authority 116 can utilize the end-entity certificate authority computing engine, the link authority 1 118 can utilize the link authority 1 computing engine, and the link authority 2 120 can utilize the link authority 2 computing engine. The functions of each of these components are described in the following paragraphs.

[0046] In some embodiments, the architecture of the certificate management service 104 advantageously separates non-security related applications from security functions. Figure 1 As shown in the example of , the registration authority 112, enrollment certificate authority 114, end-entity certificate authority 116, and chaining authorities 118, 120 are implemented as applications on their own VMs that execute on their own dedicated compute engines, all of which are separate from any non-security related applications and functions. This provides technical and security advantages and improvements over conventional systems where HSMs have slower performance, or where cloud service providers cannot provide HSMs, or where their proper management of HSMs is uncertain. In the certificate management service 104, cryptographic operations utilizing the HSMs are performed in a compute engine (e.g., one or more of the compute engines).

[0047] By separating critical safety functions from each other and onto separate computing engines, such as Figure 1As shown in , for example, computationally intensive cryptographic and security functions (e.g., elliptic curve butterfly extension computations or elliptic curve digital signatures) as performed by the enrollment authority 112, the enrollment certificate authority 114, the end-entity certificate authority 116, and the linking authorities 118, 120 are performed much faster than existing conventional similar systems. In combination with the certificate API device 108 described below, this design enables significant improvements in transaction processing in a multi-client environment by preventing any issues related to the network 110 from interfering with or delaying the configuration of digital assets retrieved from the certificate management system 104 or the client device 102 by the computerized device 106. The client device 102 can batch the raw data required for certificate creation and send that data to the certificate API device 108 to eliminate wait times / interruptions and allow accumulation of raw data from multiple sites at different times. For example, the client device 102 can retrieve or preload enrollment packages and end-entity certificate packages, etc. from the CMS 104. Thus, the credential API device 108 can provide the retrieved registration bundle and end-entity certificate bundle to the computerized device 106 during the configuration process without network delays that may exist between the credential API device 108 and the CMS 104. In some examples, the credential API device 108 can avoid bandwidth issues, network connectivity issues, etc. while configuring the computerized device 106. Furthermore, in some examples, the credential API device 108 can asynchronously retrieve the registration bundle and end-entity certificate bundle from the CMS 104 and asynchronously provide the registration bundle and end-entity certificate bundle to the computerized device 106. The asynchronous retrieval and distribution of the registration bundle and end-entity certificate bundle can further reduce the time of the configuration process for each computerized device. As such, implementations according to the present disclosure provide a particular technically advantageous system architecture for asynchronously providing and retrieving digital assets to and from a credential management system and bundling digital assets for the computerized device 106.

[0048] 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, and the secure compute capabilities of the registration authority compute engine may not need to be changed. Alternatively, if secure compute limits performance, additional secure registration authority compute engines can be added. This same multi-dimensional scaling is also true for other components of the certificate management service 104. These capabilities provide significant performance improvements and scalability over existing conventional certificate management services (CMS). In some implementations, the respective application platforms for the registration authority 112, registration certificate authority 114, end entity certificate authority 116, and link authorities 118, 120 are communicatively connected to the compute engines via respective sets of input message queues so that these components of the certificate management service 104 can all be scaled independently of each other.

[0049] As noted above and in Figure 1 As shown in the non-limiting example of FIG, each of the registration authority 112, the certificate authorities 114, 116, and the link authorities 118, 120 can be implemented as an application on its own VM. In an additional or alternative implementation, one or more of the registration authority 112, the certificate authorities 114, 116, and the link authorities 118, 120 can be executed on a hardware platform (e.g., a server or a compute engine). The roles and functions of each of these applications executed on the application platform (e.g., a VM or a hardware platform) are described in the following paragraphs.

[0050] In various implementations, the registration authority 112 may be an authority in a configuration network that verifies user requests for digital certificates or other types of digital security assets and enables certificate authorities (e.g., registration certificate authority 114 and end-entity certificate authority 116) to issue digital certificates. In various implementations, the registration authority 112 may implement any suitable public key infrastructure (PKI) technology. In various implementations, the certificate API device 108 may pass the certificate request to the registration authority 112, which may be implemented as a presentation state transfer (REST) web service or a SOAP-based service, among others. In various implementations, there may be multiple instances of the registration authority 112 executing simultaneously. This is similarly represented as Figure 1 . The registration authority functionality of the certificate management service 104 is decentralized in that its functionality can be performed by multiple instances of a registration authority 112 implemented as a REST web service. The 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 authority 116 and chaining authorities 118, 120 via any secure communication channel, including, for example, but not limited to, a message queue, to fulfill its role within the certificate management service 104.

[0051] In some implementations, the registration authority 112 (and Figure 1The certificate management service 104 may utilize a data store or a collection of databases for data storage and retrieval. For example, the database used may be composed of one or more database logical or physical units, each having one or more tables to implement data separation where necessary. As used herein, the term "database" refers to one or more databases or data stores. In some implementations, the use of multiple databases may allow the registration authority 112 to communicate with multiple databases. Figure 1 For example, such use of multiple databases allows for data separation between the enrollment authority 112, the certificate authorities 114, 116, and the link authorities 118, 120.

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

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

[0054] The end entity certificate authority 116 is a non-central component of the CMS because there may be multiple instances of the end entity certificate authority 116 executing simultaneously. For the end entity certificate authority 116, in different implementations, there may be multiple instances of the end entity certificate authority 116 executing simultaneously in parallel. The end entity certificate authority 116 can receive requests for end entity certificates from the enrollment authority 112. The role of the end entity certificate authority 116 is to fulfill requests from the enrollment authority 112 to issue end entity certificates to end user devices (such as, for example, the computerized device 106). In certain implementations, the end entity certificate authority 116 fulfills requests for short-term end entity certificates to implement V2V functionality. In some embodiments, the end entity certificate authority 116 interacts directly with the enrollment authority 112 in order to perform its functions within the CMS 104.

[0055] In different implementations, Figure 1 The linking authorities 118, 120 shown in FIG. 1 link the identity of the certificate requester (i.e., the unique identifier of the device of the certificate requester) to the issued end-entity certificate for revocation purposes. That is, linking authority 1 118 and linking authority 2 120 provide the corresponding link value as the unique identifier of the device of the certificate requester to the issued end-entity certificate. Linking authority 1 118 and linking authority 2 120 can receive a request for the link value from the registration authority 112 and then provide the requested link value to the registration authority 112. The linking authorities 118, 120 interact directly with the registration authority 112 to fulfill the request for the link value.

[0056] In various implementations, the compute engines of CMS 104 may include an HSM, which allows these components to perform secure computations without undue risk from hackers. In some implementations, the compute engines may be designed to perform secure computations themselves without requiring an embedded HSM, in which case they implement an HSM.

[0057] In various implementations, different HSM versions can be used in CMS 104. For example, the HSM can include an embedded HSM installed as a plug-in card within one or more computing engines. In such example implementations, the embedded HSM can be installed in one or more of the computing engines as a Peripheral Component Interconnect (PCI) HSM or a PCI Express (PCIe) HSM. Additionally, for example, the HSM in certificate management service 104 can include an external, network-attached, or network-connected HSM that is separate from the computing engine in its own enclosure.

[0058] One of ordinary skill will recognize that Figure 1 The components and implementation details shown in the examples are presented for simplicity and clarity of explanation. Other components, processes, implementation details and variations may be used without departing from the principles of the technology described herein, as the examples are not intended to be limiting and many variations are possible.

[0059] Figure 2 is a block diagram of an example system for using an application programming interface to provide configuration information to a certificate management system and retrieve digital assets from the certificate management system. In some embodiments, the system 200 can be implemented with any suitable computing device, such as the client device 102, the certificate API device 108, and the above-mentioned Figure 1 Various computing devices of the certificate management system 104 are described.

[0060] In some embodiments, the client device 102 may transmit a registration request 202 to the certificate API device 108. The registration request may be transmitted using any suitable protocol, such as the POST (Post Office) protocol, etc. The request may be used to register a batch of computerized devices 106, such as airborne units, roadside units, etc. In some examples, the request to register a batch of computerized devices 106 may include various parameters. For example, the request may include a public key associated with each chip and a group identifier corresponding to a batch of chips to be configured with the digital asset. Chips as referred to herein may include any suitable hardware components within the computerized device to be configured, such as airborne units, roadside units, etc. The digital asset may include a registration package and an end-entity certificate package, etc. For computerized devices that cannot store / archive their own keys for future use, the digital asset may include a wrapping key for each chip. In some embodiments, the registration package may include any number of registration certificates, boot information, applications, firmware, etc. In some examples, the end-entity certificate package may include any number of end-entity certificates that enable the computerized device to communicate securely with additional computerized devices. Registration packages and end-entity certificate packages are described below with respect to Figure 3 and Figure 4 The request may also include the name of the chip manufacturer, the model number of the chip, and the name of the electronic control unit owner to determine which local policy file is included in the final configuration. The request may also include an array of roadside unit request information, which includes a public key and an optional encapsulation key. The encapsulation key may include any suitable encryption key stored within an encrypted data packet. In some embodiments, the client device 102 or computerized device 106 may decrypt the encrypted data packet and store the private encryption key from the encrypted data packet. In some embodiments, the request may include a slot number for the registration private key, a public registration seed key, a provider service identifier (PSID), and optional service-specific permission (SSP) parameters, such as, for example, but not limited to, a geographic region for which the certificate is created and a customer profile identifier included in the registration and end-entity certificates. The geographic region may include a specific rectangular area, a circular area, or a named area, such as a country code. The customer profile number may be used to manage configurable parameters for an entire customer base. The slot number corresponds to the location of the private key residing in the computerized device.

[0061] In different implementations, the PSID and SSP parameters may indicate messages that may be signed by the application. In some embodiments, the PSID is associated with an application specification that indicates how to generate an interoperable instance of the application. For example, the SSP parameters may indicate state-related permissions for the application, where the state-related permissions enable a specific subset of activities. In one example, the SSP parameters may provide additional permissions for a fire truck registration certificate or a pseudonym certificate, where the SSP parameters allow "signal priority", which may include sending a message to a traffic light to change the displayed light color. Non-emergency vehicles do not have the SSP parameters in their certificates and will not be granted this 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 may verify that the non-emergency vehicle does not have the correct SSP parameters and deny the request.

[0062] The credential API device 108 processes the registration request 202 and, in the event of an error, may return 206 any suitable error code to the client device 102, such as an internal server error or bad request. In the event of a successful request operation, the credential API device 108 may transmit 206 a confirmation of the successful request operation to the client device 102. As shown in this embodiment, the credential API device 108 may then transmit the registration request 204 (e.g., for a batch of computerized devices) to the credential management service 104. Also as shown in this example, in response, the CMS 104 creates the requested registration credentials (and possibly other digital assets) and sends them to the credential API device 108 as a response 218, which may store them at least temporarily. The credentials returned by the CMS 104 may contain other centrally managed data, such as the PSID / SSP required by the EE manufacturer.

[0063] In some embodiments, the credential API device 108 may store any number of registration packages and end-entity credential packages for the client device 102. Thus, the credential API device 108 may bundle digital assets or data packages to be transmitted to the client device 102. As the credential API device 108 receives a portion of each batch of requested data packages, the credential API device 108 may be queried by the client device 102 to determine the status of credential creation by the credential management system 104. For example, the client device 102 may transmit a status request 208 for information related to a single chip. The status request 208 may be processed by the credential API device 108 to determine the programmatic readiness of the registration credential package to be retrieved by the client device 102. In some examples, the status request 208 may include a unique chip identifier (e.g., Figure 2The status request returns, for example, the name of the chip manufacturer, the model number of the chip, a group identifier for a 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 can return a chip status 210 to the client device 102, indicating whether a registration certificate for the computerized device or chip configured by the client device 102, as specified in the status request 208, has been received from the CMS 104. The response 210 to the status request 208 can also include a public registration seed key, a slot number for the registration seed private key, a wrapping key, an indicator of a registration request or registration receipt, and a timestamp corresponding to when the registration certificate was received.

[0064] In some embodiments, the client device 102 may also transmit a group registration status request 212. The group registration status request may query the names of the computerized devices or chipsets that have registered with the credential API device 108. For each registration request 202, the corresponding group name (e.g., Figure 2 The group name may be, for example, a tape volume identifier corresponding to a group of chips delivered to an ECU manufacturer. In some examples, the group name may be an identifier for a chipset to determine configuration status and readiness on a larger scale. For example, the certificate API device 108 may process the group registration status request 212 to determine whether configuration data (e.g., registration packages and end-entity certificate packages) for a chip volume (e.g., an onboard unit group or a roadside unit group) is ready to be downloaded from the certificate API device 108. In some examples, the group registration status request 212 may be paged and sorted by upload time in descending order (e.g., newest first, oldest first, etc.). In some embodiments, the group registration status request 212 may also indicate descending or ascending order, a registration status indicator, and a request date. The registration status response 214 may indicate an array of names of groups having certificates that have been retrieved by the certificate API device 108, the current page of the group name list, and the total number of available pages.

[0065] In some embodiments, the client device 102 may transmit a request 216 to retrieve a registration package for a chip (e.g., specified by a chipid) or computerized device. In some examples, the request may be for any chip that has a registration package received status, such as that communicated to the client 102 in a chip status message or response 210 or a registration status response 214. For example, if the credential API device 108 has retrieved or otherwise obtained 218 a set of registration packages for chips or computerized devices from the CMS 104, the client device 102 may request the registration package 216. If an encapsulation key indicator, such as an encapsulation signing caterpillar key (SCK) indicator or an encapsulation encryption caterpillar key (ECK) indicator, is provided in the initial request, the binary values of these encapsulation encryption keys may be provided instead of slot numbers. The caterpillar key referred to herein is a seed key used for butterfly expansion to derive multiple signing and / or encryption keys on a device with limited memory based on the seed signing / encryption key and the butterfly expansion value. In some examples, a butterfly expansion algorithm can use the seed key and the butterfly expansion value along with an index representing a week and the index of overlapping credentials within that week. The computerized device 106 can then derive private signing and / or encryption keys from the Caterpillar key and match these keys with corresponding certificates generated by the CMS 104. The public key created by the CMS 104 and the private key derived on the computerized device 106 correspond to each other because the CMS 104 uses the same derivation algorithm and inputs to obtain the correct public key. In some embodiments, the keys derived from the ECK are used for encryption on the device. Conversely, the keys derived from the SCK are used to sign data and messages.

[0066] In some examples, detecting an encapsulated encryption key indicates the presence of a master key that encrypts the private ECK and SCK components of the key pair, rendering them inaccessible to 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), while storing other encryption keys on a separate, unsecured storage chip. In some embodiments, the private ECK and SCK components are stored in a "encapsulated" format or encrypted by a master key. When firmware running on the chip attempts to access the private ECK or SCK keys, the firmware can retrieve or obtain the "encapsulated" private key, decapsulate (decrypt) the encapsulated key into the chip's secure RAM memory, and instructions executed by the chip can then access the decrypted private SCK and / or ECK keys. If the chip loses power, the decrypted private SCK and / or ECK keys may be lost or deleted due to storage in volatile memory. In some examples, the master key is stored in a secure storage device, while the encapsulated private SCK and ECK keys are stored in an off-chip storage device.

[0067] In some embodiments, when providing the binary, the caller of the API can determine that the device does not have onboard storage attached when creating the key, and therefore, the caller of the API (e.g., client 102) can inject the wrapping key into the appropriate "slot" or storage device at load time.

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

[0069] In some embodiments, client device 102 may also request 222 retrieval of an end-entity certificate bundle for a computerized device (such as a chip). In some examples, request 222 may be for any chip with an end-entity certificate bundle received, such as the status of which has been communicated to client 102 in a chip status message or response 210. For example, if certificate API device 108 has already retrieved 218 an end-entity certificate bundle from CMS 104 (e.g., for a group of chips or computerized devices), client device 102 may request the end-entity certificate bundle. If encapsulation Sck and encapsulation Eck are provided in the initial request, the binary representation of these encapsulation keys may be provided instead of private seed key metadata, which may include an HSM slot number. When providing the encapsulation keys, assuming the computerized device does not have onboard storage attached when the keys are created, client device 102 may inject the encapsulation keys into the appropriate "slots" upon load. In response to request 222, certificate API device 108 may retrieve the local certificate chain file, 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 been downloaded or otherwise obtained from the CMS 104, the 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 the chip identifier string, which contains elements such as a hash identifier of the end entity certificate, a hash identifier of the configuration request, a download time, a download uniform resource locator (URL) and port number, a sign extension key, a binary response decryption extension key, and a response decryption private seed key metadata, which 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 using the algorithm type, the length of the HSM slot number, and the HSM specific slot number in binary. The response 224 may also include an initial provision of the end entity certificate for the chip and a zip file, which includes an encrypted certificate response from the registration authority device.

[0070] In some embodiments, the credential API device 108 can support any suitable number of additional requests. For example, the credential API device 108 can detect a request from the client device 102 for the number of total chip (onboard unit or roadside unit) groups and return a total count of unique groups that have been loaded by the credential API device 108. In some embodiments, the credential API device 108 can also request the number of unique chips or computerized devices that have been loaded via the API. The request can be made using a chip identifier, and in some instances, the response can indicate the total count of unique chips or computerized devices that have been loaded with registration packages and / or end-entity credential packages. In some examples, the request can include a group identifier, a list of chip identifiers associated with the group, a registration status indicator, a percentage of chips that are registered, a time of the request date, and the time when the last chip of the group was registered.

[0071] In some embodiments, if the computerized device is a roadside unit, the certificate API device 108 may support the different requests described above. The roadside unit may include any suitable sensor or IoT device, which may be installed in one or more of a traffic control device, a wireless communication module, a digital billboard, an electronic sign, etc. 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 valid issued certificates at any given time. For example, the number of currently valid issued certificates to be provided to the roadside unit may be limited to any suitable threshold, such as one, two, three, or any other value. This is different from an onboard unit (OBU) and its pseudonymous certificates, which are created redundantly for future time periods, where multiple valid certificates are for a given time period. In some instances, the certificate API device 108 may not support a request to receive an application package for a roadside unit.

[0072] It should be understood that Figure 2 is an example implementation of the technology described herein, and system 200 may include fewer or more components and devices in other implementations. For example, system 200 may include any number of client devices, multiple credential API devices, and any number of credential management systems. Furthermore, the credential API devices may support any number of requests related to retrieving digital assets such as enrollment bundles and end-entity credential bundles from the credential management system.

[0073] Figure 3 is a process flow diagram of an example method for asynchronously transmitting a registration package and an end-entity credential package to a plurality of computerized devices via a client device. Figure 1 and Figure 2 The certificate API device 108) is implemented.

[0074] At block 302, the credential API device 108 may receive, via an application programming interface (API), registration requests for any number of computerized devices 106. In some embodiments, the credential API device 108 may forward the registration requests to a credential management service (CMS) 104. In various implementations, the credential API device 108 may transmit, receive, and manage data using, for example, a Representational State Transfer (REST) protocol or a Simple Object Access Protocol (SOAP).

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

[0076] In some implementations, the registration request may indicate that registration packages and end-entity certificate packages for any number of chips or computerized devices 106 will be retrieved from the certificate management system 104. As described above, the registration package may include one or more registration certificates, boot data, firmware, applications to be installed, and encapsulated encryption keys. In some implementations, the registration package may be used to configure 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 applications installed on the computerized device to execute real-time instructions related to safety operations, speed modification operations, position modification 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 function. In some examples, the computerized device 106 may include an automobile's electronic control unit, an onboard unit, or a roadside unit. In some embodiments, the registration request includes a computerized device identifier corresponding to an externally accessible serial number of each computerized device 106. The computerized device identifier is discussed in more detail below with respect to block 304 .

[0077] At block 304, the credential API device 108 may receive, via the API, a request for a computerized device status for the computerized device 106. As mentioned herein, the computerized device status may indicate a status of retrieving a registration bundle and / or an end-entity credential bundle for the chip or computerized device 106. In some embodiments, the credential API device 108 may also transmit a response to the request, wherein the response includes metadata indicating whether the registration bundle and the end-entity credential bundle for the computerized device 106 have been retrieved from the CMS 104. The computerized device status enables a device (such as the client device 102 or the credential API device 108) to determine whether the registration bundle and the end-entity credential bundle have been received for a particular computerized device.

[0078] In some embodiments, the API described herein may perform requests based on a valid externally identifiable serial number as a chip identifier within each request. In some examples, the serial number may be used in subsequent function calls or requests to retrieve the state of the computerized device 106 and to retrieve registration and end-entity certificate packages. In some embodiments, the serial number may be an identifier that is retrieved from outside the device after manufacturing. The certificate API device 108 may store the serial number or identifier, which may be used in the event that the device is compromised or stolen. In some examples, the certificate management service 104 may subsequently determine the registration certificate of the compromised computerized device based on the serial number and perform operations to revoke and blacklist the compromised computerized device. For example, the certificate management service 104 may ignore or otherwise prevent responses to subsequent requests from the compromised computerized device.

[0079] In some examples, because the chip identifier can be used to uniquely identify registration and end-entity certificate bundle requests, multiple registration requests can be initiated for different applications. For situations where multiple registration bundles are requested, the caller (such as a client device or a certificate API device) can formulate the chip identifier parameter by using an external serial number followed by an underscore and a suffix to indicate separate requests. For example, if a client device requests two bundles of a registration bundle or end-entity certificate bundle for serial number 000-123456-EFD, the client device can perform two requests using the following chip identifier parameters: (1) 000-123456-EFD_0 and (2) 000-123456-EFD_1.

[0080] At block 306, the credential API device 108 may receive, via the API, a request for the registration status of a group of computerized devices 106. In some embodiments, the credential API device 108 may also transmit a response to the request, wherein the response includes metadata indicating a number of end-entity certificates (e.g., registration certificates, pseudonym certificates, registration bundles, or pseudonym bundles) received for the group of computerized devices 106. In some examples, the registration status may indicate to the client device 102 the number or percentage of registration bundles and end-entity certificate bundles that the credential API device 108 has received for the group of computerized devices 106. In some embodiments, the registration status may indicate to the client device 102 when the client device 102 may begin retrieving registration bundles and end-entity certificate bundles from the credential API device 108. For example, the credential API device 108 may retrieve available registration bundles and end-entity certificate bundles for the group of computerized devices 106 and individually bundle each registration bundle and each end-entity certificate bundle before distributing the bundled registration bundle and bundled end-entity certificate bundle to the client device 102.

[0081] At block 308, the certificate API device 108 may generate a registration package for each computerized device 106 via the API. As discussed above with respect to block 302, the registration package may include, among other things, boot data and a registration certificate. As mentioned herein, the boot data may include any number of software and / or firmware updates that enable the computerized device 106 to install an application to be executed. The registration package may also include any number of security credentials, digital certificates, encryption keys, and the like. In some embodiments, pre-retrieval of the registration package enables the client device 102 or the certificate API device 108 to configure the computerized device 106 prior to installing an end-entity certificate that enables runtime operations related to V2X communication. 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, and the like.

[0082] At block 310, the certificate API device 108 may generate an end-entity certificate bundle for each computerized device 106 via the API. In some embodiments, the end-entity certificate bundle 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 bundle may include at least one end-entity certificate that enables the computerized device 106 to execute runtime instructions using an application provided in the registration package. For example, the end-entity certificate may enable the computerized device 106 to execute an application that manages security instructions, position instructions, speed instructions, heading instructions, etc. In some embodiments, the end-entity certificate may enable the computerized device 106 in the V2X environment to identify and securely execute requests from additional non-compromised computerized devices 106.

[0083] At box 312, the certificate API device 108 can transmit the registration 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 can use asynchronous technology to transmit the registration package and the end-entity certificate package to the client device 102 or the computerized device 106. In some implementations, the registration package and the end-entity certificate package can modify each computerized device 106 to enable execution of configuration instructions and exchange secure communications with additional computerized devices. As mentioned herein, the configuration instructions can include installing applications and firmware, as well as storing registration certificates from the registration package, etc. In some embodiments, the computerized device 106 that has executed the configuration instructions can use the end-entity certificates from the end-entity certificate package to exchange secure communications with additional computerized devices. In different implementations, the secure communications can include requests for data related to the operating environment of the computerized device 106. For example, the secure communications can include requests for the location, speed, or progress of the computerized device, etc.

[0084] In some examples, the credential API device 108 can transmit or distribute the registration package to the group of computerized devices 106 via the client device 102 after retrieving the registration package from the credential management service 104. Similarly, the credential API device 108 can transmit or distribute the end-entity certificate bundle to the group of computerized devices 106 via the client device 102 after retrieving the end-entity certificate bundle from the credential management service 104. Asynchronous retrieval and bundling of the registration package and the end-entity certificate bundle can enable the credential API device 108 to configure the group of computerized devices 106 using the client device 102 even when network connectivity to the credential management service 104 is limited. In some examples, the credential API device 108 can enable the client device 102 to retrieve the registration package and the end-entity certificate bundle without connecting to an external network. For example, the credential API device 108 can preload the registration package and the end-entity certificate bundle for use in configuring the group of computerized devices. After the registration package and the end-entity certificate bundle are preloaded into the credential API device 108, the credential API device 108 can respond to registration requests even when not connected to the CMS 104. In some examples, the computerized device 106 is a roadside unit (RSU), and the certificate API device 108 enables the client device or computerized device 106 to retrieve the registration packet without retrieving the pseudonym packet. For example, the RSU device may use application certificates instead of pseudonym certificates to communicate with other devices. In the CMS system, pseudonym certificates may be created for OBUs using a default policy to provide any number of concurrent certificates per week, such as twenty concurrent certificates for up to 156 weeks, or any other suitable time period. In some embodiments, the default policy for application certificates is up to two application certificates at a time, or any other suitable number of application certificates at a time, with each application certificate valid for one week or any other time period. In some examples, application certificates are not linked to previous application certificates, while pseudonym certificates are linked using a Caterpillar key. Thus, a new key pair may be provided or obtained for each application certificate. Because the application certificate initially created for the RSU device may expire upon delivery, and the RSU device may be associated with an unknown latitude / longitude location, the RSU device may receive a registration certificate during configuration and later receive an application certificate in response to a request for the RSU device's application certificate.

[0085] Figure 3The process flow diagram of method 300 is not intended to indicate that the operations of method 300 are to be performed in any particular order, or that all operations of method 300 are included in every case. Furthermore, method 300 may include any suitable number of additional operations. For example, method 300 may also include retrieving a wrapping 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 wrapping key and transmitting the private key to computerized device 106.

[0086] Figure 4 is a process flow diagram of an example method for asynchronously receiving registration packets and terminal entity packets for multiple computerized devices via a client device. The method 400 can be implemented in any suitable computing device, such as Figure 1 and Figure 2 The client computing device 102.

[0087] At block 402, the client device 102 may transmit 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 communication. In various implementations, the registration request may correspond to any number of computerized devices 106 in a set of requesting registration packages and end-entity certificate packages.

[0088] At block 404, the client device 102 may transmit, via the API, a request for a computerized device status for the computerized device 106. As discussed above, the computerized device status may indicate whether a registration bundle or an end-entity credential bundle has been received from the CMS 104. In some examples, the client device 102 may transmit the request for the computerized device status to the credential API device 108. In some embodiments, the client device 102 may also receive a response to the request, the response including metadata indicating whether a registration bundle or an end-entity credential bundle for the computerized device 106 has been received from the CMS 104.

[0089] At block 406, the client device 102 may transmit a request via the API for the registration status of a group of computerized devices 106. Figure 3 As discussed in block 306 of FIGURE 3, the client device 102 may also receive a response to the request, wherein the response includes metadata indicating a number of certificates received for the plurality of computerized devices 106. For example, the response may include any number of received enrollment certificates, end-entity certificates, etc. In some embodiments, the metadata may also indicate whether a 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.

[0090] 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 bootstrapping data and bundled registration certificates, etc. As discussed above with respect to block 308, pre-retrieval of the registration package may enable the client device 102 or the certificate API device 108 to configure the computerized device 106 prior to installing an end-entity certificate that enables runtime operations related to V2X communication.

[0091] At block 410, the client device 102 may retrieve an end-entity certificate bundle for each computerized device 106 via the API. In some embodiments, the end-entity certificate bundle 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 the V2X environment to identify and securely execute requests from non-compromised computerized devices 106.

[0092] At block 412, the client device 102 may modify each computerized device 106 to enable secure transmissions with additional computerized devices using data from the enrollment package and the end-entity certificate package. For example, the client device 102 may transmit the enrollment package and the end-entity certificate package to the computerized device 106. Thus, the client device 102 may install applications, firmware, enrollment certificates, end-entity certificates, etc. on the computerized device 106, which may enable the computerized device 106 to execute real-time instructions in a secure vehicle-to-vehicle or vehicle-to-infrastructure environment.

[0093] Figure 4 The process flow diagram is not intended to indicate that the operations of method 400 will be performed in any particular order, or that all operations of method 400 will be included in every case. Furthermore, method 400 may include any suitable number of additional operations.

[0094] Figure 5 is a block diagram of an example of a computing environment 500 that includes a computing system 502 that can be used to implement systems and methods according to implementations of the present technology. Other components and / or devices can also be used. In some implementations, the computing system 502 can be used to implement, at least in part, Figure 1-Figure 2 , such as client device 102 or certificate API device 108. In some implementations, a series of computing systems similar to computing system 500 can each be customized with dedicated hardware and / or programmed as a dedicated server to implement Figure 1-Figure 2 One of the components, these components can communicate with each other via network 504.

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

[0096] CPU 506 may be one or more known processors or processing devices, such as the Intel FPGA IP Core processor from Santa Clara, CA. TM Core manufactured by the company TM family of microprocessors from AMD in Sunnyvale, CA TM Athlon manufactured by the company TM family of microprocessors. 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 implementation of the present technology. Storage device 514 may be a volatile or non-volatile, magnetic, semiconductor, tape, optical, or other type of storage device or computer-readable medium, including devices such as CDs (compact discs) and DVDs (Digital Video Discs) for long-term storage and solid-state devices. In some examples, storage device 514 may be any suitable non-transitory computer-readable medium. For example, a non-transitory computer-readable medium may contain computer-executable instructions that direct CPU 506 to perform operations of the technology described herein.

[0097] In the illustrated implementation, memory 508 contains one or more programs or applications 518 loaded from storage device 514 or from a remote system (not shown) that, when executed by CPU 506, perform various operations, procedures, processes, or methodologies consistent with the present technology. Alternatively, CPU 506 may execute one or more programs external to system 500. For example, system 500 may access one or more remote programs via network 504 that, when executed, perform functions and processes associated with implementations of the present technology.

[0098] In one implementation, memory 508 may include programs 518 for performing the specialized functions and operations described herein for client device 102 and / or credential 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 for the present technology.

[0099] The memory 508 may also be configured with other programs not related to the present technology (not shown) and / or an operating system (not shown) that, when executed by the CPU 506, performs several functions well known in the art. As an example, the operating system may be Microsoft Windows TM , Unix TM 、Linux TM 、Apple Computers TM operating system or other operating systems. The choice of operating system, or even the operating system used, is not critical to the present technology.

[0100] The HSM 512 can 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 (e.g., cryptographic keys) and other sensitive data from potential access by attackers. In some implementations, the HSM can be a chip, plug-in card, or board that is directly attached to the computing system 500.

[0101] The I / O device 510 may include one or more input / output devices that allow the system 500 to receive and / or transmit data. For example, the I / O device 510 may include one or more input devices, such as a keyboard, a touch screen, a mouse, etc., that enable a user to input data. Further, the I / O device 510 may include one or more output devices, such as a display screen, a CRT (Cathode Ray Tube) monitor, an LCD (Liquid Crystal Display) monitor, a plasma display, a printer, a speaker device, etc., that enable output or presentation of data to the user. The I / O device 510 may also include one or more digital and / or analog communication input / output devices that allow the computing system 500, for example, to communicate with other machines and devices digitally. Other configurations and / or multiple input and / or output devices may be incorporated into the I / O device 510.

[0102] In the illustrated implementation, the system 500 is connected to a network 504 (such as the Internet, a private network, a virtual private network, a cellular network, or other network, or a combination of these), which in turn can be connected to various systems and computing machines, such as servers, personal computers, laptops, client devices, etc. In general, the system 500 can input data from, and output data to, external machines and devices via the network 504.

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

[0104] Data source 516 may include one or more databases that store information and are accessed and / or managed by system 500. As an example, database 516 may be an Oracle TM Database, Sybase TM Databases, or other relational or non-relational databases. However, systems and methods consistent with the present technology are not limited to a single data structure or database, or even to the use of a database or data structure.

[0105] One of ordinary skill in the art will recognize that Figure 5 The components and implementation details of the systems in FIG. 5 are examples presented for simplicity and clarity of explanation. Other components and implementation details may be used.

[0106] Although the above examples use specific examples of computerized devices, such as OBUs, ECUs, and RSUs, for clarity of explanation, the present technology is not limited to those specific examples. Implementations consistent with the present technology can be used with and 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)).

[0107] Other embodiments of the 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 illustrative embodiments, as well as other embodiments of the subject matter, that are apparent to those skilled in the art to which the disclosed subject matter pertains are deemed to fall within the scope of the disclosed subject matter.

Claims

1. A system for securely configuring at least one computerized device, comprising: a credential 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 into the at least one computerized device, the digital assets comprising a registration package and an end-entity credential package, wherein the credential API device is further operable to: receiving, via the API, a registration request for the at least one computerized device, wherein the registration request facilitates vehicle-to-vehicle or vehicle-to-infrastructure communication; generating, via the API, the registration package for the at least one computerized device by transmitting at least one registration certificate request to a certificate management service (CMS), the CMS generating one or more registration certificates for the registration package; generating the end-entity certificate bundle for the at least one computerized device by transmitting, via the API, at least one end-entity certificate request to the CMS, the CMS generating one or more end-entity certificates for the end-entity certificate bundle; and transmitting, via the API, the registration package and the end-entity credential package to the at least one computerized device, wherein the registration package and the end-entity credential package are configured to modify the at least one computerized device to enable the at least one computerized device to exchange secure communications with an additional computerized device, wherein the CMS is connected to the certificate API device via a second secure communication channel, and The CMS provides the one or more registration certificates and the one or more terminal entity certificates to the certificate API device.

2. The system according to claim 1, wherein: The Credentials API facility is operable to: receiving, via the API, a request for a computerized device state of the at least one computerized device; and A response to the request is transmitted via the API, the response including metadata indicating whether a registration credential for the at least one computerized device has been received from the CMS.

3. The system according to claim 1 or 2, wherein: The Credentials API facility is operable to: receiving, via the API, a request for a registration status of a group of computerized devices; and A response to the request is transmitted via the API, the response including metadata indicating a number of enrollment certificates and end-entity certificates received for the group of computerized devices.

4. The system according to any one of claims 1 to 3, 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 according to any one of claims 1 to 4, wherein: The at least one computerized device comprises: an electronic control unit of an automobile.

6. The system according to any one of claims 1 to 5, wherein: The credential API device is operable to, in response to detecting that one of the at least one computerized devices includes volatile memory, receive and archive a wrapping key for a matching enrollment package.

7. The system according to claim 6, wherein: The credential API device is operable to retrieve and transmit the wrapping key with metadata such that the wrapping key is properly associated with one of the at least one computerized device.

8. The system according to any one of claims 1 to 7, wherein: The credential API device is operable to provide the enrollment bundle and the end-entity credential bundle to the at least one computerized device without requiring a connection to an external network.

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

10. The system according to claim 9, wherein: The roadside unit is a street light sensor or a building warning sensor.

11. The system according to any one of claims 1 to 10, wherein: The certificate API device is operable to generate the end-entity certificate bundle by bundling the one or more end-entity certificates retrieved from the CMS.

12. The system according to any one of claims 1 to 11, wherein: The credential API device is operable to generate the registration package by bundling the one or more registration certificates retrieved from the CMS.

13. A method for securely configuring at least one computerized device using digital assets, the digital assets comprising a registration bundle and an end-entity credential bundle, the method comprising: receiving, via an application programming interface (API), a registration request for the at least one computerized device, wherein the registration request facilitates vehicle-to-vehicle or vehicle-to-infrastructure communication; generating, via the API, the registration package for the at least one computerized device by transmitting at least one registration certificate request to a certificate management service (CMS), the CMS generating one or more registration certificates for the registration package; generating the end-entity certificate bundle for the at least one computerized device by transmitting, via the API, at least one end-entity certificate request to the CMS, the CMS generating one or more end-entity certificates for the end-entity certificate bundle; and transmitting the registration package and the end-entity credential package to the at least one computerized device via the API, wherein the registration package and the end-entity credential package are configured to modify the at least one computerized device to enable the at least one computerized device to exchange secure communications with additional computerized devices.

14. The method according to claim 13, comprising: Via the API, a computerized device status of the at least one computerized device is requested.

15. The method according to claim 13 or 14, comprising: Via the API, a registration status of a group of computerized devices is requested.

16. The method according to 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. The method according to any one of claims 13 to 16, wherein: The at least one computerized device comprises: an electronic control unit of an automobile.

18. The method according to any one of claims 13 to 17, comprising: In response to detecting that the at least one computerized device includes volatile memory, a wrapping key is retrieved.

19. The method according to claim 18, comprising: The wrapping key is transmitted to the at least one computerized device.

20. The method according to any one of claims 13 to 19, comprising: The registration bundle and the end-entity credential bundle are retrieved without requiring a connection to an external network.

21. One or more non-transitory computer-readable media comprising a plurality of computer-executable instructions for an application programming interface (API), the API utilizing digital assets comprising a registration package and an end-entity credential package, wherein: The plurality of computer executable instructions, when executed by a processor, causes the processor to: receiving, via the API, a registration request for at least one computerized device, wherein the registration request facilitates vehicle-to-vehicle or vehicle-to-infrastructure communication; generating, via the API, the registration package for the at least one computerized device by transmitting at least one registration certificate request to a certificate management service (CMS), the CMS generating one or more registration certificates for the registration package; generating the end-entity certificate bundle for the at least one computerized device by transmitting, via the API, at least one end-entity certificate request to the CMS, the CMS generating one or more end-entity certificates for the end-entity certificate bundle; and The registration package and the end-entity credential package are asynchronously transmitted to the at least one computerized device via the API, wherein the registration package and the end-entity credential package are configured to modify the at least one computerized device to enable the at least one computerized device to exchange secure communications with additional computerized devices.

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 bundle and the end-entity credentials bundle to the at least one computerized device without requiring a connection to an external network.

23. One or more non-transitory computer-readable media according to any one of claims 21 or 22, wherein: The plurality of computer-executable instructions cause the processor to: A request for a computerized device state of the at least one computerized device is received via the API.

24. One or more non-transitory computer-readable media according to any one of claims 21-23, wherein: The plurality of computer-executable instructions cause the processor to: A request for a registration status of a group of computerized devices is received via the API.

25. One or more non-transitory computer-readable media according to any one of claims 21-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. One or more non-transitory computer-readable media according to any one of claims 21-25, wherein: The at least one computerized device comprises: an electronic control unit of an automobile.

27. One or more non-transitory computer-readable media according to any one of claims 21-26, wherein: The plurality of computer-executable instructions cause the processor to: A wrapping key of the at least one computerized device is obtained, the at least one computerized device including volatile memory.

28. The one or more non-transitory computer-readable media of claim 27, wherein: The plurality of computer-executable instructions cause the processor to: The wrapping key is transmitted to the at least one computerized device.

29. One or more non-transitory computer-readable media according to any one of claims 21-28, wherein: The plurality of computer-executable instructions cause the processor to: The registration package and the end-entity certificate package are provided without requiring a connection to an external network.

30. One or more non-transitory computer-readable media according to any one of claims 21-29, wherein: The plurality of computer-executable instructions cause the processor to: The registration package is generated by bundling the one or more registration certificates.

31. A system for securely configuring at least one computerized device, comprising: a credential 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 into the at least one computerized device, wherein the credential API device is further operable to: receiving, via the API, a registration request for the at least one computerized device; generating, via the API, a registration package for the at least one computerized device by transmitting at least one registration certificate request to a certificate management service (CMS), and receiving one or more registration certificates of the registration package from the CMS, wherein the CMS is connected to the certificate API device via a second secure communication channel; and transmitting, via the API, the registration package to the at least one computerized device, wherein the registration package is operable to modify the at least one computerized device, wherein the registration package facilitates the exchange of secure communications between the at least one computerized device and the additional computerized device.

32. The system of claim 31, wherein: The Credentials API facility is operable to: generating, via the API, an end-entity credential bundle for the at least one computerized device, the end-entity credential bundle comprising one or more end-entity certificates retrieved from the CMS; as well as transmitting, via the API, the end-entity credentials package to the at least one computerized device, wherein the end-entity credentials package is operable to modify the at least one computerized device, The end-entity credential package facilitates the exchange of secure communications between the at least one computerized device and the additional computerized device.

33. The system of claim 31 or 32, wherein: The credential API device is operable to provide the enrollment bundle and the end-entity credential bundle to the at least one computerized device without requiring a connection to an external network.

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

35. The system according to any one of claims 31 to 34, wherein: The Credentials API facility is operable to: receiving, via the API, a request for a computerized device state of the at least one computerized device; and A response to the request is transmitted via the API, the response including metadata indicating whether a registration credential for the at least one computerized device has been received from the CMS.

36. The system according to any one of claims 31 to 35, wherein: The Credentials API facility is operable to: receiving, via the API, a request for a registration status of a group of computerized devices; and A response to the request is transmitted via the API, the response including metadata indicating a number of enrollment certificates and end-entity certificates received for the group of computerized devices.

37. The system according to any one of claims 31 to 36, wherein: The Credentials API facility is operable to: The pseudonymous packet is transmitted to the at least one computerized device via the API.

38. The system according to 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. The system according to any one of claims 31 to 38, wherein: The at least one computerized device comprises: an electronic control unit of an automobile.

40. The system according to any one of claims 31 to 39, wherein: The credential API device is operable to receive and archive a wrapping key for a matching enrollment package in response to detecting that one of the at least one computerized devices includes volatile memory.

41. The system of claim 40, wherein: The credential API device is operable to retrieve and transmit the wrapping key with metadata such that the wrapping key is properly associated with one of the at least one computerized device.

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

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

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

45. A method for securely configuring at least one computerized device using a digital asset, the method comprising: receiving, via an application programming interface (API), a registration request for the at least one computerized device, wherein the registration request facilitates communication between computerized devices; generating, via the API, a registration package for the at least one computerized device; and The registration package is transmitted to the at least one computerized device via the API, wherein the registration package is operable to modify the at least one computerized device, wherein the modification to the at least one computerized device facilitates the interchange of secure communications between the at least one computerized device and an additional computerized device.

46. The method of claim 45, further comprising: generating, via the API, an end-entity credential bundle for the at least one computerized device, the end-entity credential bundle comprising: one or more end-entity certificates retrieved from a certificate management service CMS via the API; and The end-entity credential package is transmitted to the at least one computerized device via the API, wherein the end-entity credential package is operable to modify the at least one computerized device, wherein the modification to the at least one computerized device enables secure communications to be interchanged between the at least one computerized device and an additional computerized device.

47. The method according to claim 45 or 46, comprising: When the at least one computerized device includes volatile memory, a wrapping key is retrieved from the CMS.

48. The method of claim 47, comprising: The wrapping key is transmitted to the at least one computerized device.

49. The method according to any one of claims 45 to 48, comprising: The at least one computerized device is enabled to retrieve the enrollment bundle and the end-entity credentials bundle without requiring a connection to an external network.

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

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

52. The method according to 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. The method according to any one of claims 45 to 52, wherein: The at least one computerized device comprises: an electronic control unit of an automobile.

54. One or more non-transitory computer-readable media comprising a plurality of computer-executable instructions for an application programming interface (API), the API utilizing a digital asset, wherein: The plurality of computer executable instructions, when executed by a processor, causes the processor to: receiving, via the API, a registration request for at least one computerized device, wherein the registration request facilitates communication between computerized devices; generating, via the API, a registration package for the at least one computerized device by transmitting at least one registration certificate request to a certificate management service (CMS), and receiving one or more registration certificates of the registration package from the CMS; and The registration package is transmitted to the at least one computerized device via the API, wherein the registration package is operable to modify the at least one computerized device, wherein the registration package facilitates the exchange of secure communications between the at least one computerized device and an additional computerized device.

55. The one or more non-transitory computer-readable media of claim 54, wherein: The plurality of computer-executable instructions, when executed by the processor, cause the processor to: generating, via the API, an end-entity credential bundle for the at least one computerized device, the end-entity credential bundle comprising: one or more end-entity credentials retrieved from the CMS via the API; and The end-entity credential package is transmitted to the at least one computerized device via the API, wherein the end-entity credential package is operable to modify the at least one computerized device, wherein the end-entity credential package facilitates the exchange of secure communications between the at least one computerized device and an additional computerized device.

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 bundle and the end-entity credentials bundle to the at least one computerized device without requiring a connection to an external network.

57. The one or more non-transitory computer-readable media of claim 55, wherein: The plurality of computer-executable instructions, when executed, cause the processor to: The registration package and the end-entity certificate package are provided without requiring a connection to an external network.

58. One or more non-transitory computer-readable media according to any one of claims 54-57, wherein: The plurality of computer-executable instructions cause the processor to: A request for a computerized device state of the at least one computerized device is received via the API.

59. One or more non-transitory computer-readable media according to any one of claims 54-58, wherein: The plurality of computer-executable instructions cause the processor to: A request is received via the API for a registration status of a group of computerized devices.

60. One or more non-transitory computer-readable media according to any one of claims 54-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. One or more non-transitory computer-readable media according to any one of claims 54-60, wherein: The at least one computerized device comprises: an electronic control unit of an automobile.

62. One or more non-transitory computer-readable media according to any one of claims 54-61, wherein: The plurality of computer-executable instructions cause the processor to: A wrapping key of the at least one computerized device is obtained, the at least one computerized device including volatile memory.

63. The one or more non-transitory computer-readable media of claim 62, wherein: The plurality of computer-executable instructions cause the processor to: The wrapping key is transmitted to the at least one computerized device.

64. One or more non-transitory computer-readable media according to any one of claims 54-63, wherein: The plurality of computer-executable instructions cause the processor to: The registration package is generated by bundling the one or more registration certificates.

65. One or more non-transitory computer-readable media according to any one of claims 54-64, wherein: The plurality of computer-executable instructions cause the processor to: The registration package is generated by obtaining the registration package from the CMS.

Images