Providing Quality of Service for Certificate Management Systems

Abstract

To provide a system and a method for providing a Quality of Service (QoS) level while safely provisioning digital assets in computerized devices.SOLUTION: A system 900 includes a QoS manager 901 that: distributes requests from clients across client queues, each of which corresponding to a particular client; and divides the requests into smaller subgroups of entries corresponding to a subset of computerized devices needing certificates. It also includes a QoS arbiter 904 that selects a sequence of entries from the client queues to be placed onto a QoS queue based on the number of entries in the QoS queue, a latency level of a certificate management service, and timestamps indicating when the requests were transmitted, where the QoS manager retrieves entries from the QoS queue in the sequence selected by the QoS arbiter and transmits them to the certificate management service 980.SELECTED DRAWING: Figure 9

Description

[Technical Field]

[0001] The present invention relates to systems, devices, and methods for securely generating and provisioning certain types of digital assets, such as security credentials and digital certificates. More particularly, the present invention relates to improved systems, methods, and techniques for providing Quality of Service (QoS) levels while securely provisioning digital assets on computerized devices to reduce or eliminate delays in provisioning of digital assets on computerized devices. [Background technology]

[0002] As computers become increasingly miniaturized and commoditized, manufacturers are producing an ever-increasing variety of devices that contain one or more embedded computers or processors. The computer within a computerized device can, among other things, control the device's operation; 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 that contain embedded processors, electronics, software, data, sensors, actuators, and / or network connectivity, enabling these devices to connect and exchange data over digital networks, including the Internet, cellular networks, and other wireless networks. Typically, each "thing" is uniquely identifiable through its embedded computing system and can interoperate within the existing Internet infrastructure.

[0004] "Things" in the IoT sense can refer to a variety of computerized devices such as home appliances, enterprise devices used in business and corporate environments, manufacturing machinery, agricultural equipment, energy-consuming devices in homes and buildings (such as switches, outlets, appliances, lighting systems, light bulbs, televisions, garage door openers, sprinkler systems, security systems), medical and healthcare equipment, infrastructure management equipment, robots, drones, and transportation equipment and vehicles, among others.

[0005] For example, most, if not all, modern vehicles and transportation machines (e.g., automobiles, trucks, airplanes, trains, ships, motorcycles, scooters, etc.) contain several embedded processors or embedded computers within their subsystems and are computer-controlled in at least some aspects. Similarly, an increasing number of modern transportation infrastructure devices (e.g., traffic lights, traffic cameras, traffic sensors, bridge monitors, bridge control systems, etc.) contain at least one, and often many, embedded processors or embedded computer systems and are computer-controlled in at least some aspects. These computer-controlled elements of transportation networks typically communicate with each other to exchange various types of information, and for safe, correct, efficient, and reliable operation, they can react, respond, modify their operation, or rely on information received / sent between other vehicles in vehicle-to-vehicle (V2V, also known as vehicle-to-computer (C2C)) communication and / or between infrastructure elements in vehicle-to-infrastructure (V2I, also known as vehicle-to-infrastructure (C2I)) communication.

[0006] The computers within computerized equipment operate according to their software and / or firmware and data. To ensure safe and proper operation, computerized equipment must be operated with the appropriate software and / or firmware as intended by the manufacturer. The IoT consists of only devices running authorized, working software and data, because the software must be properly initialized and updated with firmware, executable instructions, digital certificates (e.g., public key certificates), and cryptographic keys (collectively referred to below as "digital assets" or "software"). However, problems arise when unauthorized individuals or organizations (e.g., hackers) replace or modify software within computerized devices. Problems also arise when outdated, untested, unauthorized, and / or software with known bugs is installed within computerized devices.

[0007] In the fields of computer networking, packet-switched networks, and telecommunications, quality of service (QoS) refers to a set of technologies and techniques designed to provide improved service to selected users, customers, client devices, or network traffic. The goal of QoS is to guarantee the performance of a service or network. QoS metrics can include delay, availability, latency, bandwidth, upload data rate, download data rate, and per-session upload / download limits (i.e., the total number of megabytes or gigabytes that can be uploaded or downloaded during a network session). A service or network can assign different QoS levels to different users and client devices. QoS can also guarantee a certain level of performance to a user or client device according to a request from an application program. QoS guarantees are important when computing or network capacity is limited or when the requests being made are latency-sensitive.

[0008] Therefore, it is desirable to provide improved systems, methods, and techniques for providing QoS levels while securely provisioning digital assets within computerized equipment, such as IoT devices, vehicles, and transportation infrastructure equipment, to reduce or eliminate delays in provisioning digital assets within computerized equipment. Summary of the Invention

[0009] Disclosed herein are systems, methods, and apparatus for providing QoS levels while fulfilling requests to generate certain types of digital assets, such as security credentials and digital certificates. In various embodiments, the systems, methods, and apparatus use a QoS manager to provide QoS levels to clients requesting certificates from a certificate management system (CMS). In some embodiments, the CMS hosts a certificate management service that accepts requests from the QoS manager to create and provide certain types of digital assets, such as security credentials and public key certificates. The QoS manager uses a QoS arbiter to create and manage QoS queues, allowing the CMS to appropriately manage distinct requests based on their specific QoS levels. In various embodiments, the certificate management service can create 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 embodiments, the system includes a QoS manager that provides QoS levels to clients submitting certificate requests. The QoS manager is communicatively coupled to a certificate management service that generates certificates, such as enrollment certificates and pseudonym certificates, in response to receiving certificate requests from the QoS manager.

[0010] As described further herein, the QoS manager manages intermediary client queues corresponding to tenants and provides QoS levels by using a QoS arbiter to select the order of entries from the client queues to be placed in the QoS queues, thereby enabling the certificate management service to provide multi-tenant (e.g., multi-client) operation. For example, customized workflows can be created and customized configurations can be managed at end entities via the entity management system.

[0011] In various embodiments, a system provides quality of service (QoS) levels to multiple clients (e.g., tenants or customers) requesting certificates from a certificate management service. The system includes a public application programming interface (API) operable to receive certificate requests from the multiple clients, each certificate request indicating the number of computerized devices requiring a certificate, a timestamp indicating when the certificate request was submitted, and the particular client requesting the certificate. The system also includes a QoS manager operable to distribute the certificate requests from the multiple clients to multiple intermediary client queues, each of the multiple client queues corresponding to a particular client requesting a certificate. The QoS manager is also operable to divide the certificate requests from the clients in the client queue into subgroups (i.e., smaller groups) of one or more entries, each of the one or more entries having a group size corresponding to a subset of the number of computerized devices requiring a certificate. The system further includes a QoS arbiter operable to select an order for entries from the multiple client queues to be placed in the QoS queue. The QoS arbiter selects an order of entries from the client queue based at least in part on the number of entries in the QoS queue, a latency level of the certificate management service, and respective timestamps indicating when the certificate requests were submitted. The QoS manager is further operable to retrieve the entries from the QoS queue in the order selected by the QoS arbiter and then send the retrieved entries to the certificate management service via an internal registration authority API of the certificate management service.

[0012] In some embodiments, the group size, which corresponds to a subset of the number of computerized devices requiring a certificate, is an adjustable number with a default value of one.

[0013] In certain embodiments, the computerized equipment corresponds to one or more on-board units (OBUs), electronic control units (ECUs), and roadside units (RSUs), where the OBUs are configured to be installed in one or more of a vehicle, a watercraft (e.g., a boat), an aircraft, a spacecraft, a medical device, a robot, a drone, a wireless or wired communication module, and an IoT device, the ECUs are configured to be installed in one or more of a vehicle, a watercraft, an aircraft, a spacecraft, a medical device, a robot, a drone, a wireless communication module, a wired communication module, and an IoT device, and the RSUs are configured to be installed in one or more of a traffic control device, a wireless communication module, a digital billboard, and an electronic sign.

[0014] In certain embodiments, the plurality of clients includes at least one distribution device that acts as a proxy between the certificate management service and at least one computerized device requiring a certificate. The distribution device may be located at a manufacturer's site, such as a factory. According to such embodiments, the at least one computerized device may obtain a certificate from the distribution device after the distribution device receives the certificate from the certificate management service. In additional embodiments, the plurality of clients includes at least one server that acts as a proxy between the certificate management service and at least one computerized device requiring a certificate. According to such embodiments, the at least one computerized device may obtain a certificate from the distribution device after the distribution device receives the certificate from the certificate management service. A computerized device can obtain a certificate from the server after the server receives the certificate from the certificate management service.

[0015] According to some embodiments, each certificate request further indicates a client priority level of the client sending the request, and the QoS arbiter is further operable to select an order of entries from the multiple client queues to be placed in the QoS queue based at least in part on the respective client priority levels indicated in the certificate request. According to some such embodiments, the QoS arbiter is further operable to dynamically reorder the order of entries to be placed in the QoS queue based at least in part on the respective client priority levels indicated in additional certificate requests received from additional clients. In some such embodiments, the client priority level for a client is based on a service tier associated with the client. According to some such embodiments, the service tier corresponds to one of a plurality of tiers ranging from a lowest service level to a highest service level. In some such embodiments, the service tier is an alphanumeric string or a number corresponding to one of the plurality of tiers.

[0016] In other embodiments, each certificate request further indicates a request urgency level associated with the request, and the QoS arbiter is operable to select an order of entries from the multiple client queues to be placed in the QoS queue based at least in part on the urgency of each request indicated in the certificate request. According to some such embodiments, the request urgency level of a certificate request is specified by a client submitting the certificate request. According to certain such embodiments, the request urgency level corresponds to one of a plurality of levels ranging from a least urgent option to a most urgent option. In some such embodiments, the request urgency level is an alphanumeric string or a number corresponding to one of the plurality of levels.

[0017] In yet another embodiment, the QoS arbiter is operable to use a round robin technique to select the order of entries from the multiple client queues to be placed in the QoS queue.

[0018] In yet another embodiment, the QoS arbiter is operable to select an order of entries from the multiple client queues to be placed in the QoS queue based on a dynamic priority assigned to each of the client queues, the respective dynamic priority assigned to each of the client queues being assigned by the QoS arbiter based at least in part on the number of entries in each of the client queues.

[0019] In additional embodiments, the public API is a Representational State Transfer (REST) ​​API operable to receive certificate requests from a plurality of clients over a communications network, the certificate requests including requests for enrollment certificates, and to transmit, on behalf of the certificate management service, to the plurality of clients over the communications network, enrollment certificates generated by a registration authority of the certificate management service. According to some such embodiments, the certificate requests further include requests for pseudonymous certificates, and the public REST API is further operable to transmit, on behalf of the certificate management service, to the plurality of clients over the communications network, the pseudonymous certificates generated by the pseudonymous authority of the certificate management service. According to some such embodiments, the enrollment certificates are public key certificates that identify the holder of the public key certificate as an authorized participant in an ecosystem that includes a plurality of computerized devices, and each authorized participant in the ecosystem is operable to communicate with the plurality of computerized devices. You may receive one or more pseudonymous certificates that allow you to trust your

[0020] In other embodiments, the QoS arbiter is further operable to dynamically reorder the order of entries placed in the QoS queue based at least in part on additional certificate requests received from additional clients.

[0021] In a particular embodiment, a computer-implemented method provides a quality of service (QoS) level to clients requesting certificates from a certificate management service. The computer-implemented method includes receiving certificate requests from a plurality of clients via a public application programming interface (API). Each certificate request indicates the number of computerized devices needing a certificate, a timestamp indicating when the certificate request was submitted, and a client identifier for the client requesting the certificate. In some embodiments, the client identifier may include one or more of a unique alphanumeric string, an authentication token, and client authentication information (e.g., a Transport Layer Security (TLS) certificate or other type of digital certificate). The method further includes distributing, by a QoS manager, the certificate requests from the plurality of clients into a plurality of intermediary client queues, each of the plurality of client queues corresponding to a particular client requesting the certificate. The method also includes dividing, by the QoS manager, the client requests into one or more subgroups (i.e., smaller groups) of entries, each of the one or more entries corresponding to a subset of the number of computerized devices needing the certificate. The method further includes selecting, by a QoS arbiter, an order for entries from the multiple client queues to be placed in the QoS queue based at least in part on the number of entries in the QoS queue, a latency level of the certificate management service, and respective timestamps indicating when the certificate requests were submitted. The method also includes retrieving, by a QoS manager, the entries from the QoS queues in the order selected by the QoS arbiter. The method further includes sending the retrieved entries to the certificate management service via an internal registration authority API of the certificate management service.

[0022] In some embodiments, the QoS manager is communicatively coupled to a CMS that hosts a certificate management service. In some embodiments, the CMS communicates with the QoS manager via calls to an internal application programming interface (API) of the certificate management service. The CMS is configured to securely provide certificates via the QoS manager in response to requests from multiple clients. In additional or alternative embodiments, the QoS manager may be hosted on the CMS.

[0023] In certain embodiments in which the QoS manager is operable to send requests for registration certificates on behalf of multiple clients to a registration authority of the CMS, the QoS manager may be further operable to reprioritize client queues or QoS queues before transmission to the registration authority. For example, the QoS manager may prioritize clients requesting certificates before transmitting the client's registration certificate requests to the registration authority.

[0024] In other embodiments, the registration certificate may be a public key certificate that identifies the owner of the public key certificate as an authorized participant in an ecosystem that includes multiple computerized devices, and each authorized participant in the ecosystem may be able to receive one or more pseudonymous certificates that enable communication with multiple computerized devices. [Brief explanation of the drawings]

[0025] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the present invention. , together with its description, serve to explain the principles of the present invention.

[0026] [Figure 1A] 1 is a first portion of a swimlane diagram illustrating an example process for securely providing authentication information, such as a certificate, consistent with embodiments of the present invention.

[0027] [Figure 1B]1 is a second portion of a swimlane diagram illustrating an example process for securely providing authentication information, such as a certificate, consistent with embodiments of the present invention.

[0028] [Figure 2] FIG. 1 is a block diagram of an exemplary operating environment for a certificate management service and a single client consistent with embodiments of the present invention.

[0029] [Figure 3] FIG. 2 is a data flow diagram illustrating an exemplary data flow between a single client and a CMS consistent with embodiments of the present invention.

[0030] [Figure 4] FIG. 2 is a block diagram of an exemplary certificate management service operating in a two-client environment consistent with embodiments of the present invention.

[0031] [Figure 5] FIG. 2 is a data flow diagram illustrating an exemplary data flow between two clients and a CMS consistent with embodiments of the present invention.

[0032] [Figure 6] FIG. 1 is a block diagram of an exemplary certificate management service operating in a multi-client environment, consistent with embodiments of the present invention.

[0033] [Figure 7] FIG. 2 is a data flow diagram illustrating an exemplary data flow between multiple clients and a CMS consistent with embodiments of the present invention.

[0034] [Figure 8] FIG. 2 is a block diagram of an exemplary certificate management service that uses a QoS manager to provide QoS levels to multiple clients, consistent with embodiments of the present invention.

[0035] [Figure 9]1 is a block diagram of an example system for implementing a QoS manager consistent with embodiments of the present invention.

[0036] [Figure 10] FIG. 2 is a data flow diagram illustrating an exemplary data flow between multiple clients and a certificate management system using a QoS manager, consistent with an embodiment of the present invention.

[0037] [Figure 11] FIG. 1 is a block diagram of an example computing system that can be used to host systems and methods consistent with embodiments of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0038] Reference will now be made in detail to various embodiments of the present invention, examples of which are illustrated in the accompanying drawings. Wherever convenient, the same reference numerals will be used throughout the drawings to refer to the same or like parts.

[0039] To ensure secure and proper operation in the field, embedded devices (e.g., electronic control units (ECUs) used in vehicles) need to be properly initialized during manufacturing by provisioning them with digital assets, such as security assets. Digital assets can include various digital certificates, cryptographic keys, unique identifiers, and software. In most cases, the CMS or certificate management service and the manufacturing plant that generate these digital assets are located in different geographic locations, and these locations are traditionally managed through insecure interfaces. They are interconnected via network communications. Therefore, it is desirable to create an end-to-end secure channel from the origin of these digital assets to the equipment so that the digital assets cannot be accessed or modified by malicious or accidental actors. Typically, different manufacturing plants and tenants (e.g., customers and clients) require different numbers of digital assets (e.g., different sized bundles of digital certificates). Therefore, it is also desirable to minimize delays in the delivery of these digital assets due to computational bottlenecks or communication bandwidth limitations associated with large requests.

[0040] Conventional certificate management systems (CMSs) and certificate management services have the disadvantage of issuing certificates on a first-come, first-served basis. This creates a technical problem when a large request is made and received by a customer; requests arriving at the certificate management system or service after the large request must wait for the large request to complete. Conventional 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 conventional approach is that allocating dedicated equipment is expensive and inefficient, contrasting with offering a multi-customer solution where equipment dedicated to a given customer sits idle while equipment dedicated to another customer is at full capacity. Systems, methods, and apparatus consistent with the present disclosure address these and other problems of conventional certificate management systems and services. An exemplary solution addresses these problems by employing a fairness method that allows multiple customers (e.g., clients) to submit overlapping or simultaneous certificate requests without starving any client.

[0041] Provisioning generally refers to a set of actions taken to prepare a computerized device with the appropriate data and software. It can also include a set of actions taken to properly install the device in its operating environment and make 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 (if necessary) properly customizing and configuring specific digital assets on the device that may be unique to each particular 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.

[0042] Actions can also include properly installing the equipment in its operating environment and testing it to verify that it is operating correctly. The ability to securely provision only equipment that has been verified as safe is complicated by the fact that equipment may be built by one manufacturer and later installed into a larger system or equipment by another (e.g., an on-board unit (OBU) made by a parts manufacturer may be installed in an automobile made by an automobile manufacturer). Improperly installed equipment may not function properly.

[0043] Various embodiments consistent with the present invention provide QoS levels for performing certificate requests as part of a secure provisioning workflow for computerized devices, including IoT devices. Such embodiments help prevent large certificate requests from some clients from creating bottlenecks or excessive delays at the expense of smaller requests from other clients.

[0044] Various embodiments consistent with the present invention include a QoS arbiter for efficiently fulfilling certificate requests as part of a secure provisioning and management platform. The QoS manager can also be used to split large certificate requests into smaller, more manageable portions that are placed in QoS queues, which can be offered as a service to equipment and system manufacturers.

[0045] 1A and 1B are swimlane diagrams illustrating an example process 100 for securely providing authentication information, such as certificates, consistent with embodiments of the present invention. In particular, the example process 100 illustrated in FIGS. 1A and 1B involves the exchange of requests and responses between CMS components to provide a certificate to a V2X device. However, the embodiments described herein are not limited to V2X devices, and the disclosed principles may be applied to other types of computerized and computer-controlled devices, such as C2X devices. That is, a CMS can host a certificate management service that functions as a V2X or C2X certificate management service. The example process 100 illustrated in FIGS. 1A and 1B provides a certificate to a V2X device. FIGS. 1A and 1B illustrate components of an example CMS in the context of a V2X flow of requests and responses.

[0046] In various embodiments, process 100 or some or all of the operations shown may be performed by code executing on a computing system (which may include one or more processors or one or more computing subsystems), by a hardware-only system, or by a system that is a hybrid of the two. As shown at the top of Figures 1A and 1B, the entities involved in process 100 include a manufacturer (not shown), a registration authority 120 at a CMS host (e.g., a CMS hosting a certificate management service), collaboration authorities 150, 160, a pseudonymous certificate authority 140, and distribution equipment 108 located at a registration certificate authority 130. In various embodiments, these entities may communicate with each other to perform tasks as part of process 100 for providing certificates, as described below and throughout this disclosure with respect to Figures 1A and 1B.

[0047] In particular embodiments, the CMS host may be a system that hosts a certificate management service. The CMS communicates with the QoS manager. In some embodiments, such communication occurs via calls to an internal application programming interface (API) of the certificate management service.

[0048] The CMS includes a registration authority 120, one or more cooperating authorities 150, 160, a pseudonymous certificate authority 140, and a registration certificate authority 130. An exemplary CMS may include one or more application platforms that run applications for the registration authority 120. These application platforms are communicatively connected to one or more computational engines that perform the cryptographic calculations required by the registration authority 120. The one or more application platforms may include one or more virtual machines (VMs) or one or more hardware platforms (e.g., servers, computers, or other computer hardware capable of hosting and running software applications). The CMS may also include one or more VMs that run the registration certificate authority 130 and are communicatively connected to one or more computational engines that perform the cryptographic calculations required by the registration certificate authority 130. The registration certificate authority 130 is operable to generate and conditionally transmit registration certificates to the registration authority 120. 1A and 1B may further include one or more VMs that execute applications for the pseudonymous certificate authority 140 and are communicatively connected to one or more computation engines that perform the cryptographic calculations required by the pseudonymous certificate authority 140. The pseudonymous certificate authority 140 is operable to generate and conditionally transmit pseudonymous certificates to the registration authority 120. The CMS host may also include one or more VMs that execute first and second coordinating stations 150, 160 and are communicatively connected to one or more computation engines that perform the cryptographic calculations required by the first and second coordinating stations 150, 160. The applications of each of the first and second coordinating stations 150, 160 generate and conditionally transmit a coordinating value to the registration authority 120. The device may be operable to transmit.

[0049] 1A and 1B may also include one or more application platforms that run applications for registration authority 120 and are communicatively connected to one or more computation engines that perform the cryptographic calculations required by registration authority 120. The CMS host may further include one or more application platforms that run applications for registration certificate authority 130 and are communicatively connected to one or more computation engines that perform the cryptographic calculations required by registration certificate authority 130, which may be operable to generate and conditionally send a registration certificate to registration authority 120. The CMS host may further include one or more application platforms that run applications for pseudonym certificate authority 140 and are communicatively connected to one or more computation engines that perform the cryptographic calculations required by pseudonym certificate authority 140, which may be operable to generate and conditionally send a pseudonym certificate to registration authority 120. Additionally, the CMS host may include one or more application platforms that execute applications for the first cooperating station 150 and are communicatively connected to one or more computation engines that perform cryptographic calculations required by the first cooperating station 150. Finally, the CMS host may also include one or more application platforms that execute applications for the second cooperating station 160 and are communicatively connected to one or more computation engines that perform cryptographic calculations required by the second cooperating station 160. The cooperating stations 150, 160 may be operable to generate and conditionally transmit a coordination value to the registration authority 120.

[0050] In yet other embodiments, registration authority 130 may be operable to generate a registration certificate in response to receiving a request for a registration certificate from registration authority 120, pseudonymous certificate authority 140 may be operable to generate a pseudonymous certificate in response to receiving a request for a pseudonymous certificate from registration authority 120, and first coordination station 150 and second coordination station 160 may be operable to generate a coordination value in response to receiving a request for a coordination value from registration authority 120. In alternative or additional embodiments, registration authority 130 may be operable to generate a registration certificate in response to receiving a request directly from a computerized device. That is, there are multiple ways to obtain a registration certificate, and the exemplary process 100 shown in Figures 1A and 1B is just one exemplary way.

[0051] As shown in the example of FIG. 1A , process 100 begins with registration-related operations 105-135. The primary role of registration authority 130 is to fulfill requests from registration authority 120 and issue registration certificates to end-user devices, such as distribution equipment 108. As described below with reference to the example registration-related operations 105-135 shown in FIG. 1A , registration authority 130 can interact directly with registration authority 120 to issue the requested registration certificate to distribution equipment 108. In additional or alternative embodiments, registration authority 130 can communicate directly with distribution equipment 108 operable to act as a proxy between a CMS hosting a certificate management service and a computerized device requiring a registration certificate, and with a server that acts as a proxy for the computerized device requiring a registration certificate and a client requesting a registration certificate. For example, registration authority 130 can communicate directly with distribution equipment 108 located at a manufacturer's site (e.g., a manufacturer's factory).

[0052] At 105, the manufacturer's distribution equipment 108 requests a registration certificate from the registration authority 120, which may then provision (e.g., be used by) the computerized device, and the request may identify the computerized device for which the registration certificate is intended. The request may, for example, be for a new computerized device (e.g., a new product ), a manufacturer's distribution device 108 requesting a registration certificate for the V2X ecosystem. The registration certificate is a public key certificate that identifies its holder as an authorized participant in an ecosystem (e.g., the U.S. Department of Transportation (USDOT) V2X ecosystem), in which all participants must share a valid registration certificate, and authorized participants can also receive pseudonymous certificates that enable devices to communicate and operate within the ecosystem (e.g., in the USDOT V2X ecosystem example, enable communication and operation between vehicles and roadside infrastructure).

[0053] At 110, a request for a registration certificate is received at registration authority 120 and then transmitted from registration authority 120 to registration authority 130. In various embodiments, this operation may involve registration authority 120 decrypting and verifying the request, including signature verification that checks the revocation status of the device (e.g., computerized device) for which the registration certificate is intended using a list of unauthorized devices (e.g., a blacklist), and determining whether the requester (e.g., distribution device 108) is authorized to request a registration certificate from registration authority 120. For example, operation 110 may include determining whether a user from the manufacturer is an authorized user (e.g., part of staff). In some embodiments, registration authority 120 may also determine at 110 whether the computerized device (e.g., product) is approved for use to receive the registration certificate. In some cases, a list of approved devices (e.g., a whitelist) may be provided by a regulatory authority and used by the provisioning controller to make this determination. After the request for the registration certificate is confirmed, the request is transmitted from registration authority 120 to registration authority 130. This request can be sent as a registration certificate generation request generated by registration authority 120 .

[0054] At 115, a request for a registration certificate is received at registration authority 130. In response to receiving the request, at 120, registration authority 130 generates the requested registration certificate and sends the generated registration certificate back to registration authority 120. At 125, the registration certificate is received at registration authority 120, which sends the registration certificate to distribution device 108 at 130. At 135, distribution device 108 receives the registration certificate. At this point, distribution device 108 can provision the registration certificate into the device so that the device can use it, and registration-related operations are complete.

[0055] Acts 140-199 relate to provisioning of pseudonymous certificates. In some embodiments, acts 140-199 for requesting, generating, and provisioning pseudonymous certificates include using a QoS manager (not shown in FIGS. 1A and 1B, but see QoS managers 801 and 901 in FIGS. 8 and 9) to provide QoS levels to multiple clients requesting pseudonymous certificates. At 140, distribution equipment 108 requests a pseudonymous certificate from registration authority 120. The pseudonymous certificate is provisioned to (e.g., used by) a computerized device, and the request can identify the computerized device to which the pseudonymous certificate is intended. The request can be, for example, a manufacturer's distribution equipment 108 requesting a pseudonymous certificate for a computerized device that previously received a registration certificate (e.g., a registered computerized device). The pseudonymous certificate request can include a client request for a certain amount of public key certificates (e.g., a week's worth, a month's worth, or a year's worth).

[0056] At 145, the request for the pseudonymous certificate is received at the registration authority 120, which then initiates provisioning of the pseudonymous certificate.

[0057] In operations 152 to 170, the cooperating stations 150 and 160 execute the request for the cooperation value. At 150, the registration authority 120 sends a request to the association authority 1 150 for a first set of association values ​​(LA1).

[0058] At 155, in response to receiving the request for the first set of coordination values, collaboration station 1 150 generates and / or transmits the first set of coordination values ​​to registration station 120. That is, collaboration station 1 150 may transmit a previously generated first set of coordination values ​​(i.e., pre-generated collaboration values), or if the values ​​are not pre-generated, collaboration station 1 150 may generate and then transmit the first set of coordination values. At 157, the first set of coordination values ​​is received at registration station 120. At 160, registration station 120 transmits a request for a second set of coordination values ​​(LA2) to collaboration station 2 160.

[0059] 1B , at 165, in response to receiving the request for the second set of coordination values, coordination station 2 160 generates and / or transmits the second set of coordination values ​​to registration station 120. In various embodiments, coordination station 2 160 may transmit a pre-generated second set of coordination values, or alternatively, coordination station 2 160 may generate and transmit the second set of coordination values. At 170, the second set of coordination values ​​is received at registration station 120.

[0060] 1A and 1B can link a certificate requester's identifier (i.e., a unique identifier of the certificate requester's device) to an issued pseudonymous certificate for revocation purposes. That is, collaboration station 1 150 and collaboration station 2 160 provide first and second sets of collaboration values, respectively, to the pseudonymous certificate issued by pseudonymous certificate authority 140 as the unique identifier of the certificate requester's device as part of process 100. Collaboration station 1 150 and collaboration station 2 160 receive requests for collaboration values ​​sent from registration authority 120 in operations 152 and 162 and provide the requested collaboration values ​​to registration authority 120 in operations 155 and 165.

[0061] 1B, at 175, registration authority 120 sends a request for a pseudonymous certificate to pseudonymous certificate authority 140. This request may be sent as a batch of pseudonymous certificate generation requests made by registration authority 120.

[0062] At 180, a request for a pseudonym certificate is received at pseudonym certificate authority 140. In response to receiving the request, at 185, pseudonym certificate authority 140 generates the requested pseudonym certificate and sends the generated pseudonym certificate back to registration authority 120. At 190, the pseudonym certificate is received at registration authority 120.

[0063] At 195, distribution equipment 108 may send multiple requests to registration authority 120 to inquire whether the requested pseudonymous certificate is ready (i.e., generated and available). In particular embodiments, the query of operation 195 may be sent at any time after the request for the pseudonymous certificate is sent at operation 142. For example, after sending the request for the pseudonymous certificate to registration authority 120 at operation 142, distribution equipment 108 may periodically send queries to registration authority 120 to determine whether the requested pseudonymous certificate has been read. In this example, one or more of the queries of operation 195 may be sent in parallel with operations 145-190 (i.e., while the pseudonymous certificate is being generated).

[0064] At 198, once the pseudonym certificate is ready, the registration authority 120 sends the pseudonym certificate to the distribution device 108. At 199, the distribution device 108 receives the pseudonym certificate. At this point, the distribution device 108 can provision the pseudonym certificate to the device so that the device can use the pseudonym certificate, and the operations for provisioning the pseudonym certificate are complete.

[0065] In additional or alternative embodiments, a process similar to process 100 described above can be used to provide credentials to other computerized devices, such as C2X devices. For example, a CMS with components similar to those shown in FIGS. 1A and 1B can provide credentials to one or more on-board units (OBUs), electronic control units (ECUs), or roadside units (RSUs). Such OBUs and ECUs can be configured to be installed in vehicles, watercraft (e.g., boats), aircraft (e.g., airplanes and drones), spacecraft, medical devices, robots, wireless or wired communication modules, and IoT devices. Similarly, RSUs can be installed in traffic control devices (e.g., traffic signals), digital signage devices, and digital display devices (e.g., electronic billboards).

[0066] It should be appreciated that the QoS manager, QoS arbiter, and QoS queues described herein with respect to Figures 2-9 can be used to provide QoS levels to clients requesting certificates in the V2X context as well as the C2X context.

[0067] FIG. 2 illustrates an exemplary operating environment 200 in which a single client 202 interacts with a certificate management service 280. In some embodiments, the certificate management service 280 may be a V2X certificate management service. In additional or alternative embodiments, the certificate management service 280 may be a C2X certificate management service. As illustrated, the client 202 may send certificate requests to one or more computerized devices over a network 235. In the example of FIG. 2, the network 235 is the Internet. In particular embodiments, the computerized device corresponds to one or more of a vehicle, a watercraft (e.g., a boat), an aircraft, a spacecraft, a medical device, a robot, a drone, a wireless or wired communication module, and an IoT device. For example, the computerized device may correspond to an OBU or ECU of the vehicle, watercraft, aircraft, spacecraft, robot, drone, medical device, or IoT device. Also, for example, the computerized device may correspond to an RSU of a traffic control device (e.g., a traffic light, a traffic signal, or an electronic traffic sign), a digital billboard, or an electronic sign.

[0068] In operating environment 200, a certificate request is received by a client representational state transfer (REST) ​​API 205 of certificate management service 280. As shown in FIG. 2, client REST API 205 can be a public API, and certificate management service 280 can be a V2X or C2X certificate management service. Certificate management service 280 accepts the certificate request, completes the task within a timeframe, and then returns the result (e.g., the generated certificate) to client 202 over network 235. In some embodiments, the timeframe can be minutes, hours, or days, depending on the processing capabilities of certificate management service 280.

[0069] Certificate management service 280 includes components for generating requested certificates. In the example of Figure 2, these components include registration authority 220, registration certificate authority 230, pseudonym certificate authority 240, cooperation authority 1 250, and cooperation authority 2 260.

[0070] In additional or alternative embodiments, the components of certificate management service 280 may differ depending on whether certificate management service 280 is configured as a V2X or C2X certificate management service. For example, when certificate management service 280 functions as a C2X certificate management service, certificate management service 280 may include a Long Term Certificate Authority (LTCA) configured to fulfill a role similar to that of registration certificate authority 230. Similarly, when certificate management service 280 is embodied as a C2X certificate management service, certificate management service 280 may include a Long Term Certificate Authority (LTCA) configured to fulfill a role similar to that of registration certificate authority 230. 0 may include an Authorization Authority (AA) that plays a role similar to that of pseudonymous certificate authority 240. The components of certificate management service 280 are described in the following paragraphs.

[0071] In one example, certificate management service 280 may be embodied as a CMS. Various embodiments of certificate management service 280 may be used for very high volume device transaction and certificate generation processing. In various embodiments, certificate management service 280 may be implemented using multiple servers, multiple hardware security modules (HSMs), multiple calculation or computing engines, and multiple application platforms. In an exemplary embodiment, the application platforms may each include one or more virtual machines (VMs) for hosting registration authority 220, registration certificate authority 230, pseudonym certificate authority 240, and collaboration authorities 250 and 260. In additional or alternative embodiments, the application platforms may each include one or more hardware platforms, such as, for example, application servers, computers, or other computer hardware capable of hosting and executing software applications. In the example of FIG. 2 , the application platform for registration certificate authority 230 may be one or more VMs running the application for registration certificate authority 130, and the application platform for pseudonym certificate authority 240 may be one or more VMs operable to host and execute the application for pseudonym certificate authority 240. Similarly, the application platform of collaboration station 1 250 may be one or more VMs configured to host and execute applications for collaboration station 1, and the application platform of collaboration station 2 260 may be one or more VMs operable to host and execute applications for collaboration station 2. Non-limiting examples of certificate management service 280 may be implemented in a private data center, a cloud data center such as Amazon's Amazon Web Services (AWS), or a hybrid of a private data center and a cloud data center.

[0072] In some embodiments, the certificate management service 280 may provide security certificates, such as, for example, registration certificates and pseudonym certificates, for use by the manufacturer's distribution equipment 108, which may function as described with respect to Figures 1A and 1B. In particular embodiments, the certificate management service 280 may interact with a digital asset management system (DAMS) to provide certificates to the distribution equipment 108 shown in Figures 1A and 1B.

[0073] 2, the architecture of certificate management service 280 includes registration authority 220, registration authority 230, pseudonymous certificate authority 240, collaboration authority 1 250, and collaboration authority 2 260. Each of these components may utilize a dedicated computation engine (not shown) to perform tasks. For example, registration authority 220 may utilize a registration authority computation engine, registration authority 230 may utilize a registration authority computation engine, pseudonymous certificate authority 240 may utilize a pseudonymous certificate authority computation engine, collaboration authority 1 250 may utilize a collaboration authority 1 computation engine, and collaboration authority 2 260 may utilize a collaboration authority 2 computation engine. The functionality of each of these components is described in the following paragraphs.

[0074] The architecture of the certificate management service 280 advantageously separates non-security related applications from security functions. As shown in the example of Figure 2, the registration authority 220, registration certificate authority 230, pseudonymous certificate authority 240, and collaboration authorities 250, 260 are implemented as applications on their own VMs running on their own dedicated compute engines, all of which are separated from non-security related applications and functions. This allows for the security of HSMs, which can be slow to perform, or for cloud service providers to provide HSMs. This provides both technical and security advantages and improvements over conventional systems that do not provide or are uncertain about the proper management of HSMs. In certificate management service 280, all cryptographic operations requiring an HSM are performed in a compute engine (e.g., one or more compute engines).

[0075] As shown in FIG. 2 , by separating critical security functions from one another and into separate computation engines, computationally intensive cryptographic and security functions (e.g., elliptic curve butterfly expansion computations or elliptic curve digital signatures), when performed by, for example, registration authority 220, registration certificate authority 230, pseudonymous certificate authority 240, and collaboration authorities 250, 260, are performed significantly faster than in existing registration authority systems. This design, in conjunction with a Quality of Service (QoS) manager described below with reference to FIGS. 8-10 , enables significant improvements in transaction processing in multi-client environments by allowing “bottleneck” applications to be individually scaled as needed. Accordingly, embodiments consistent with the present disclosure provide a specific, technically advantageous system architecture for reducing bottlenecks associated with existing registration authority systems. For example, if the registration authority application running on registration authority 220 needs to be scaled, additional VMs can be added, but the secure computation capabilities of the registration authority’s computation engines may not need to be modified. Alternatively, if security computations are limiting performance, additional secure registration authority computation engines can be added. This same multidimensional scaling applies to other components of the Credential Management Service 280. These capabilities provide significant performance and scalability improvements over existing Security Credential Management Systems (SCMS).

[0076] In some embodiments, the application platforms of each of the registration authority 220, registration certificate authority 230, pseudonym certificate authority 240, and collaboration authorities 250, 260 are communicatively connected to a computation engine via a respective set of input message queues, allowing all of these components of the certificate management service 280 to scale independently of each other.

[0077] As discussed above and shown in the non-limiting example of Figure 2, each of the registration authority 220, the certificate authorities 230, 240, and the coordination authorities 250, 260 may be implemented as an application on its own virtual machine (VM). In additional or alternative embodiments, one or more of the registration authority 220, the certificate authorities 230, 240, and the coordination authorities 250, 260 may run on a hardware platform (e.g., a server or a computing engine). The role and function of each of these applications running on the application platform (e.g., a VM or hardware platform) are described in the following paragraphs.

[0078] In various embodiments, registration authority 220 may be an authority in a provisioning network that validates user requests for digital certificates or other types of digital security assets and enables certificate authorities (e.g., registration authority 230 and pseudonymous certificate authority 240) to issue digital certificates. In various embodiments, registration authority 220 may be similar to registration authorities known in public key infrastructure (PKI) systems. In various embodiments, a client's REST API 205 may pass certificate requests to registration authority 220, which may be implemented as a representational state transfer (REST) ​​web service. In various embodiments, multiple instances of registration authority 220 may run simultaneously. This is similarly represented for the other components of certificate management service 280 shown in FIG. 2. The registration authority functionality of certificate management service 280 is unique in that its functionality may be performed by multiple instances of registration authority 220 implemented as a REST web service. It is centralized. The primary role of the registration authority 220 is to authorize and fulfill certificate provisioning requests, while preventing the signing pseudonymous certificate authority 240 from knowing which certificate will ultimately reach a particular computerized device. The registration authority 220 interacts directly with the pseudonymous certificate authority 240 and the collaborating authorities 250, 260 via message queues to fulfill their roles within the certificate management service 280.

[0079] In particular embodiments, registration authority 220 (and other components of FIG. 2 ) can be connected to a database. Certificate management service 280 may utilize a collection of data stores or databases for data storage and retrieval. For example, the databases used can consist of one or more database logical or physical units, each having one or more tables, allowing for data separation as needed. As used herein, the term “database” refers to one or more databases or data stores. In particular embodiments, the use of multiple databases can enable data separation between registration authority 220 and other components of FIG. 2 . For example, the use of such multiple databases can enable data separation between registration authority 220, certification authorities 230, 240, and coordination authorities 250, 260.

[0080] In a preferred embodiment, the database used by certificate management service 280 is a collection of one or more fast-access, low-latency databases. In some embodiments, the database may be a NoSQL database or a database service (e.g., the DynamoDB data service offered by Amazon Web Services). In various embodiments, the data stored in the database is application dependent, but may include previously issued certificates, various federated authority values, data on devices to which certificates have been issued, operator actions, etc. Note that the data may be stored unencrypted, encrypted, or a combination thereof.

[0081] In various embodiments, certificate management service 280 includes registration authority 230 and pseudonymous certificate authority 240 because the digital certificates generated by registration authority 220 are divided into different segments, e.g., registration digital certificates and pseudonymous digital certificates.

[0082] Registration authority 230 is a non-central component of certificate management service 280 because there may be multiple instances of registration authority 230 running simultaneously. For example, in some embodiments, multiple instances of registration authority 230 may be running simultaneously. Registration authority 230 may receive requests for registration certificates from registration authority 220. The primary role of registration authority 230 is to carry out requests from registration authority 220 and issue registration certificates to end-user devices, such as distribution equipment 108 shown in FIGS. 1A and 1B. As discussed above with reference to FIG. 1A, registration authority 130 interacts directly with registration authority 120 to fulfill its role within the CMS.

[0083] Pseudonym certificate authority 240 is a non-central component of the CMS in that there may be multiple instances of pseudonym certificate authority 240 running simultaneously. Regarding pseudonym certificate authority 240, in various embodiments, there may be multiple instances of pseudonym certificate authority 240 running concurrently. Pseudonym certificate authority 240 can receive requests for pseudonym certificates from registration authority 220. The primary role of pseudonym certificate authority 240 is to fulfill requests from registration authority 220 to issue pseudonym certificates to end-user devices, such as distribution equipment 108 shown in FIGS. 1A and 1B. In certain embodiments, pseudonym certificate authority 240 fulfills requests for short-term pseudonym certificates for V2V functionality. As described below with reference to FIG. 5B, pseudonym certificate authority 240 interacts directly with registration authority 220 to perform its functions within the CMS.

[0084] In various embodiments, the coordination stations 250, 260 shown in FIG. 2 link a certificate requester's identifier (i.e., a unique identifier of the certificate requester's device) to an issued pseudonymous certificate for revocation purposes. That is, coordination station 1 250 and coordination station 2 260 provide their respective coordination values ​​as the unique identifier of the certificate requester's device to the issued pseudonymous certificate. Coordination station 1 250 and coordination station 2 260 can receive a coordination value request from registration authority 220 and then provide the requested coordination value to registration authority 220. Coordination stations 250, 260 interact directly with registration authority 220 to fulfill the coordination value request.

[0085] In various embodiments, the computation engine includes an HSM that allows these components to perform secure computations without undue exposure to hackers. In some embodiments, the computation engine can be designed to perform secure computations without requiring an embedded HSM, and in such embodiments, an HSM is embodied.

[0086] In various embodiments, different HSM versions can be used with the CMS. For example, the HSM can include an embedded HSM installed as a plug-in card within one or more compute engines. In such exemplary embodiments, the embedded HSM can be installed within one or more compute engines as a Peripheral Component Interconnect (PCI) HSM or PCI Express (PCIe) HSM. Also, for example, the HSM of certificate management service 280 can include an external, network-mounted, or network-attached HSM separate from the compute engines within their own enclosures.

[0087] Those skilled in the art will appreciate that the components and implementation details shown in Figure 2 are examples presented for simplicity and clarity of explanation. This example is not intended to be limiting, and since many variations are possible, other components, processes, implementation details, and variations can be used without departing from the principles of the invention.

[0088] 3 is a data flow diagram illustrating an exemplary data flow between a single client 302 and a CMS 380 consistent with embodiments of the present invention. In the example of FIG. 3, CMS 380 may be embodied as a V2X or C2X CMS. According to some embodiments, CMS 380 may host a certificate management service, such as certificate management service 280 described above with reference to FIG. 2.

[0089] As shown in FIG. 3 , client 302 transmits a request 310 for a certificate for one or more computerized devices. In some embodiments, the computerized devices may be ECUs or OBUs configured to be installed in vehicles. In additional or alternative embodiments, the computerized devices may be RSUs configured to be installed in traffic control devices (e.g., traffic lights, electronic traffic signs, etc.), digital billboards, and other roadside electronic signs. In particular embodiments, each certificate request 310 indicates the number of computerized devices requiring a certificate, a timestamp indicating when the certificate request 310 was sent, and the identifier of the client requesting the certificate (e.g., the identifier of client 302 in the example of FIG. 3 ). In particular embodiments, the client identifier (i.e., the client identifier) ​​may include or be one or more of a unique alphanumeric string, an authentication token, and client authentication information such as, for example, a TLS certificate, or other type of digital certificate.

[0090] CMS 380 accepts request 310 and completes the requested task by generating the requested certificate bundle within computation time 315. The certificate bundle is created by CMS 380 within computation time 315, which is a timeframe. The computation time 315 may be a number of minutes, hours, or days (e.g., number of minutes, hours, or days). The computation time 315 may vary depending on various factors, such as the workload of the CMS 380, the number of computerized devices that require certificates (as indicated in the request 310), and the latency level of the CMS 380. After generating the certificate bundle (i.e., after the computation time 315 has elapsed), the CMS 380 returns the results as a response 325 that is sent back to the client 302.

[0091] Figure 4 is a block diagram of an exemplary operating environment 400. In particular, Figure 4 illustrates a certificate management service 480 operating in two client environments consistent with embodiments of the present invention. For the sake of brevity, only the differences that occur in Figure 4 compared to Figure 2 are described below.

[0092] In FIG. 4 , the exemplary operating environment 400 includes two clients 402, 422 (e.g., Client 1 and Client 2) that can simultaneously interact with a certificate management service 480. As shown, both client 402 and client 422 can send respective simultaneous requests for certificates to one or more computerized devices over a network 435. In the example of FIG. 4 , the network 435 is the Internet. In some embodiments, the computerized device corresponds to one or more of a vehicle, a watercraft, an aircraft, a spacecraft, a medical device, a robot, a drone, a wireless or wired communication module, and an IoT device (e.g., an IoT appliance, an IoT sensor, an IoT switch, an IoT controller, or a wearable IoT device). For example, the computerized device can correspond to an OBU or ECU of the vehicle, watercraft, aircraft, spacecraft, robot, drone, medical device, or IoT device. Further, for example, the computerized device can correspond to an RSU of a traffic control device (e.g., a traffic light, a traffic signal, or an electronic traffic sign), a digital billboard, or an electronic sign.

[0093] In operating environment 400, a request for a certificate is received by a client REST API 405 of a certificate management service 480. As shown in FIG. 4, the client REST API 405 can be a public API, and the certificate management service 480 can be a V2X or C2X certificate management service. The certificate management service 480 accepts the certificate request, completes the task within a timeframe, and then returns the result (e.g., the generated certificate) to the client 402, 422 over the network 435. The certificate management service 480 includes components for generating the requested certificate. In the example of FIG. 4, these components include a registration authority 420, a registration certificate authority 430, a pseudonymous certificate authority 440, a coordination authority 1 450, and a coordination authority 4 460.

[0094] In additional or alternative embodiments, the components of certificate management service 480 may differ depending on whether certificate management service 480 is configured as a V2X or C2X certificate management service. For example, as described above with reference to FIG. 2, in embodiments in which certificate management service 480 functions as a C2X certificate management service, certificate management service 480 may include a long-term certificate authority (LTCA) configured to fulfill a role similar to that of registration certificate authority 430. Similarly, when certificate management service 480 is embodied as a C2X certificate management service, certificate management service 480 may include an authorization authority that fulfills a role similar to that of pseudonymous certificate authority 440.

[0095] The operating environment 400 has two concurrent clients 402, 422 that can both request work from the same certificate management service 480. In one example, client 402 (e.g., client 1) can send requests over network 435 for a large number of computerized devices (e.g., over 100,000 vehicles), and client 422 (e.g., client 2) can respond to client 1's certificate requests. Following this, a request for a certificate for a relatively small number of computerized devices (e.g., less than 50) can be submitted. In the case of a simple certificate management service (V2X or C2X) without a QoS manager, these two requests would be processed on a first-come, first-served basis. In this example, client 422 (e.g., client 2) must wait until client 1's job is completed before a response is provided. This means that even if client 2's request is relatively small, instead of the time it would normally take to execute client 2's request, the time delay could be hours or days (i.e., however long it takes for a large request from client 402 to be executed).

[0096] Advantageously, embodiments disclosed herein use a QoS manager (see, e.g., QoS managers 801 and 901 in FIGS. 8 and 9) that enables a certificate management service to provide QoS levels to multiple clients so that clients, such as client 422, do not experience excessive delays associated with waiting for earlier, larger requests to be fulfilled. For example, as described herein with reference to FIGS. 8-10, a QoS manager may be used by certificate management service 480 to distribute certificate requests from clients 402, 422 into two corresponding intermediary client queues, each corresponding to a particular client (e.g., client 402 or client 422) requesting a certificate. The QoS manager may also divide a client's request into one or more smaller groups (i.e., subgroups) of entries, where each entry corresponds to a subset of the number of computerized devices for which the client needs a certificate.

[0097] Figure 5 is a data flow diagram illustrating an exemplary data flow between two clients 502, 522 and a CMS 580, consistent with embodiments of the present invention. For brevity, only the differences that occur in Figure 5 compared to Figure 3 are described below.

[0098] 5, CMS 580 may be a V2X CMS or a C2X CMS. According to certain embodiments, CMS 580 may host a certificate management service, such as certificate management service 480 described above with reference to FIG.

[0099] 5, client 502 (e.g., client 1) submits large request 510, a certificate for a large number of computerized devices (e.g., 110,000 vehicles), and client 522 (e.g., client 2) submits small request 512 for a certificate for a small number of computerized devices (e.g., 40 vehicles) following the large request 510 from client 502. In various embodiments, each certificate request 510, 512 indicates the number of computerized devices needing a certificate (e.g., 110,000 for large request 510 and 40 for small request 512), a timestamp indicating when the certificate request was submitted, and the client requesting the certificate (e.g., the respective identifiers of client 502 for large request 510 and client 522 for small request 512). For example, each certificate request 510, 512 may include the client identifier of the corresponding client 502, 522 requesting the certificate. In some embodiments, the client identifier uniquely identifies either client 502 or 522 and may be a unique alphanumeric string, an authentication token, or client authentication information such as, for example, a TLS certificate, or other type of digital certificate corresponding to client 502 or 522.

[0100] Figure 5 shows a simple CMS 580 without a QoS manager making two requests 510 and 511. 5 illustrates a method for processing small request 512 on a first-come, first-served basis. When large request 510 is received by CMS 580, CMS 580 requires computation time 515 to perform the computations necessary to generate the certificate bundle needed to fulfill large request 510. In the example of FIG. 5, once the requested certificate bundle is generated, response 525 containing the requested certificate bundle is sent from CMS 580 to client 502. That is, client 502 simply waits for computation 515 before receiving response 525. In this example, client 522 (e.g., client 2) must wait a wait time 516 to receive response 527 to small request 512. As illustrated, wait time 516 for client 522 includes the total computation time 515 required for client 1's job to complete plus the additional computation time 517 required to execute small request 512 before response 527 to small request 512 is provided. That is, even though client 2's small request 512 is for far fewer certificates than large request 510 and can be executed much more quickly by CMS 580, the wait time 516 could be hours or days (i.e., the computation time 515 required for large request 510 from client 502 to execute and the computation time 517 for small request 512 to execute) instead of just the minutes it would otherwise take to execute client 2's small request 512.

[0101] Figure 6 is a block diagram of an exemplary certificate management service 680 operating in a multi-client environment 600 consistent with implementations of the present invention. For brevity, only the differences that occur in Figure 6 compared to Figures 2 and 4 are described below.

[0102] 6, an exemplary operating environment 600 includes multiple clients 602, 622 (e.g., Client 1 and Client 2), 623, ... 62n that can simultaneously interact with a certificate management service 680. As shown, a group of n clients 602, 622, 623, ... 62n can each transmit a respective request for a certificate to one or more computerized devices over a network 635 (e.g., the Internet). This can cause delays similar to those described above with reference to Figures 4 and 5, but the problem can be exacerbated if the clients 602, 622, 623, ... 62n include multiple large requesters, especially if smaller requests are sent after larger requests are received by the certificate management service 680.

[0103] In the operating environment 600, a certificate request is received by a client REST API 605 of a certificate management service 680 (e.g., a public API of a V2X or C2X certificate management service). The certificate management service 680 accepts the certificate request, completes the task within a timeframe, and then returns the results (e.g., generated certificates) to the clients 602, 622, 623, ... 62n over the network 635. The certificate management service 680 includes components for generating the requested certificates. In the example of FIG. 6, these components include a registration authority 620, a registration certificate authority 630, a pseudonymous certificate authority 640, a coordination authority 1 650, and a coordination authority 6 660.

[0104] In additional or alternative embodiments, the components of certificate management service 680 may differ depending on whether certificate management service 680 is configured as a V2X or C2X certificate management service. For example, as described above with reference to Figures 2 and 4, in embodiments in which certificate management service 680 functions as a C2X certificate management service, certificate management service 680 may include an LTCA configured to play a role similar to that of registration certificate authority 630. Similarly, when certificate management service 680 is embodied as a C2X certificate management service, certificate management service 680 may include an LTCA configured to play a role similar to that of registration certificate authority 630. It may include a certificate authority that performs a similar role.

[0105] In the operating environment 600, there are multiple concurrent clients 602, 622, 623, ... 62n (e.g., a group of n clients) that can each request work from the same certificate management service 680. In one example, clients 602, 622 (e.g., clients 1 and 2) can send a large request over the network 635 for a large number of computerized devices (e.g., over 100,000 vehicles), and following client 1 and client 2's certificate requests, another client 623 can send another large request for a certificate. Then, the last client 62n in the group of n clients can send a smaller request for a relatively small number of computerized devices (e.g., fewer than 50 vehicles). In a simple certificate management service (V2X or C2X) without a QoS manager, these requests would be processed on a first-come, first-served basis. In this example, client 62n (e.g., the last of the n clients) must wait until the previous client's job is completed before a response is provided. That is, even if the request from client 62n is relatively small, the time delay could be hours or days (i.e., however long it takes to execute a large request from client 602, 622, 623) instead of just the few minutes it would otherwise take to execute a small request from client 62n.

[0106] To address the above issues, embodiments disclosed herein advantageously use a QoS manager (see, e.g., QoS managers 801 and 901 in FIGS. 8 and 9 ) that enables a certificate management service to provide QoS levels to multiple clients so that clients, such as client 62 n, do not experience excessive delays associated with waiting for an earlier, larger request to be fulfilled. For example, as described herein with reference to FIGS. 8-10 , a QoS manager can be used in certificate management service 680 to distribute certificate requests from clients 602, 622, 623, ... 62 n into n corresponding intermediary client queues, each of the n client queues corresponding to a particular client that requested a certificate. The QoS manager can also divide the client certificate requests in the client queues into smaller groups of one or more entries, each of the one or more entries having a group size corresponding to a subset of the number of computerized devices requiring certificates.

[0107] 7 is a data flow diagram illustrating an exemplary data flow between multiple clients (e.g., n clients 702, 722, 723, ... 72n) and a CMS 780 consistent with implementations of the present invention. For brevity, only the differences that occur in FIG. 7 compared to FIG. 3 and FIG. 5 are described below.

[0108] 7, the CMS 780 may be a V2X CMS or a C2X CMS. In particular embodiments, the CMS 780 may host a certificate management service, such as the certificate management service 680 described above with reference to FIG.

[0109] As shown in FIG. 7, client 702 (e.g., client 1) sends a large request 710 for certificates for a large number of computerized devices (e.g., 110,000 vehicles), client 722 (e.g., client 2) sends another large request 711 following the large request 710 from client 702, and then client 723 sends yet another large request 713. After large requests 710, 711, and 713 are received by CMS 780, client 72n sends a smaller request 712 for certificates for a relatively small number of computerized devices (e.g., 40 vehicles). In an embodiment, each certificate request 710, 711, 712, 713 includes data fields indicating the number of computerized devices requiring a certificate (e.g., 110,000 for large request 710 and 40 for small request 712), a timestamp indicating when the particular certificate request was submitted (e.g., date and time indicating the hour, minute, and second of submission), and the client requesting the certificate (e.g., the respective identifiers of clients 702, 722, 723 for large requests 710, 711, and 713, and client 72n for small request 712). For example, each certificate request 710, 711, 712, 713 may include the client identifier of the corresponding client 702, 722, 72n, 723 requesting a certificate. In some embodiments, the client identifier uniquely identifies one of the clients 702, 722, 723, or 72n and may include or be a unique alphanumeric string, an authentication token, or client authentication information such as, for example, a TLS certificate, or other type of digital certificate.

[0110] FIG. 7 illustrates how a CMS 780 without a QoS manager processes multiple requests 710, 711, 712, and 713 sequentially on a first-come, first-served basis. Due to the large number of requests 710, 711, and 713 received by CMS 780, CMS 780 requires long successive periods of computation time 715, 717, and 718 to generate the numerous requested certificates. For example, CMS 780 requires computation time 715 to perform the computations necessary to generate the bundle of certificates needed to fulfill large request 710 from client 702. In the example of FIG. 7, once the bundle of certificates requested by client 702 is generated, response 725 with the bundle of certificates is sent from CMS 780 back to client 702. That is, client 702 only needs to wait for computation 715 before receiving response 725. In this example, client 722 (e.g., client 2) must wait for computation time 715 and additional computation time 717 to receive response 727.

[0111] Finally, client 72n with small request 712 must wait the longest time of all clients 702, 722, 723, 72n due to the fact that small request 712 was sent after large requests 710, 711, 713. That is, without the use of a QoS manager (see, e.g., QoS managers 801 and 901 in Figures 8 and 9 described below), client 72n would experience a long wait 716 before being provided with a response 727 to small request 712.

[0112] 7, client 72n must endure wait time 716 before receiving response 729 to small request 712. This is because client 72n's wait time 716 includes the entire compute time 715 required to complete client 1's job, in addition to compute time 717 to complete client 2's request, compute time 718 to complete the request from client 723, and compute time 719 required to execute small request 712. That is, even if client 72n sends small request 712 for far fewer certificates than large requests 710, 711, and 713, wait time 716 could be in the period of several hours or days. This is because wait time 716 is the sum of the combined compute times 715, 717, and 718 required for large requests 710, 711, and 713 from clients 702, 722, and 723 to execute, plus compute time 719 for small request 712 to execute. Without the use of QoS managers 801 and 901 described below with reference to FIGS. 8 and 9, small request 712 from client 72n can be executed without first having to wait for the originally submitted larger requests 710, 711, and 713 to be executed. As will be explained below with reference to Figures 8-10, a QoS manager allows a CMS or certificate management service to provide QoS levels in a multi-client environment.

[0113] 8 is a block diagram of an exemplary certificate management service 880 that uses a QoS manager 801 to provide QoS levels to multiple clients 802, 822, 823, ... 82n in a multi-client environment 800 consistent with an embodiment of the present invention. For brevity, only the differences that occur in FIG. 8 compared to FIGS. 2, 4, and 6 are described below.

[0114] 8, an exemplary multi-client environment 800 includes multiple clients 802, 822 (e.g., clients 1 and 2, out of a total of n clients), 823, ... 82n that can simultaneously interact with a certificate management service 880. The group of n clients 802, 822, 823, ... 82n can each send respective requests for certificates for one or more computerized devices over a network 835 (e.g., the Internet). This can cause delays similar to those described above with reference to Figures 4, 5, and 7, but the problem can be exacerbated if clients 802, 822, 823, ... 82n send multiple large requests, especially if smaller requests are sent after larger requests have been received by the certificate management service 880.

[0115] Certificate management service 880 includes components for fulfilling certificate requests submitted by clients 802, 822, 823, ... 82n. As shown in Figure 8, these components include QoS manager 801, public registration authority API 805, registration authority 820, registration authority 820 internal API 825, registration certificate authority 830, pseudonym certificate authority 840, collaboration authority 1 850, and collaboration authority 8 860.

[0116] In various embodiments, the public registration authority API 805 is operable to receive certificate requests from n clients 802, 822, 823, ... 82n, each certificate request indicating the number of computerized devices needing a certificate, a timestamp indicating when the certificate request was submitted, and the client requesting the certificate. For example, each certificate request may include a client identifier for one of the n clients 802, 822, 823, ... 82n requesting the certificate. In some embodiments, the client identifier uniquely identifies one of the clients 802, 822, 823, ... 82n and may include one or more of a unique alphanumeric string, an authentication token, and client authentication information, such as a TLS certificate, or other type of digital certificate.

[0117] In additional or alternative embodiments, each request may also indicate a respective client priority level, which may be based on a service tier associated with the client. In some embodiments, the service tier is a numeric value corresponding to one of a plurality of tiers ranging from the lowest service level to the highest service level (e.g., service tiers 1-10, where 1 is the lowest service level, 5 is a medium service level, and 10 is the highest service level). According to additional or alternative embodiments, each request may further indicate a request urgency level associated with the request. For example, the request urgency level of a certificate request may be specified by the client submitting the certificate request. The urgency level of such a request may be a numeric value corresponding to one of a plurality of levels ranging from the lowest urgency option to the highest urgency option (e.g., 1-10, where 1 is the least urgent, 5 is a medium urgency request, and 10 is the most urgent request). In various embodiments, ,A client may choose to pay a premium to a service provider (e.g., the entity providing certificate management services 880 or another entity) for increased priority and urgency levels on a per-client or per-request basis. Similarly, a client may choose to selectively lower the priority and urgency for certain non-urgent, low-priority requests in exchange for a rebate or other incentive.

[0118] Advantageously, the embodiment shown in FIG. 8 uses QoS manager 801 to enable certificate management service 880 to provide QoS levels to clients 802, 822, 823, ... 82n, thereby preventing clients such as client 82n from experiencing excessive delays associated with waiting to execute earlier, larger requests. For example, QoS manager 801 can be used by certificate management service 880 to distribute certificate requests from clients 802, 822, 823, ... 82n to n corresponding intermediary client queues, each of the n client queues corresponding to a particular client that requested a certificate. QoS manager 801 can also divide the client certificate requests in the client queues into smaller groups of one or more entries, each of the one or more entries having a group size corresponding to a subset of the number of computerized devices requiring certificates. In certain embodiments, group size is a user-tunable parameter with a default value of 1.

[0119] QoS manager 801 acts as an intermediary between clients 802, 822, 823, ... 82n and certificate management service 880. QoS manager 801 can accept multiple concurrent requests from any number of clients (e.g., n clients in the example of FIG. 8) and hold them in an intermediary client queue. QoS manager 801 can break down large requests into smaller requests and send the smaller requests to separate client queues (not shown, but see client queues 903, 907, 909, ... 91n in FIG. 9, described below). This allows smaller requests to complete much faster and can support any number of clients. Also, with QoS manager 801, if additional small requests arrive, they will be able to complete much faster compared to a certificate management service without a CMS or QoS manager.

[0120] In the multi-client environment 800, a request for a certificate is received by a registration authority API 805 (e.g., a public API) of the QoS manager 801. The QoS manager 801 accepts certificate requests on behalf of a certificate management service 880. In various embodiments, the QoS manager 801 is operable to distribute certificate requests from n clients 802, 822, 823, ... 82n to n intermediary client queues, each of the n client queues corresponding to a particular client requesting a certificate. The QoS manager 801 may also be configured to divide a particular client's request in that client's client queue into one or more subgroups (i.e., smaller groups) of entries, each of the one or more entries having a group size corresponding to a subset of the number of computerized devices for which the client requires a certificate. As described in more detail with reference to FIG. 9 below, in some embodiments, the QoS manager 801 includes a QoS arbiter (not shown, however, see QoS arbiter 904 in FIG. 9). The QoS arbiter is operable to select an order for entries from the multiple client queues to be placed in the QoS queue based at least in part on the number of entries in the QoS queue, the latency level of the certificate management service 880, and respective timestamps indicating when the certificate requests were submitted. According to some embodiments, the QoS manager 801 retrieves entries from the QoS queue in the order selected by the QoS arbiter. QoS manager 801 obtains the entry from the QoS queue and sends the obtained entry to certificate management service 880 via registration authority 820's internal API 825. QoS manager 801 then transfers the entry from the QoS queue to certificate management service 880 via the certificate management service's 880's call to registration authority 820's internal API 825. Certificate management service 880 then completes the tasks transferred to it by QoS manager 801 within the timeframe and then returns the result (e.g., a generated certificate) to QoS manager 801. QoS manager 801 then forwards the result as a response to client 802, 822, 823, ... 82n via registration authority API 805 and network 835.

[0121] Operating environment 800 has multiple concurrent clients 802, 822, 823, ... 82n (e.g., a group of n clients), which can simultaneously interact with QoS manager 801, which acts as an intermediary between the n clients and certificate management service 880. In one example, clients 802, 822 (e.g., clients 1 and 2) can send large requests over network 835 for a large number of computerized devices (e.g., over 100,000 vehicles), and following client 1 and client 2's certificate requests, another client 823 can send another large request for a certificate. Then, the last client 82n in the group of n clients can send a smaller request for a relatively small number of computerized devices (e.g., fewer than 50 vehicles). As described above, in the case of certificate management service 880 with QoS manager 801, these requests are placed in a client queue and gradually divided and processed (e.g., into subsets of a particular group size) as needed to provide QoS levels to clients 802, 822, 823, ... 82n. That is, instead of having to process requests sequentially on a first-come, first-served basis regardless of changes in the size or priority of the requests, QoS manager 801 is advantageously used to avoid the need to process requests sequentially. For example, instead of requesting that the last client (e.g., client 82n) wait for all jobs of prior clients to complete before a response is provided, QoS manager 801 allows certificate management service 880 to fulfill smaller requests from client 82n that arrive later but should be completed without undue delay (i.e., hours or days, however long it takes for the larger requests from prior clients 802, 822, 823 to be fulfilled).

[0122] Figure 9 is a block diagram of an example of a system 900 for implementing a QoS manager 901 consistent with implementations of the present invention. For the sake of brevity, only the differences that occur in Figure 9 when compared to Figure 8 will be described below.

[0123] 9, the exemplary system 900 includes multiple clients 902, 922 (e.g., clients 1 and 2 out of n total clients), 923, ... 92n that can simultaneously interact with a QoS manager 901 that acts as an intermediary between the clients and a certificate management service 980. Each of the multiple clients 902, 922, 923, ... 92n can transmit a respective request for certificates for one or more devices over a network 935 (e.g., the Internet in the non-limiting example of FIG. 9).

[0124] The certificate management service 980 includes components for fulfilling certificate requests submitted by clients 902, 922, 923, ... 92n. In various embodiments, the public registration authority API 905 is operable to receive certificate requests from n clients 902, 922, 923, ... 92n, each certificate request indicating the number of computerized devices needing a certificate, a timestamp indicating when the certificate request was submitted, and the client requesting the certificate. In additional or alternative embodiments, each request may also indicate a respective client priority level, which may be based on a service tier associated with the client. In some embodiments, the service tier is an alphanumeric string or number corresponding to one of a plurality of tiers ranging from the lowest to the highest service level (e.g., service tiers 1-10, where 1 represents the lowest or bronze service tier, 5 represents the mid-tier or silver tier, 7 represents the high-tier or gold tier, and 10 represents the highest or platinum tier). According to additional or alternative embodiments, each request may further indicate a request urgency level associated with the request. For example, the request urgency level of a certificate request may be specified by the client submitting the certificate request. Such a request urgency level may be an alphanumeric string or number corresponding to one of a plurality of levels ranging from the lowest urgency option to the highest urgency option (e.g., 1-10, where 1 represents a low urgency request, 5 represents a normal urgency request by default, 7 represents a very urgent request, and 10 represents an extremely urgent request). In various embodiments, one or more of clients 902, 922, 923, ... 92n may choose to pay a premium to a service provider (e.g., the entity providing QoS manager 901 or another entity) for increased priority and urgency levels on a per-client or per-request basis. Similarly, clients may choose to selectively lower the priority and urgency for certain non-urgent, low-priority requests in exchange for a rebate or other incentive.

[0125] Advantageously, system 900 uses QoS manager 901 to enable certificate management service 980 to provide QoS levels to clients 902, 922, 923, ... 92n, thereby preventing clients such as client 92n from experiencing excessive delays associated with waiting to execute earlier, larger requests. For example, QoS manager 901 may be used by certificate management service 980 to distribute certificate requests from clients 902, 922, 923, ... 92n to n corresponding intermediary client queues 903, 907, 909, ... 91n, each of these n client queues corresponding to a particular client that requested a certificate. In the example of FIG. 9, client queue 903 corresponds to client 902, client queue 907 corresponds to client 922, client queue 909 corresponds to client 923, and client queue 91n corresponds to client 92n.

[0126] As shown in FIG. 9 , the QoS manager 901 can also divide the client certificate requests in the client queue into smaller groups of one or more entries, each of which has a group size corresponding to a subset of the number of computerized devices requiring certificates. In the non-limiting example of FIG. 9 , the group size is 50 (e.g., certificates for 50 vehicles). However, it is understood that in alternative embodiments, the group size can be any number and the certificates can be for any computerized device (i.e., not limited to vehicles). For example, the group size can vary by client, and in a particular embodiment, the size is one computerized device per queue entry in the client queues 903, 907, 909, ... 91n. In an alternative or additional embodiment, the group size is a user-tunable parameter with a default value of 1. In an alternative embodiment, the system 900 can use a pooled queue approach instead of the dedicated client queues 903, 907, 909, ... 91n shown in FIG. 9 . For example, as shown in Figure 9, it is not necessary to dedicate a client queue to each client, using a one-to-one mapping between each of the n clients and the number of client queues. That is, instead of a system 900 having a dedicated (predetermined) client queue for each client, a pooled queue embodiment utilizes a pool of queues, where clients are assigned a queue based on their active queue. A given queue can only be allocated from a pool of queues when it is appropriate. That is, in a pooled queue embodiment, a queue can only be allocated to a client when the client submits a certificate request (i.e., when the client is active). One advantage of a dedicated queue embodiment is that the system 900 does not need to execute logic or instructions to allocate a queue when the client changes its state from inactive to active or active to inactive. One advantage of a pooled queue embodiment is that it optimizes the work that the QoS arbiter 904 needs to perform when looking for active jobs to place in the QoS queues 906. That is, in a pooled queue embodiment, the QoS arbiter 904 only needs to scan the queues of active clients for currently pending certificate requests (as opposed to potentially having to scan empty dedicated client queues for inactive clients).

[0127] QoS manager 901 acts as an intermediary between clients 902, 922, 923, ... 92n and certificate management service 980. QoS manager 901 can accept multiple concurrent requests from any number of clients (e.g., n clients in the example of FIG. 9 ) and hold them in the intermediary's client queues 903, 907, 909, ... 91n. As shown in FIG. 9 , QoS manager 901 breaks down large requests into smaller requests and places the smaller requests in separate client queues 903, 907, 909, ... 91n. This allows the smaller requests to complete much faster, supporting any number of clients. Also, by using QoS manager 901, if additional smaller requests come in after a large request has been received, the smaller requests can be completed much faster compared to a CMS or certificate management service without QoS manager 901.

[0128] In system 900, a request for a certificate is received by a registration authority API 905 (e.g., a public API) of QoS manager 901. QoS manager 901 accepts certificate requests on behalf of certificate management service 980. In various embodiments, QoS manager 901 is operable to distribute certificate requests from n clients 902, 922, 923, ... 92n to n intermediary client queues, each of the n client queues corresponding to a particular client requesting a certificate. QoS manager 901 may also be configured to divide a particular client's request into smaller groups of one or more entries within that client's client queue, each of the one or more entries having a group size corresponding to a subset of the number of computerized devices for which the client requires a certificate (e.g., see portions 1, 2, 3, 4, ... x of client queue 903). That is, QoS manager 901 may break down a large certificate request from a given client into smaller pieces and place those smaller pieces in that client's client queue.

[0129] In various embodiments, the QoS manager 901 includes a QoS arbiter 904. The QoS arbiter 904 selects entries from the client queues to be placed in the QoS queue 906. In particular embodiments, the QoS arbiter 904 is operable to select the order of entries from the client queues 903, 907, 909, ... 91n to be placed in the QoS queue 906 using a round robin technique. That is, the QoS arbiter 904 may sequentially select entries from each of the client queues 903, 907, 909, ... 91n, moving in order starting with the first client queue 903, and then proceeding through each of the other client queues 907, 909, ... 91n. The QoS arbiter 904 may select only enough entries from the QoS queues 906 as needed. The QoS queue 906 regulates entries only by placing entries in the queue. For example, the QoS queue 906 may limit the number of entries allowed. To improve the efficiency of the system 900, the number of entries allowed may be set to a value large enough to ensure that the certificate management service 980 is always busy, but small enough to minimize waiting times. That is, the queue depth of the QoS queue 906 is limited, and this limit is known by the QoS arbiter 904.

[0130] The QoS arbiter 904 may seek to minimize the size of the QoS queue 906 to allow new requests to enter and be placed in the QoS queue 906. In some embodiments, even if the QoS arbiter 904 places items in the QoS queue 906 in a particular order, a later-arriving, but higher-priority request may be inserted at the head of the QoS queue 906 rather than the tail. In other words, new entries in the QoS queue 906 are typically placed or configured at the tail of the QoS queue 906. The head of the QoS queue 906 in FIG. 9 is the entry for client 1 (e.g., client 1 (x50)), which is at the bottom of the QoS queue 906. This entry is at the head of the QoS queue 906, which will be the next entry destined for the certificate management service 980 via the internal API 925. However, in some cases, the QoS arbiter 904 may choose to insert the new entry at the head of the QoS queue 906, or somewhere between the head and the tail. For example, the placement of an entry into the QoS queue 906 by the QoS arbiter 904 may be based on the client priority level and / or certificate request urgency indicated in the certificate request.

[0131] In some embodiments, the QoS arbiter 904 is further operable to dynamically reorder the entries placed in the QoS queue 906 based at least in part on additional certificate requests received from additional clients (e.g., requests received from new clients after a request from client 92n). Further, for example, the order of the entries in the QoS queue 906 can be determined based on dynamic priorities assigned by the QoS arbiter 904 to each of the client queues 903, 907, 909, ... 91n, where the respective dynamic priorities assigned to each of the client queues 903, 907, 909, ... 91n are assigned by the QoS arbiter based at least in part on the number of entries in each of the client queues 903, 907, 909, ... 91n.

[0132] In various embodiments, the QoS arbiter 904 is operable to select a series of entries from the n client queues 903, 907, 909, ... 91n to place in the QoS queue 906 based at least in part on the number of entries in the QoS queue 906, the latency level of the certificate management service 980, and the respective timestamps indicating when the certificate requests were submitted.

[0133] 9, the QoS arbiter 904 uses a round-robin technique to select the order of entries from multiple clients (e.g., Client 1, Client 2, ... Client n) to be placed in the QoS queue 906. In additional or alternative embodiments, the QoS arbiter 904 is further operable to select the order of entries from n client queues 903, 907, 909, ... 91 n to be placed in the QoS queue 906 based on a request urgency level or client priority level that may be indicated in the certificate request. For example, instead of using a round-robin technique to select the order of entries from client queues 903, 907, 909, ... 91 n among all clients 902, 922, 923, ... 92 n, the QoS arbiter 904 can select the order of entries based on rules that alter the balance among the clients. For example, the order of entries can be adjusted to favor high-priority, high-paying clients (such as a particular automobile manufacturer) and low-paying clients (such as a particular automobile manufacturer). The order of entries may be determined based on respective client priority levels, which indicate low-priority, low-paying clients (e.g., a particular university that only wants to pay for idle-time processing). In this example, QoS arbiter 904 places entries from high-priority clients in QoS queue 906 before entries from lower-priority clients. Also, for example, the order of entries may be determined based on respective request urgency levels, with QoS arbiter 904 placing entries corresponding to high-priority requests in QoS queue 906 before entries corresponding to less urgent requests. In additional embodiments, QoS arbiter 904 may select the order of entries for QoS queue 906 based on rate-limiting rules indicating that certificate management service 980 should never process more than a certain number of certificates per client per unit of time (e.g., limiting a given client to no more than x certificates per hour or day).

[0134] In system 900, a given client, clients 902, 922, 923, ... 92n, may have multiple concurrent certificate requests. In particular embodiments, QoS manager 901 may not distinguish between multiple requests from the same client. In alternative or additional embodiments, QoS manager 901 may further divide concurrent requests from a single client based on rules. According to an exemplary embodiment, QoS manager 901 may divide a client's requests based on the respective request urgency levels the client provides to system 900 and rules that enforce the urgency levels among requests from that client. In this exemplary embodiment, QoS manager 901 may instruct QoS arbiter 904 on the order in which to process portions of multiple requests from a given client based on the urgency levels the client provides for each of its certificate requests. In another embodiment, a client may enable QoS manager 901 to use a round-robin technique to select the order of entries across all of that client's certificate requests.

[0135] In additional or alternative embodiments, the QoS arbiter 904 is further operable to select the order of entries from n client queues 903, 907, 909, ... 91n to be placed in the QoS queue 906 based on a request urgency level or client priority level that may be indicated in the certificate request. As shown in Figure 9, the QoS arbiter 904 selects the order of entries from multiple clients (e.g., Client 1, Client 2, ... Client n) to be placed in the QoS queue 906.

[0136] In particular embodiments, the certificate management service 980 pulls entries from the QoS queue 906 via calls to the internal API 925. However, as noted above, for a new request (from a new client that is not one of clients 902, 922, 923, 92n) or a new request from any of clients 902, 922, 923, 92n that has a higher priority than other entries in the QoS queue 906, the QoS arbiter 904 may then place the new, higher priority entry in the QoS queue 906 as the next entry for the CMS 980 to process. In one embodiment, the QoS arbiter 904 may temporarily freeze or pause the QoS queue 906, preventing the certificate management service 980 from pulling any more entries from the QoS queue 906 until the new, higher priority entry is placed in the QoS queue 906. In an alternative embodiment, the QoS arbiter 904 may remove a lower priority entry from the QoS queue 906 and replace it with a higher priority entry, and the QoS arbiter 904 may return the removed entry to the corresponding client queue.

[0137] According to some embodiments, QoS manager 901 retrieves entries from QoS queue 906 in the order selected by QoS arbiter 904 and sends the retrieved entries to certificate management service 980 via internal API 925. QoS manager 901 then transfers the entries from the QoS queue to certificate management service 980 via calls to the certificate management service's 980 registration authority's internal API 925. Certificate management service 980 then completes the tasks transferred to it by QoS manager 901 within the timeframe and then returns the results (e.g., generated certificates) to QoS manager 901. QoS manager 901 then forwards the results as responses to clients 902, 922, 923, ... 92n via registration authority API 905 and network 935.

[0138] In system 900, there are multiple clients 902, 922, 923, ... 92n (e.g., a group of n clients) that can each request work from the same certificate management service 980 via QoS manager 901. That is, multiple concurrent clients 902, 922, 923, ... 92n can simultaneously interact with QoS manager 901, which acts as an intermediary between the n clients and certificate management service 980. In the example shown in FIG. 9 , clients 902, 922 (e.g., clients 1 and 2) can send a large request over network 935 for a large number of computerized devices (e.g., over 100,000 vehicles), and another client 923 can send another large request for certificates following the certificate requests of clients 1 and 2. The last client 92n in the group of n clients can then send a smaller request for a relatively small number of computerized devices (e.g., less than 50 vehicles). As described above, in a system 900 including a QoS manager 901, these requests are placed in client queues 903, 907, 909, ... 91n and gradually divided and processed (e.g., into subsets of group size 50 in the non-limiting example of FIG. 9) to provide QoS levels to clients 902, 922, 923, ... 92n. That is, instead of QoS manager 901 having to process requests from clients 902, 922, 923, ... 92n sequentially on a first-come, first-served basis, regardless of the varying size or priority of the requests, system 900 advantageously avoids the need to process requests sequentially.For example, rather than requesting that the last client (e.g., client 92n) wait for the preceding client's job to complete before providing a response, QoS manager 901 allows certificate management service 980 to execute a smaller request from client 92n that arrives later but should be completed without undue delay (i.e., hours or days, however long it takes for the larger requests from preceding clients 902, 922, 923 to be executed).

[0139] 10 is a data flow diagram illustrating an exemplary data flow between multiple client queues 1003, 1007, 1009, ... 101n and a CMS 1080 using a QoS manager, consistent with an embodiment of the present invention. For brevity, only the differences that occur in FIG. 10 compared to FIG. 7 are described below.

[0140] 10, CMS 1080 may be a V2X CMS or a C2X CMS. In particular embodiments, CMS 1080 may host a certificate management service, such as certificate management service 980 described above with reference to FIG. 9. In some embodiments, a QoS manager with a QoS arbiter (e.g., QoS manager 901 and QoS arbiter 904 described above with reference to FIG. 9) may select entries from n client queues 1003, 1007, 1009, ... 101n that are submitted to CMS 1080.

[0141] 10, CMS 1080 receives a large request 1010 for a certificate from client queue 1003 for a first client (e.g., client 1), which is followed by another large request 1013 from client queue 1007 for a second client (e.g., client 2), which is followed by yet another large request 1014 from client queue 1009. After large requests 1010, 1013, and 1014 are received by CMS 1080, a small request 1012 for certificates for a relatively small number of computerized devices (e.g., 50 vehicles) is received from client queue 101n. In some embodiments, each certificate request 1010, 1013, 1014, 1012 includes data fields indicating the number of computerized devices requiring a certificate (e.g., 110,000 for large request 1010, 50 for small request 1112), a timestamp indicating when the particular certificate request was submitted (e.g., date and time indicating the hour, minute, and second of submission), and the client requesting the certificate (e.g., the respective identifiers of clients 1002, 1022, and 1023 for large requests 1010, 1011, and 1013, and client 102n for small request 1012).

[0142] FIG. 10 illustrates how a CMS 1080 with a QoS manager processes multiple requests 1010, 1012, 1013, and 1014. By using the QoS manager and its QoS arbiter, a later-arriving smaller request 1012 can be executed without waiting for the larger requests 1010, 1013, and 1014 to be executed first. That is, FIG. 10 illustrates how a smaller request 1012 from a client queue 101 n does not have to wait for all of the previous requests 1010, 1013, and 1014 to complete. In other words, the long continuous computation time associated with completing all of the larger requests 1010, 1013, and 1014 does not have to elapse before the CMS 1080 executes the smaller request 1012. This is achieved by the QoS manager dividing the requests 1010, 1012, 1013, and 1014 into portions that are placed in client queues 1003, 1007, 1009, ... 101 n. These portions are subgroups (i.e., smaller groups) of one or more entries, each having a group size corresponding to a subset of the number of computerized devices requiring certificates. In the non-limiting example of Figure 10, the group size is 50, and certificates are requested for vehicles. In alternative or additional embodiments, the group size is an adjustable number with a default value of 1, and certificates may be for various computerized devices requiring security credentials.

[0143] As shown in FIG. 10 , CMS 1080 requires computation time 1015 to perform the calculations necessary to generate the first portion of the bundle of certificates needed to fulfill large request 1010 from client 1002 (e.g., portion 1 of client 1's request). In the example of FIG. 10 , only portion 1 of the bundle of certificates requested by client 1002 (e.g., client 1) is generated, which requires computation time 1017, before moving on to the first portion of large request 1013 from client 1022 (e.g., portion 1 of client 2's request). Next, portion 1 of large request 1014 from client 1023 is processed, which requires computation time 1018. Next, small request 1012 from client 102n is processed in computation time 1016. By splitting the large request using the QoS manager, client 102n only needs to wait an amount of time for portions 1 of large requests 1010, 1013, and 1014 from clients 1002, 1022, and 1023 to complete. This is after large requests 1010, 1011, and 1013 This is despite the fact that small request 1012 was sent. Without the use of a QoS manager (see, e.g., QoS manager 901 in FIG. 9 above), client 102n would experience a long wait before a response to small request 1012 was provided, as it would have to wait for all parts of large request 1010, 1013, 1014 to complete before small request 1012 could be executed.

[0144] 10, client 102n only needs to wait the sum of portion 1 computation times 1015, 1017, 1018, and 1016 before receiving a response to small request 1012. This is because client 102n's wait time does not include the total computation time required for all portions of large requests 1010, 1013, and 1014 to complete. Instead, client 102n only needs to wait the computation time 1016 to complete small request 1012 plus the relatively smaller computation times 1015, 1017, and 1018 to complete the first portions of large requests 1010, 1013, and 1014. In other words, even if client 102n sends small request 1012 after large requests 1010, 1011, and 1013, the wait time will be much shorter than if a QoS manager were not used. This is because, without the QoS manager dividing the large requests 1010, 1013, 1014 into portions, the wait time for client 102 n would be the sum of the total combined computation time required to execute large requests 1010, 1013, 1014 from clients 1002, 1022, 1023, plus the computation time 1016 for small request 1012 to execute. Without the use of QoS manager 901, as described above with reference to FIG. 9, there would be no mechanism for small request 1012 from client 102 n to execute without first having to wait for previously submitted large requests 1010, 1013, and 1014 to execute. In other words, the QoS manager enables CMS 1080 to provide QoS levels in a multi-client environment.

[0145] Next, after small request 1012 has been executed, CMS 1080 processes portion 2 of large request 1010 from client 1002, which requires compute time 1015'. Next, portion 2 of large request 1013 from client 1022 (e.g., portion 2 of client 2's request) is processed, which requires compute time 1017'. Next, portion 2 of large request 1014 from client 1023 is processed, which requires compute time 1018'. At this point, because small request 1012 from client 102n has already been executed, CMS 1080 processes portion 3 of large request 1010 from client 1002, which requires compute time 1015'. The remaining portions of large requests 1010, 1013, and 1014 are processed in this manner until these requests are completed.

[0146] In some embodiments, a QoS arbiter (e.g., QoS arbiter 904 of FIG. 9) can dynamically reorder the entries placed in the QoS queues used by CMS 1080. In this manner, the order of request portions processed by CMS 1080 can be dynamically changed. For example, the QoS manager can change the order of entries in response to receiving additional certificate requests from additional clients (i.e., requests from new clients following smaller request 1012). Further, for example, the order of entries can be based on the priority level of the client and / or the urgency of the certificate request as indicated in the certificate request. Also, for example, the order of entries can be changed based on dynamic priorities assigned to each of client queues 1003, 1007, 1009, ... 101 n, where the respective dynamic priorities assigned to each of client queues 1003, 1007, 1009, ... 101 n are assigned by the QoS arbiter based at least in part on the number of entries in each of client queues 1003, 1007, 1009, ... 101 n.

[0147] 11 is a block diagram of an example computing environment 1101, including a computing system 1100, that can be used to implement systems and methods consistent with embodiments of the present invention. Other components and / or configurations can also be used. In some embodiments, the computing system 1100 can be used to at least partially implement various components of FIGS. 1-10, such as the distribution equipment 108, the registration authority 120, the coordination authorities 150, 160, the pseudonymous certificate authority 140, the registration certificate authority 130 of FIGS. 1A and 1B, the components of the certificate management services 280, 480, 680, 880 of FIGS. 2, 4, 6, and 8, the QoS manager 901 of FIG. 9, and the certificate management systems (CMS) 380, 580, 780, 1080 of FIGS. 3, 5, 7, and 10, among others. In some embodiments, a series of computing systems similar to computing system 1100 can each be customized with dedicated hardware and / or programmed as dedicated servers to implement one of the components of FIGS. 1-10, which can communicate with each other via network 1135.

[0148] 11 , computing system 1100 includes a number of components, such as a CPU 1105, memory 1110, input / output (I / O) devices 1125, a hardware security module (HSM) 1140, and non-volatile storage devices 1120. System 1100 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 1105, memory 1110, non-volatile storage 1120, and I / O devices 1125. In such a configuration, components 1105, 1110, 1120, and 1125 can be connected and communicate via a local data bus and can access a data repository 1130 (e.g., implemented as a separate data source or database system) via an external I / O connection. The I / O component 1125 can connect to external devices via a direct communications link (e.g., a wired or local WiFi connection), through a network such as a local area network (LAN) or a wide area network (WAN, e.g., a cellular network or the Internet), and / or through other suitable connections. The system 1100 can be standalone or can be a subsystem of a larger system.

[0149] The CPU 1105 may be one or more known processors or processing devices, such as the Core® family of microprocessors manufactured by Intel® Corporation of Santa Clara, California, or the Athlon® family of microprocessors manufactured by AMD® Corporation of Sunnyvale, California. The memory 1110 may be one or more high-speed storage devices configured to store instructions and information executed or used by the CPU 1105 to perform certain functions, methods, and processes related to embodiments of the present invention. The storage 1120 may be volatile or non-volatile, magnetic, semiconductor, tape, optical, or other types of storage devices or computer-readable media, including devices such as CDs and DVDs, and solid-state devices intended for long-term storage.

[0150] In the illustrated embodiment, memory 1110 includes one or more programs or applications 1115 loaded from storage 1120 or from a remote system (not shown) that, when executed by CPU 1105, perform various operations, procedures, processes, or methods consistent with the present invention. Alternatively, CPU 1105 may execute one or more programs located remotely from system 1100. For example, System 1100 can access one or more remote programs via network 1135 that, when executed, perform functions and processes related to embodiments of the present invention.

[0151] In particular embodiments, memory 1110 may include programs 1115 for performing the specialized functions and operations described herein for registration authority 120, distribution equipment 108, certificate management services 280, 480, 680, 880, CMS 380, 580, 780, 1080, QoS managers 801, 901, and / or CMS hosts with QoS arbiter 904. In some embodiments, memory 1110 may also include other programs or applications that implement other methods and processes that provide auxiliary functionality to the present invention.

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

[0153] The HSM 1140 may be a device with its own processor that securely generates and stores digital security assets and / or securely performs various cryptographic and sensitive calculations. The HSM 1140 protects digital security assets such as cryptographic keys and other sensitive data from access by potential attackers. In some embodiments, the HSM may be a plug-in card or board installed directly in the computing system 1100.

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

[0155] In the illustrated embodiment, system 1100 is connected to a network 1135 (e.g., the Internet, a private network, a virtual private network, a cellular phone network, and / or other networks), which in turn may be connected to various systems and computing machines (e.g., servers, personal computers, laptop computers, client devices, etc.). Generally, system 1100 may input data from and output data to external machines and devices via network 1135.

[0156] In the exemplary embodiment shown in FIG. 11, repository 1130 is external to system 1100. In other embodiments, repository 1130 may be hosted by system 1100. In various embodiments, repository 1130 may manage and store data used to implement systems and methods consistent with the present invention. For example, repository 1130 may manage and store data structures containing status and log information for each computerized device that has a certificate provisioned by distribution equipment 108, etc.

[0157] Repository 1130 may include one or more databases that store information and that are accessed and / or managed through system 1100. By way of example, repository 1130 may be an Oracle® database, a Sybase® database, or other relational database. However, systems and methods according to the present invention are not limited to separate data structures or databases, or even to the use of databases or data structures.

[0158] Those skilled in the art will appreciate that the components and implementation details of the system in Figure 11 are examples presented for simplicity and clarity of explanation, and other components and implementation details may be used.

[0159] Although the foregoing examples use specific examples of computerized devices, such as an OBU, an ECU, and an RSU, for clarity of explanation, the present invention is not limited to those specific examples. Various embodiments consistent with the present invention may 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, wireless communication modules (e.g., embedded universal integrated circuit cards (eUICCs)), among others.

[0160] Various operations of the applications described herein may be performed, at least in part, by one or more VMs. In additional or alternative embodiments, operations of the applications described herein may be performed, at least in part, by one or more processors that are temporarily or permanently configured (e.g., by software) to perform the associated operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform the operations, functions, and roles of one or more applications described herein. As used herein, the term "processor-implemented module" refers to a hardware module that is implemented using one or more processors.

[0161] Similarly, the methods described herein may be at least partially processor-implemented, with one or more processors being an example of hardware. For example, at least some of the operations of the methods may be performed by one or more processors or processor-implemented modules. Furthermore, one or more processors may also operate to support performance of related operations in a "cloud computing" environment or as "software as a service" (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines that include processors), and these operations may be accessible via a network (e.g., the Internet) and one or more appropriate interfaces (e.g., APIs).

[0162] Performance of a particular operation may be distributed among processors not only within a single machine, but also spread across multiple machines. In some exemplary embodiments, a processor or processor-implemented module may be located in a single geographic location (e.g., in an office environment, a manufacturing environment, or a server farm). In other exemplary embodiments, a processor or Alternatively, the processor-implemented modules may be distributed across several geographic locations.

[0163] Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with the true scope of the invention being indicated by the following claims.

Claims

1. 1. A system for providing a quality of service (QoS) level to a client requesting a certificate from a certificate management service, the system comprising:

1. An application programming interface (API) operable to receive certificate requests from a plurality of clients, each certificate request comprising: A large number of computerized devices requiring certification and a timestamp indicating when the certificate request was submitted; and an application programming interface (API) including information indicating an identifier that identifies the client requesting the certificate; A QoS manager, comprising: distributing the certificate requests from the plurality of clients across a plurality of client queues, each of the plurality of client queues corresponding to a particular client requesting a certificate; Dividing the client certificate requests in the client queue into subgroups of one or more entries, each of the one or more entries having a group size corresponding to a subset of the number of computerized devices requiring certificates; and a QoS manager operable to take entries from the plurality of client queues and send them to the certificate management service; A system comprising:

2. 2. The system of claim 1, further comprising a QoS arbiter operable to select an order of entries from the plurality of client queues to be placed in the QoS queue based at least in part on a number of entries in a QoS queue, a latency level of the certificate management service, or a timestamp indicating when the certificate request was submitted.

3. 3. The system of claim 2, wherein the QoS manager is operable to retrieve entries from the plurality of client queues by retrieving entries from the QoS queues in an order selected by the QoS arbiter and to send the retrieved entries to the certificate management service.

4. The system of claim 1 , wherein the computerized equipment requiring a certificate corresponds to one or more of an on-board unit (OBU), an electronic control unit (ECU), and a roadside unit (RSU).

5. the OBU is operable to be installed in one or more of a vehicle, a watercraft, an aircraft, a spacecraft, a medical device, a robot, a drone, a wireless communication module, a wired communication module, and an Internet of Things (IoT) device; the ECU is operable to be installed in one or more of a vehicle, a boat, an aircraft, a spacecraft, a medical device, a robot, a drone, a wireless communication module, a wired communication module, and an IoT device; The system of claim 4 , wherein the RSU is operable to be installed in one or more of a traffic control device, a wireless communication module, a digital billboard, and an electronic sign.

6. 10. The system of claim 1, wherein the plurality of clients includes at least one distribution device or server operable to act as a proxy between the certificate management service and at least one computerized device requiring a certificate.

7. 4. The system of claim 3, wherein each certificate request further includes additional information indicating a client priority level of a client sending the request, and wherein the QoS arbiter is further operable to select an order of entries from the plurality of client queues placed in the QoS queue based at least in part on the respective client priority levels indicated in the certificate request.

8. 10. The system of claim 7, wherein a client priority level of a client is based on a service tier associated with the client, the service tier corresponding to one of a plurality of tiers ranging from a lowest service level to a highest service level.

9. 8. The system of claim 7, wherein the QoS arbiter is further operable to dynamically reorder the entries placed in the QoS queue based at least in part on respective client priority levels indicated in additional certificate requests received from additional clients.

10. 4. The system of claim 3, wherein each certificate request further indicates a request urgency level associated with the request, and wherein the QoS arbiter is operable to select an order of the entries from the plurality of client queues placed in the QoS queue based at least in part on the respective request urgency levels indicated in the certificate requests.

11. 11. The system of claim 10, wherein a request urgency level of a certificate request is specified by a client submitting the certificate request, and the request urgency level corresponds to one of a plurality of levels ranging from a least urgent option to a most urgent option.

12. The system of claim 2 , wherein the QoS arbiter is operable to select the order of the entries from the plurality of client queues to be placed in the QoS queue using a round robin technique.

13. 3. The system of claim 2, wherein the QoS arbiter is operable to select an order of the entries from the plurality of client queues to be placed in the QoS queue based on a dynamic priority assigned to each of the client queues, the dynamic priority assigned to each of the client queues being assigned by the QoS arbiter based at least in part on the number of entries in each of the client queues.

14. 2. The system of claim 1, wherein the certificate requests from the plurality of clients include requests for enrollment certificates, and the API is further operable to send the plurality of clients enrollment certificates generated by an enrollment authority of the certificate management service.

15. the certificate request further includes a request for a pseudonymous certificate; the API is further operable to transmit, on behalf of the certificate management service, pseudonymous certificates generated by a pseudonymous certificate authority of the certificate management service to the plurality of clients over a communications network; the plurality of clients includes at least one distribution device operable to act as a proxy between the certificate management service and at least one computerized device requiring a certificate; The system of claim 14 , wherein at least one of the computerized devices is operable to obtain a certificate from the distribution device.

16. 16. The system of claim 15, wherein the registration certificate is a public key certificate that identifies the owner of the public key certificate as an authorized participant in an ecosystem that includes a plurality of computerized devices, and wherein each authorized participant in the ecosystem can receive one or more pseudonymous certificates that enable communication with the plurality of computerized devices.

17. 1. A computer-implemented method for providing a quality of service (QoS) level to a client requesting a certificate from a certificate management service, the computer-implemented method comprising: receiving certificate requests from a plurality of clients via an application programming interface (API), each certificate request including: A large number of computerized devices requiring certification and a timestamp indicating when the certificate request was submitted; and receiving a certificate including information indicating an identifier identifying a client requesting the certificate; distributing, by a QoS manager, the certificate requests from the plurality of clients to a plurality of client queues, each of the plurality of client queues corresponding to a particular client requesting a certificate; dividing, by the QoS manager, client requests into subgroups of one or more entries, each of the one or more entries having a group size corresponding to a subset of the number of computerized devices requiring certificates; and sending entries obtained from the plurality of client queues to the certificate management service.

18. 20. The computer-implemented method of claim 17, further comprising selecting, by a QoS arbiter, the entry from the plurality of client queues to retrieve based at least in part on a latency level of the certificate management service or a timestamp indicating when the certificate request was submitted.

19. 20. The computer-implemented method of claim 18, wherein selecting the entry to retrieve from the multiple client queues comprises using a round-robin technique.

20. 20. The computer-implemented method of claim 18, wherein selecting the entry to retrieve from the plurality of client queues is based on a dynamic priority assigned to each of the client queues, the respective dynamic priority assigned to each of the client queues being assigned by the QoS arbiter based at least in part on a number of entries in each of the client queues.

21. 20. The computer-implemented method of claim 18, further comprising: obtaining, by the QoS manager, entries from the multiple client queues by obtaining entries from QoS queues in an order selected by the QoS arbiter, and sending the obtained entries to the certificate management service.

22. 20. The computer-implemented method of claim 17, wherein the computerized equipment requiring a certificate corresponds to one or more of an on-board unit (OBU), an electronic control unit (ECU), and a roadside unit (RSU).

23. 20. The computer-implemented method of claim 17, wherein the plurality of clients includes at least one distribution device or server operable to act as a proxy between the certificate management service and at least one computerized device requiring a certificate.

24. each certificate request further includes additional information indicating a client priority level of the client sending the request; 22. The computer-implemented method of claim 21, further comprising selecting, by the QoS arbiter, an order of entries from the plurality of client queues placed in the QoS queue based at least in part on client priority levels indicated in respective certificate requests.

25. 25. The computer-implemented method of claim 24, wherein a client priority level for a client is based on a service tier associated with the client, the service tier corresponding to one of a plurality of tiers ranging from a lowest service level to a highest service level.

26. 25. The computer-implemented method of claim 24, further comprising dynamically reordering, by the QoS arbiter, the order of the entries placed in the QoS queue based at least in part on respective client priority levels indicated in additional certificate requests received from additional clients.

27. each certificate request further includes additional information indicating a request urgency level associated with said request; 22. The computer-implemented method of claim 21, further comprising selecting, by the QoS arbiter, an order of the entries from the plurality of client queues placed in the QoS queue based at least in part on a request urgency level indicated in each certificate request.

28. 28. The computer-implemented method of claim 27, wherein a request urgency level of a certificate request is specified by a client submitting the certificate request, the request urgency level corresponding to one of a plurality of levels ranging from a least urgent option to a most urgent option.

29. the certificate requests from the plurality of clients include requests for enrollment certificates; 20. The computer-implemented method of claim 17, further comprising sending to the plurality of clients an enrollment certificate generated by an enrollment authority of the certificate management service.

30. transmitting, on behalf of the certificate management service, pseudonymous certificates generated by a pseudonymous certificate authority of the certificate management service to the plurality of clients over a communications network; the certificate request further comprises a request for a pseudonymous certificate; 30. The computer-implemented method of claim 29, wherein the plurality of clients includes at least one distribution device operable to act as a proxy between the certificate management service and at least one computerized device requiring a certificate, and at least one of the computerized devices operable to obtain a certificate from at least one of the distribution devices.

Images