Scalable certificate management system architectures

Abstract

To provide systems and methods for securely generating and providing certain types of digital assets such as security credentials and digital certificates.SOLUTION: A system includes an application platform that runs a registration authority and is connected to a compute engine that performs a cryptographic computation required by the registration authority. The system also includes an application platform that runs an enrollment certificate authority and is connected to a compute engine that performs a cryptographic computation required by the enrollment certificate authority. The system further includes an application platform that runs a pseudonym certificate authority and is connected to a compute engine that performs a cryptographic computation required by the pseudonym certificate authority. The system also includes an application platform that runs first and second linkage authorities and is connected to a compute engine that performs cryptographic computation required by the linkage authorities.SELECTED DRAWING: Figure 4A

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application is a continuation - in - part of U.S. application Ser. No. 15 / 812,510, filed Nov. 14, 2017, which claims the benefit of U.S. Provisional Application No. 62 / 421,878, filed Nov. 14, 2016; U.S. Provisional Application No. 62 / 421,852, filed Nov. 14, 2016; and U.S. Provisional Application No. 62 / 487,909, filed Apr. 20, 2017, each of which is hereby incorporated by reference in its entirety.

[0002] The present invention relates to systems, devices, and methods for secure provisioning of computerized devices.

Background Art

[0003] As computers become smaller and more commoditized, manufacturers are producing an increasing number of various devices incorporating one or more embedded computers or processors. The computers within computerized devices can, among other things, control the operation of the device, collect, store, and share data, communicate with other computers and other computerized devices, and update their own software.

[0004] The Internet of Things (IoT) is a network consisting of computerized physical devices having embedded processors, electronic circuits, software, data, sensors, actuators, and / or network connectivity functions. These devices can be connected and exchange data through digital networks including the Internet, cellular networks, and other wireless networks via their network connectivity functions. Typically, each "thing" is uniquely identifiable within its own embedded computing system and can interoperate within the existing Internet infrastructure.

[0005] In the context of IoT, "things" can refer to a variety of computerized devices, especially consumer electronics products, business devices used at work or in companies, manufacturing machines, farming machines, energy consumption devices in houses and buildings (such as switches, sockets, electrical appliances, lighting systems, light bulbs, TVs, garage door openers, sprinkler systems, security systems, etc.), medical and healthcare devices, infrastructure management devices, robots, drones, transportation devices and vehicles, etc.

[0006] For example, most, if not all, modern vehicles and transportation machines (such as cars, trucks, airplanes, trains, ships, motorcycles, scooters, etc.) have several embedded processors or embedded computers in their subsystems and are at least partially computer-controlled. Similarly, many modern transportation infrastructure devices (such as traffic lights, traffic monitoring cameras, traffic sensors, bridge monitoring devices, bridge control systems, and the like) have at least one, and in many cases multiple, embedded processors or embedded computer systems and are at least partially computer-controlled. These computer-controlled elements of the transportation network usually communicate with each other while exchanging various types of information. These elements can react, respond, change their own operations, or rely on information transmitted and received from other vehicles in vehicle-to-vehicle (i.e., V2V, also known as C2C or car-to-car) communication and / or information transmitted and received from infrastructure elements in vehicle-to-infrastructure (i.e., V2I, also known as C2I or car-to-infrastructure) communication for safe, accurate, efficient, and reliable operation.

[0007] The computer within the computerized device operates according to its own software and / or firmware and data. To ensure safe and proper operation, the manufacturer must appropriately initialize and update the computerized device with suitable software, firmware, executable instructions, digital certificates (e.g., public key certificates), cryptographic keys, etc. (hereinafter collectively referred to as "digital assets" or "software"). Therefore, the IoT consists only of devices that execute software and data that have been proven to be approved and good. However, problems arise when unauthorized persons or organizations (e.g., hackers) exchange or modify the software of the computerized device. Problems also occur when old software, untested software, unapproved software, and / or software with known bugs are installed on the computerized device.

[0008] Therefore, it is desirable to provide an improved system, method, and technique for securely provisioning digital assets in a computerized device to prevent the computerized device from operating using error-prone software and data, malfunctioning software and data, untested software and data, maliciously modified software and data, or undesirable software and data.

Summary of the Invention

[0009] This specification discloses a system, method, and apparatus for securely generating and providing certain digital assets such as security credentials and digital certificates. In various implementations, the system, method, and apparatus use an extensible Certificate Management System (CMS) to create and provide certain digital assets such as security credentials and public key certificates. In some implementations, the CMS provides such certificates in response to requests for certificates such as enrollment certificates and anonymous certificates.

[0010] In various implementations, the CMS has an extensible architecture that includes a registration authority, one or more coupling authorities, an anonymous certificate authority, and an enrollment certificate authority. An exemplary CMS may include one or more application platforms communicatively connected to one or more computing engines that execute a registration authority application and perform cryptographic calculations required by the registration authority application. 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 executing software applications). The system may also include one or more VMs communicatively connected to one or more computing engines that execute an enrollment certificate authority and perform cryptographic calculations required by the enrollment certificate authority. The enrollment certificate authority application serves to generate enrollment certificates and conditionally send them to the registration authority application. The exemplary CMS may further include one or more VMs communicatively connected to one or more computing engines that execute an anonymous certificate authority application and perform cryptographic calculations required by the anonymous certificate authority. The anonymous certificate authority application serves to generate anonymous certificates and conditionally send them to the registration authority application. The CMS system may also include one or more VMs communicatively connected to one or more computing engines that execute first and second coupling authorities and perform cryptographic calculations required by the first and second coupling authorities. The first coupling authority application and the second coupling authority application serve to generate coupling values and conditionally send them to the registration authority application.

[0011] In some implementations, an extensible CMS that securely provides certificates to a provisioning controller includes one or more application platforms communicatively connected to one or more computing engines that execute a registration authority application and perform cryptographic calculations required by the registration authority application, and one or more computing engines that execute an enrollment certificate authority application and perform cryptographic calculations required by the enrollment certificate authority application. One or more application platforms connected so as to be communicable with a calculation engine, wherein the one or more application platforms may function such that a membership certificate issuing office application generates a membership certificate and conditionally transmits it to a registration office application; one or more application platforms connected so as to be communicable with one or more calculation engines that execute an anonymous certificate issuing office application and perform cryptographic calculations required by the anonymous certificate issuing office application, wherein the one or more application platforms may function such that the anonymous certificate issuing office application generates an anonymous certificate and conditionally transmits it to a registration office application; one or more application platforms connected so as to be communicable with one or more calculation engines that execute a first combining office application and perform cryptographic calculations required by the first combining office application; and one or more application platforms connected so as to be communicable with one or more calculation engines that execute a second combining office application and perform cryptographic calculations required by the second combining office application. The combining office application functions to generate a combined value and conditionally transmit it to the registration office application.

[0012] In another implementation, the CMS may further include one or more databases operably connected to one or more application platforms that execute a registration office application, one or more application platforms that execute a membership certificate issuing office application, one or more application platforms that execute an anonymous certificate issuing office application, one or more application platforms that execute a first combining office application, and one or more application platforms that execute a second combining office application.

[0013] In yet another implementation, each of the registration office application, the membership certificate office application, the anonymous certificate office application, the first combining office application, the second combining office application, and the one or more databases can operate to be independently extended from each other.

[0014] In yet another implementation, the membership certificate office application may function to generate a membership certificate in response to receiving a request for a membership certificate from the registration office application, the membership certificate office application may function to generate an anonymous certificate in response to receiving a request for an anonymous certificate from the registration office application, and the first combining office application and the second combining office application may function to generate a combined value in response to receiving a request for a combined value from the registration office application.

[0015] In some implementations, each of the registration office application, the membership certificate office application, the anonymous certificate office application, the first combining office application, and the second combining office application may be connected to be communicable with each other by a message queuing service having a plurality of message queues.

[0016] In some implementations, one or more application platforms that execute the membership certificate authority application are one or more virtual machines communicatively connected by a first plurality of message queues to one or more computing engines that perform cryptographic calculations required by the membership certificate authority application. One or more application platforms that execute the first binding station application are one or more virtual machines communicatively connected by a second plurality of message queues to one or more computing engines that perform cryptographic calculations required by the first binding station application. One or more application platforms that execute the second binding station application are one or more virtual machines.

[0017] According to some implementations having the first, second, and third pluralities of message queues, the first plurality of message queues includes a first message queue that holds messages sent to one or more virtual machines that execute the membership certificate authority application, and a second message queue that holds messages sent to one or more computing engines that perform cryptographic calculations required by the membership certificate authority application. The second plurality of message queues includes a third message queue that holds messages sent to one or more virtual machines that execute the first binding station application, and a fourth message queue that holds messages sent to one or more computing engines that perform cryptographic calculations required by the first binding station application. The third plurality of message queues includes a fifth message queue that holds messages sent to one or more virtual machines that execute the second binding station application, and a sixth message queue that holds messages sent to one or more computing engines that perform cryptographic calculations required by the second binding station application.

[0018] In another implementation having a first, a second, and a third plurality of message queues, the first plurality of message queues includes a first bi-directional message queue that holds messages sent to one or more virtual machines executing a certificate authority application and messages sent from the one or more virtual machines, and a second bi-directional message queue that holds messages sent to one or more computing engines performing cryptographic calculations required by the certificate authority application and messages sent from the one or more computing engines. The second plurality of message queues includes a third bi-directional message queue that holds messages sent to one or more virtual machines executing a first combining station application and messages sent from the one or more virtual machines, and a fourth bi-directional message queue that holds messages sent to one or more computing engines performing cryptographic calculations required by the first combining station application and messages sent from the one or more computing engines. The third plurality of message queues includes a fifth bi-directional message queue that holds messages sent to one or more virtual machines executing a second combining station application and messages sent from the one or more virtual machines, and a sixth bi-directional message queue that holds messages sent to one or more computing engines performing cryptographic calculations required by the second combining station application and messages sent from the one or more computing engines.

[0019] In another implementation of the CMS, one or more application platforms that execute the membership certificate authority application are connected by a first load balancer to be communicable with one or more computing engines that perform cryptographic calculations required by the membership certificate authority application. One or more application platforms that execute the first combining station application are connected by a second load balancer to be communicable with one or more computing engines that perform cryptographic calculations required by the first combining station application. One or more application platforms that execute the second combining station application are connected by a third load balancer to be communicable with one or more computing engines that perform cryptographic calculations required by the second combining station application.

[0020] In some implementations of the CMS including the first, second, and third load balancers, each of the load balancers may include any one or more of a load balancer virtual machine and a load balancer server. The load balancer virtual machine and the load balancer server are each configured to distribute the workload across a plurality of application platforms and a plurality of computing engines.

[0021] In another implementation having a load balancer virtual machine and a load balancer server, the load balancer virtual machine and the load balancer server are each configured to distribute the workload across a plurality of application platforms and a plurality of computing engines using a round-robin method.

[0022] In yet another implementation including a load balancer virtual machine and a load balancer server, the load balancer virtual machine and the load balancer server are each configured to distribute the workload across a plurality of application platforms and a plurality of computing engines based on the respective workloads reported by each of the plurality of application platforms and each of the plurality of computing engines.

[0023] In various implementations, the provisioning controller may, instead of the computerized device, send a request for a joining certificate to the registration authority application, receive from the registration authority application a joining certificate that may be generated by the joining certificate authority application, send the joining certificate to the computerized device, instead of the computerized device, send requests for a plurality of anonymous certificates to the registration authority application, receive from the registration authority application a plurality of anonymous certificates that may be generated by the anonymous certificate authority application, send the plurality of anonymous certificates to the computerized device, create and maintain logs related to the computerized device, and store information regarding the certificate activities of the computerized device.

[0024] In some implementations where the provisioning controller may create and maintain logs, the provisioning controller may further function to send information regarding certificate activities related to the computerized device to the provisioning controller for storage in the log.

[0025] In some implementations where the provisioning controller may send a request for a joining certificate to the registration authority application, the provisioning controller may further function to authenticate the computerized device before sending the request for the joining certificate to the registration authority application.

[0026] In another implementation, the joining certificate may be a public key certificate that identifies the holder of the public key certificate as an authorized participant within an ecosystem that includes a plurality of computerized devices, and each authorized participant within the ecosystem may also receive one or more anonymous certificates that enable communication with the plurality of computerized devices.

[0027] In some implementations, a system for provisioning one or more computerized devices includes a distributor device communicatively coupled to the computerized devices and operative to receive digital assets and cause the digital assets to be loaded onto the computerized devices, a digital asset management system connected to the distributor device via a first secure communication path and operative to generate digital assets and conditionally transmit the digital assets to the distributor device, and a provisioning controller connected to the distributor device via a second secure communication path and connected to the digital asset management system via a third secure communication path and operative to instruct the digital asset management system to transmit digital assets to the distributor device. The computerized devices may not function or may only partially function because no digital assets are present before the digital assets are loaded onto the computerized devices. The digital assets may be at least any one of a digital certificate, a cryptographic key, and executable software. In some implementations, the system may interact with an extensible CMS or receive credentials from an extensible CMS.

[0028] In various implementations, the system may further include a second distributor device connected to the digital asset management system via a fourth secure communication path, communicatively coupled to the computerized devices after the connection to the distributor device is removed, and operative to receive a second digital asset and cause the second digital asset to be loaded onto the computerized devices, and the provisioning controller may further be operative to instruct the digital asset management system to transmit the second digital asset to the distributor device. The computerized devices may function fully after the second digital asset is loaded onto the computerized devices.

[0029] In various implementations, a digital asset management system may further include one or more application platforms communicatively connected to one or more computing engines that execute a registration authority application and perform cryptographic calculations required by the registration authority application, one or more application platforms communicatively connected to one or more computing engines that execute a membership certificate authority application and perform cryptographic calculations required by the membership certificate authority application, one or more application platforms communicatively connected to one or more computing engines that execute an anonymous certificate authority application and perform cryptographic calculations required by the anonymous certificate authority application, one or more application platforms communicatively connected to one or more computing engines that execute a first combining station application and perform cryptographic calculations required by the first combining station application, and one or more application platforms communicatively connected to one or more computing engines that execute a second combining station application and perform cryptographic calculations required by the second combining station application.

[0030] In another implementation, a digital asset management system may further include one or more databases operatively connected to one or more application platforms that execute a registration authority application, one or more application platforms that execute a membership certificate authority, one or more application platforms that execute an anonymous certificate authority application, one or more application platforms that execute a first combining station application, and one or more application platforms that execute a second combining station application.

[0031] In yet another implementation, the system may further include a portal that is operably connected to the provisioning controller, authenticates the manufacturer of the computerized device, and enables the manufacturer to manage the provisioning of the computerized device, and / or a portal that is operably connected to the provisioning controller, authenticates the installer of the computerized device, and enables the installer to manage the provisioning of the computerized device, and / or a portal that is operably connected to the provisioning controller, authenticates the adjuster of the computerized device, and enables the adjuster to adjust the provisioning of the computerized device.

[0032] In yet another implementation, the provisioning controller may further function to send a digital asset (e.g., an executable software image) to a distributor device for loading onto the computerized device. In yet another implementation, the provisioning controller may further function to create and maintain a log that stores information regarding the provisioning activities related to the digital device, and the distributor device may further function to send information regarding the provisioning activities related to the digital device to the provisioning controller for storage in the log.

[0033] In yet another implementation, the provisioning controller may further function to authenticate the digital device before instructing the digital asset management system to send the digital asset.

Brief Description of the Drawings

[0034] The accompanying drawings, which are incorporated herein and form a part of this specification, illustrate implementations of the invention and, together with the description, explain the principles of the invention.

Figure 1

Figure 2

Figure 3

Figure 4A

Figure 4B

Figure 5A

Figure 5B

Figure 6A

Figure 6B

Figure 7A

Figure 7B

Figure 8

Figure 9

Figure 10A

Figure 10B

Figure 11

[0035] Reference is now made to various implementations of the present invention illustrated in the accompanying drawings. Where convenient, the same or similar parts throughout the drawings are designated by the same reference numerals.

[0036] To ensure safe and proper operation in the field, an embedded device, such as an electronic control unit (ECU) used in a vehicle, needs to be properly initialized during manufacturing by provisioning digital assets such as security sets. Digital assets can include various cryptographic keys, unique identifiers, digital certificates, and software. In most cases, the sources of these digital assets and the manufacturing plants are in separate geographical locations interconnected by non-secure Internet communications. Therefore, it is desirable to create an end-to-end secure path from the source of these digital assets to the device to prevent malicious parties or accidents from accessing or modifying the digital assets.

[0037] Conventional network security protocols for end-to-end protection such as TLS / SSL have the drawback of requiring both communicating parties to have a pre-shared key or some kind of secret security material in advance. This causes a circular technical problem that there must be some initial secret material in advance to provision digital assets. This problem includes how to protect the initial secret material. To simplify logistics, usually a single version of the initial software is installed on the computerized device during manufacturing, so this problem is particularly acute in the case of computerized devices. If this initial software must include the initial security material, there will be a wide-area secret. As a result, if the initial security material is compromised, it will lead to the compromise of all digital assets provisioned on all devices sharing the same wide-area secret. Systems, methods, and apparatuses consistent with the present disclosure address these problems and other problems of conventional provisioning systems.

[0038] Provisioning generally refers to a series of operations performed to prepare a computerized device with appropriate data and software. This may also include a series of operations performed to properly install and make the device operable within its operating environment. The operations include loading appropriate digital assets (such as operating systems, device drivers, middleware, applications, digital certificates, etc.) into the digital storage (such as memory) of the device, and further (if necessary) appropriately customizing and configuring specific digital assets on the device, and these digital assets may be unique to individual devices. The operations may also include verifying that the computerized device is a legitimate device manufactured by a legitimate device manufacturer rather than a counterfeit or forged device.

[0039] The operation may also include correctly installing the device in its operating environment and testing it to confirm that it operates properly. Since a device is manufactured by one manufacturer and may later be installed in a larger system or device by another manufacturer, for example, an on-vehicle unit (OBU) manufactured by a parts manufacturer may be installed in a vehicle manufactured by an automobile manufacturer, it is complex to securely provision only those devices that have been found to be in good condition. A device installed inappropriately may function inappropriately.

[0040] Various implementations consistent with the present invention provide secure provisioning of computerized devices, including IoT devices. Such implementations serve to prevent or block malicious, inadvertent, or mistaken tampering, alteration, updating, or release of digital assets used by the computerized device and to prevent or block inappropriate installation / installation of the computerized device and its software.

[0041] Various implementations consistent with the present invention can also create audit logs, records, reports, etc. of the secure provisioning process, which can be used to analyze and solve problems found later.

[0042] Various implementations consistent with the present invention can also provide a secure provisioning and management platform which can be provided to device manufacturers and system manufacturers in the form of a service.

[0043] FIG. 1 is a block diagram illustrating an example of a system 100 for secure provisioning of a computerized device, which is consistent with the implementation of the present invention. As shown in the example of FIG. 1, system 100 includes a provisioning controller 120. The provisioning controller 120 may be implemented as a server computer (e.g., having at least one processor and associated memory) with an embedded hardware security module (HSM), which securely generates and stores digital security assets and securely performs various cryptographic and confidential computations. The HSM protects digital security assets such as cryptographic keys and other confidential data from access by attackers. In various implementations, the provisioning controller 120 authenticates users of the system 100 and communicates securely with them, communicates securely with and manages one or more distributor devices 108, 131, communicates securely with and directs the operation of a digital asset management system (DAMS) 110, creates and stores provisioning records, creates, stores, and distributes provisioning records, creates, stores, and distributes audit logs, creates and distributes certificates for cryptographically binding the DAMS 110 and each part of the distributor devices 108, 131, revokes them as necessary if users or managed devices become untrusted, and creates and distributes secure and encrypted backups of important keys and data for off-site storage for business continuity and disaster recovery.

[0044] As shown in the example of FIG. 1, the provisioning controller 120 is communicatively connected to a database 125, which can store data, information, and digital assets related to securely provisioning devices 106a, 106b (which may be collectively referred to as 106).

[0045] The provisioning controller 120 is also communicably connected to the manufacturer's user portal 115, which may be implemented, for example, as a server or as an interface to the provisioning controller 120. In various implementations, the staff 109 of the device manufacturer 105 can interface with the provisioning controller 120 (and thus the DAMS 110) by using the manufacturer's user portal 115 and manage their device provisioning operations. In various implementations, the manufacturer's user portal 115 can collect identification information from the staff user 109, such as username, password, two-factor identification data, face recognition images, fingerprints, etc., and provide the identification information to the provisioning controller 120. The provisioning controller 120 can authenticate the staff 109 before allowing the staff 109 to access the secure provisioning system 100. For example, the provisioning controller 120 can examine the identification information related to the staff user 109 stored in the pre-verified database 125 and compare the stored identification information with the identification information collected by the manufacturer's user portal 115. Alternatively, the provisioning controller 120 or the DAMS user portal 115 may be integrated with the user's company's identification authentication system, which determines whether the staff 109 is permitted to use the system 100. In various implementations, the provisioning controller 120 or the DAMS user portal 115 can restrict the activities of the staff within the system 100 by assigning roles to the successfully authenticated staff 109. In some examples, the provisioning controller 120 can grant access only if two sets of identification information match.

[0046] Similarly, the provisioning controller 120 is also communicably connected to the installer user portal 116, which may be implemented, for example, as a server or as an interface to the provisioning controller 120 This is acceptable. In various implementations, the staff 132 of the equipment installer can interface with the provisioning controller 120 (and thus with the DAMS 110) by using the installer user portal 116, and can manage their own equipment installation work and provisioning work. The provisioning controller 120 can authenticate the staff 132 before permitting them, and can assign roles to the staff 132 before permitting them to access the secure provisioning system 100 and perform authorized functions on the system.

[0047] Similarly, the provisioning controller 120 is also communicatively connected to the adjuster portal 117, and the adjuster portal 117 may be implemented, for example, as a server or as an interface to the provisioning controller 120. In various implementations, the adjuster 140, once authenticated by the provisioning controller 120, can interface with the provisioning controller 120 by using the adjuster portal 117 and manage the review and approval of the manufacturer 104, the installer 130, the device 106, and / or the software / digital assets installed on the device 106. The provisioning controller 120 can authenticate the adjuster 140 before permitting the adjuster 140 to access the secure provisioning system 100. In some implementations of the system 100, the adjuster 140 and the adjuster portal 117 are optional.

[0048] The provisioning controller 120 is further connected to be communicable with the DAMS 110. In various implementations, the DAMS 110 may be implemented as a system consisting of a server, a device, or a secure device and / or server. The DAMS 110 securely retrieves a public key from an end entity device to be provisioned, through the distributor devices 108, 131, or through another secure and authenticated connection, and securely supplies the digital certificate and related data installed in the device 106. In addition, the DAMS 110 securely receives status information regarding the provisioning, installation, functionality, etc. of the computerized device 106 from the manufacturer 105 and the installer 130 through the distributor devices 108, 131. In addition, as shown in FIG. 1, the DAMS 110 can perform this provisioning in a single location or in multiple locations. As will be described in more detail with respect to FIG. 2, the DAMS 110 may include the following main elements, namely, a root certificate authority (CA), a policy generator, a CRL generator, a misbehavior bureau, an intermediate CA, a subscribing CA, a combining bureau, an anonymous CA, and a registration bureau.

[0049] DAMS110 improves upon the components and functions described in the paper "A Secure Credential Management System for V2V Communications" by William Whyte et al., 2013 IEEE Vehicular Networking Conference, December 2013, by adding new features. In various implementations, DAMS110 includes multi-stage programming and flexible management (e.g., allowing the introduction of adjuster 140). Various implementations of DAMS110 also enable the ability for a single DAMS110 to provide different levels of provisioning to different subscribers. Various implementations of DAMS110 also enable the ability for subscribers to allocate various digital certificate usages over a period of time (e.g., one week), as well as allocate various certificate loads (e.g., one week instead of three years as in conventional systems). Various implementations of DAMS110 also enable the ability to provide subscriber-specific URLs, whereby a computerized device 106 of a particular manufacturer (e.g., an OEM vehicle) can stay within the domain of that manufacturer (e.g., the manufacturer's URL indicates the manufacturer's name).

[0050] As shown, the provisioning controller 120 is a distributor device They are also connected so as to be communicable with the distributors 108 and 131. In various implementations, the distributor devices 108 and 131 may be implemented, inter alia, as a separate secure device installed on the company's premises (as shown in the figure) or as a web or cloud service. In various implementations, the distributor devices 108 and 131 are preferably realized as trusted endpoint devices that securely transmit and receive digital assets and other information to and from the DAMS 110 and the provisioning controller 120 via a dedicated communication path other than the Internet. As shown in the figure, the distributor devices 108 and 131 are also directly or indirectly connected to the devices 106a and 106b in order to download digital assets to the devices 106a and 106b and to receive data from the devices 106a and 106b. In various implementations, the distributor devices 108 and 131 can be implemented as a box enclosing a server computer (e.g., having at least one processor and associated memory) equipped with a hardware security module (HSM), an enhanced operating system (OS), an internal firewall, and an internal host intrusion detection / prevention system. The distributor device may be specially designed to provide trustworthy and reliable operation even when operating in an untrusted environment. The distributor device has a secure communication path between itself and the secure provisioning controller 120 and the DAMS 110. This path is used to control the distributor device and to transmit and retrieve provisioning-related data and log information. The distributor device may also have a secure communication path to the test device 107 used for programming or provisioning the device 106. This path prevents the leakage or modification of provisioning data and log data in the communication network at the manufacturing site. The distributor device 108 may also directly establish a secure communication path with the device 106 to be programmed, thereby preventing security breaches and modifications of the provisioning data by third parties (including the unauthorized test device 107).In various implementations, the distributor device can collect other data such as public keys and microprocessor serial numbers from the device 106 to be provisioned. The distributor device can send this information to the provisioning controller 120 and / or the DAMS 110. The distributor device can also receive data, commands, and other information from the provisioning controller 120 and / or the DAMS 110 to program the device 106. The distributor device can return its own log data and can also return data from the test device 107 to the provisioning controller 120 and / or the DAMS 110.

[0051] As shown with respect to the device manufacturer 105, the distributor device 108 may be communicatively connected to a test device 107 (e.g., a computerized manufacturing device, a product test device, etc.), and the test device 107 is connected to a device 106a manufactured by the manufacturer 105, such as an OBU device. The manufacturer 105 may include, or be, a factory that manufactures and / or supplies the computerized device 106a to the market. As an example of several possible examples, the computerized device 106a may be an embedded universal integrated circuit card (eUICC) installed as part of an on-board unit (OBU) and used later in a cellular modem for remote communication installed in a vehicle for communication between the vehicle and a transportation infrastructure device. The computerized device 106a may also be a secure microprocessor for V2V installed in the OBU for communication with other vehicles and roadside units (RSUs). These newly manufactured devices 106a must be properly provisioned with digital assets, such as digital certificates from the DAMS 110, in order to operate properly. The staff 109 of the manufacturer 105 can interact with the provisioning controller 120 using the user portal 115 and manage the product provisioning activities by the DAMS 110.

[0052] As shown with respect to installer 130, instead, the distributor device 131 may be directly connected to be communicable with the device 106b while the device 106b is being installed or after it has been installed in its operating environment. The installer 130 may include, or be, a factory or a workplace where the computerized device 106b is installed in its operating environment, for example, where an OBU is installed in a vehicle. The computerized device 106b must be more appropriately provisioned at installation with digital assets, for example, additional digital certificates from the DAMS 110, in order to operate properly. The staff 132 of the installer 130 can use the installer user portal 116 to interact with the provisioning controller 120 and manage the product provisioning activities by the DAMS 110.

[0053] In various implementations, the provisioning controller 120, the distributor devices 108, 131, and the DAMS 110 may have a secure and non-publicly accessible communication link or path therebetween. In various implementations, any of the communication links shown in FIG. 1 may be a non-publicly accessible communication path that is secure. In various implementations, these secure paths are encrypted and mutually authenticated to prevent unauthorized endpoints from communicating within this secure infrastructure. Multiple security mechanisms may be used to protect these communication paths, such that even if the outer layer is somehow compromised, the inner layer remains secure. As an example, a mutually authenticated TLS tunnel may be used as the outer layer, and another protocol such as a proprietary secure communication protocol may be used for the inner layer. These secure connections between the infrastructure components comprising the system 100 are used to protect confidential communication between the components and ensure their proper operation. By using these secure paths, the provisioning controller 120 and the DAMS 110 can transmit digital data between components without worrying about the digital data being compromised or modified during transmission. Commands and control information can also be passed over these paths. For example, the provisioning controller 120 can manipulate which of the distributor devices 108, 131 are the destinations for any digital assets or data. The provisioning controller 120 can also teach the distributor devices 108, 131 how to meter out this data to the devices 106 on the manufacturing line being provisioned. Further, the distributor devices 108, 131 can report back information to the provisioning controller 120 without concern for the information being compromised or modified during transmission. For example, the secure provisioning controller 120 can program the distributor devices 108, 131 to provision up to 10,000 devices with some type of digital asset, such as a certificate, software, fuse content, etc.The distributor devices 108, 131 can count the devices being provisioned, and when they reach their limit, they report this fact to the provisioning controller 120. In various implementations, the devices (e.g., 108, 110, 131, 115, 116, 117) managed by the provisioning controller 120 include a function to stop the operation of those devices when they do not communicate with the provisioning controller 120 regularly. Thus, if those devices are stolen, they become useless. This function operates as if the lost / stolen devices were still installed in a legitimate manufacturing environment, preventing the provisioning of device 106 from continuing.

[0054] Continuing to refer to the example shown in FIG. 1, during operation, the distributor device 108 at the manufacturer 105 securely receives digital assets from the DAMS 110 and supplies them to the test device 107 of the device 106a. When each device 106a is manufactured by the manufacturer 105, the test device 107 communicates with the device 106a to obtain information such as the unique identification number and status of the device 106a from the device 106a, and downloads or installs digital assets such as digital certificates to the device. The test device 107 can also supply information (e.g., provisioning status) from the device 106a to the distributor device 108, and the distributor device 108 securely transmits that information to the DAMS 110 and / or the provisioning controller 120. In some implementations, the test device 107 may include a software transport layer security (TLS) agent that securely transports data between the distributor device 108 and the device 106a, which substantially forms a secure and encrypted communication path via the distributor device 108 and the test device 107 between the DAMS 110 and the device 106a using a temporary key associated with each device 106a. The test device 107 can also supply information (e.g., provisioning status) from the device 106a to the distributor device 108, and the distributor device 108 securely transmits that information to the DAMS 110 and / or the provisioning controller 120. In some implementations, the test device 107 may include a software transport layer security (TLS) agent that securely transports data between the distributor device 108 and the device 106a, which substantially forms a secure and encrypted communication path via the distributor device 108 and the test device 107 between the DAMS 110 and the device 106a using a temporary key associated with each device 106a.

[0055] Manufacturer 105 ships device 106a to installer 130 after device 106a is first provisioned. Installer 130 installs device 106b. In various implementations, device 106a does not function before the first provisioning, and after the first provisioning by manufacturer 105, device 106a can function partially but not fully yet. In such implementations, the first provisioning only enables the device to function to the extent necessary for installation and to the extent necessary for further final provisioning to make the device fully operational.

[0056] Installer 130 installs device 106b in its operating environment, and installer staff member 132 notifies provisioning controller 120 of this through installer portal 116. This notification certifies that the installation was completed properly and preferably includes information that uniquely identifies device 106b to provisioning controller 120. In some implementations, distributor device 131 can automatically notify provisioning controller 120 after querying device 106b for status and identification information. In various implementations where installer 130 certifies through installer portal 116 that device 106b was installed properly, this certification may be recorded / saved in database 125 by provisioning controller 120. This certification may include specific test data related to the installed device 106b, such as wireless transmission power measurement and GPS antenna position verification.

[0057] In response to the setup notification, the provisioning controller 120 verifies that (i) the device 106b is listed in the database 125 as a device legally manufactured by the manufacturer 105, (ii) the device 106b is listed in the database 125 as having been initially and properly provisioned by the manufacturer 105, and (iii) the installer 130 is listed in the database 125 as an authorized installer. Upon successful verification, the controller 120 instructs the DAMS 110 to send the digital assets (e.g., anonymous proof certificate (PC)) and / or other information necessary to provision the device 106b into an operational form, such that the device 106b can function properly as if installed in the operating environment.

[0058] In various implementations, the adjuster 140 interacts with the provisioning controller 120 through the adjuster portal 117 to identify, verify, and manage the installer 130 and / or the manufacturer 105, so as to prevent unauthorized installers (e.g., hackers) from obtaining genuine digital assets from the system 100. Staff members of the adjuster 140 can be authenticated by the provisioning controller 120 and can have unique IDs in the system 100, so that the activities of the staff members can be uniquely recorded. In various implementations, the adjuster 140 uses the adjuster portal 117 to query the provisioning controller 120 and obtain copies or reports of information recorded by the controller 120, such as proof reports, installer activities, the number and identification information of the manufactured devices 106a, and the number and identification information of the installed and fully provisioned devices 106b. be entered.

[0059] In various implementations, in order for installer 130 to interact with system 100, installer 130 must be authenticated as an authorized installer by provisioning controller 120. To be authorized, installer 130 may, for example, have to fulfill a proper contract stating that installer 130 will properly install device 106b in the environment that installer 130 is targeting (e.g., a vehicle or location of interest). Installer 130 may, for example, be required to have other contractual terms attested to by adjuster 140. Desirably, each installer 130 has a unique ID within system 100, whereby the activities of installer 130 can be uniquely recorded by provisioning controller 120.

[0060] The described implementation of system 100 and its functionality ensures that only devices 106 that are manufactured by manufacturer 105 and properly installed and tested by an authorized installer 130 are fully provisioned with the digital assets necessary to make device 106 operational. Provisioning controller 120 creates extensive logs and reports that communicate who performed what actions at each stage of the provisioning process, providing an important auditing capability not present in conventional systems.

[0061] Those skilled in the art will recognize that the components, processes, data, steps, and implementation details shown in FIG. 1 are examples presented to simplify and clarify the description. This example is not intended to be limiting, and since numerous variations are possible, other components, processes, implementation details, and variations can be used without departing from the principles of the present invention. For example, FIG. 1 shows only one manufacturer 105, only one installer 130, and only one adjuster 140, but in other implementations, there may be any number of each of these entities. As another example, the DAMS 110 and the provisioning controller 120 are shown as separate devices, but in another implementation, their functions may be combined into a single device, such as a single server. As yet another example, the same can be done for the portals 115 - 117. As yet another example, the system 100 can additionally include an asset management apparatus (AMA, not shown) as described in U.S. Provisional Application No. 62 / 421,852, filed Nov. 14, 2016, which is incorporated by reference. In such an implementation, the AMA may be communicatively connected to the provisioning controller 120 and / or the distributor devices 108, 131, and / or the DAMS 110. In various implementations, the AMA may include a user-friendly GUI and functions that enable a production coordinator to easily and efficiently manage the configuration and structure of a product (e.g., device 106) and enable an asset owner to easily and efficiently manage the inventory of digital assets.

[0062] Figure 2 is a swimlane diagram showing an example of process 200 for securely provisioning a computerized device that conforms to the implementation of the present invention. In various implementations, some or all of the processes 200 or steps shown may be performed by code executed on a general-purpose 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 spanning the top of Figure 2, the entities involved in process 200 include manufacturer 105 of computerized device 106, distributor device 108 at manufacturer 105, provisioning controller 120, and DAMS 110. In various implementations, these entities may be as described with respect to Figure 1, may be as described throughout the present disclosure, and may communicate with each other.

[0063] As shown in the example of Figure 2, process 200 begins at 205, where manufacturer 1 05 (e.g., staff member 109) requests a digital asset provisioning service from provisioning controller 130 for digital assets to be provisioned to device 106a (e.g., used by device 106a), and this request can identify device 106a which is the destination of the digital asset. The request may be, for example, one in which manufacturer 105 requests a provisioning service for new product 106A, or may be one in which a new provisioning service request is made for existing product 106B. In various implementations, this step may involve an authorized user logging on to provisioning controller 130, for example, through user portal 115. In some cases, the digital assets requested may be secure credentials such as a certificate of enrollment, executable code that device 106 executes, digital operation parameters. A certificate of enrollment is a public key certificate that identifies its holder as an authorized participant within the ecosystem, and within this ecosystem, all participants must possess a valid certificate of enrollment. (such as the V2X ecosystem of the US Department of Transportation), an authorized participant may also receive an anonymous certificate that enables communication and operation of device 106 within the ecosystem (e.g., in the example of the V2X ecosystem of the US Department of Transportation, to enable communication and operation between vehicles and roadside infrastructure).

[0064] At 210, provisioning controller 120 determines whether user 109 of the manufacturer is an authorized user. In some implementations, provisioning controller 120 can also determine at 210 whether the device 106a to be provisioned (e.g., a product) is approved for use in system 100. In some cases, a list of approved devices may be provided by adjuster 140 of FIG. 1 and may be used by provisioning controller 120 in making this determination.

[0065] The provisioning controller 120 rejects requests for the digital asset provisioning service if the user (and / or product) is not authorized (not shown in FIG. 2). On the other hand, when an authorized user makes a request (e.g., for an authorized product) (210, yes), the provisioning controller 120 instructs, commands, or controls the DAMS 110 to fulfill the service request, e.g., by sending a service request command to the DAMS 110 at (215).

[0066] At 220, in response to receiving the request from 215 and conditional on receiving the request from 215, the DAMS 110 configures itself to begin providing service to the device 106a based on the request. In some implementations, the DAMS 110 can also send commands to the distributor device 108 (not shown) to configure the distributor device 108 to service the device 106a.

[0067] At 222, the DAMS 110 generates, creates, calculates, and / or searches for digital assets for the device 106a requested at 205. In various implementations, the DAMS 110 can create or generate requested digital security assets such as public and private key pairs, as well as enrollment and anonymity certificates for the device 106a.

[0068] In an alternative implementation of step 222 (not shown in FIG. 2), the DAMS 110 requests from the distributor device 108 and receives digital asset generation information related to the device 106a, such as enrollment and anonymity public keys generated by and retrieved from the device 106a, and data that uniquely identifies the device 106a (e.g., microprocessor serial number). In such an implementation, the DAMS 110 then uses the enrollment and anonymity public keys to generate digital assets, e.g., an enrollment certificate and an appropriate number of anonymity certificates for the device 106a.

[0069] At 225, DAMS 110 transmits digital assets to the distributor device 108 of the manufacturer 105 that requested digital asset services at 205. For example, DAMS 110 can securely transmit a public-private key pair, a membership certificate, and an anonymity certificate to the distributor device 108 of the manufacturer 105.

[0070] At 226, DAMS 110 transmits log information regarding the digital assets to the provisioning controller 120. In various implementations, the log information may include information describing the request and transfer of the digital assets, such as the ID of the requester, the ID of the digital asset, the ID of the distributor device, the timestamps of the request operation and the transmission operation, the received microprocessor serial number, and the like. In some implementations, the log information may include a copy of the digital asset. At 227, the provisioning controller 120 receives the log information and stores the log information in, for example, the database 125. The provisioning controller 120 substantially manages the audit trail of all activities occurring within the system 100, thereby enabling the compilation of many types of data, such as data regarding how many devices 106a were manufactured and provisioned by the manufacturer 105 and when. Such data and log information can be used for invoice creation and for audit purposes.

[0071] At 230, the distributor device 108 receives and stores the digital assets (e.g., public-private key pair, membership certificate, and anonymity certificate) transmitted by DAMS 110.

[0072] At 235, the distributor device 108 requests from device 106a and receives a digital security asset such as a public key that can be used to securely transfer a digital asset from the distributor device 108 to device 106a. Various types of device 106a have the ability to generate a temporary key pair, possibly using a secure processor incorporated into device 106 in some cases, and the public key may be part of this temporary key pair. At 240, the distributor device 108 uses the digital security asset (e.g., public key) to securely send a digital asset (e.g., membership certificate) to device 106a. In various implementations, the distributor device 108 uses the public key of device 106a to form, for example, a virtual private network (VPN) with device 106a and can securely send digital assets within it.

[0073] In various implementations, the distributor device 108 uses transport layer security (TLS) between the distributor device 108 and the test device 107 to secure communication with the test device 107 that may be connected to device 106a. In implementations where it is desired to provide direct and secure communication to device 106a, the system creates a temporary public key pair at device 106a and uses the public key in conjunction with a certificate from the distributor device 108 that includes the public key of the distributor device 108 to create a secure tunnel to device 106a. In such an implementation, device 106a executes special code that includes the root public key of system 100 to verify the certificate sent by the distributor device 108 to device 106a.

[0074] Once a secure path is established between device 106a or test device 107 and distributor device 108, device 106a can then create subscription / anonymity public key pairs (e.g., for the V2X ecosystem) and export those public keys and other data to distributor device 108, and distributor device 108 can then send this data to DAMS 110 and provisioning controller 120. As described above with respect to the alternative implementation of step 222, DAMS 110 can use the received public keys to create subscription certificates and anonymity certificates, but in some implementations, the number of anonymity certificates can be large (e.g., 3000). In this alternative implementation example, DAMS 110 returns these certificates to distributor device 108 in the aforementioned step 225. In some other implementations, DAMS 110 can also send these certificates to distributor device 131 instead of distributor device 108, depending on where the provisioning is being performed. There may be (e.g., 3000). In this alternative implementation example, DAMS 110 returns these certificates to distributor device 108 in the aforementioned step 225. In some other implementations, DAMS 110 can also send these certificates to distributor device 131 instead of distributor device 108, depending on where the provisioning is being performed.

[0075] In some implementations, for example, if device 106 has its own wireless or wired communication capabilities and is at least partially operable, distributor device 108 can communicate directly with device 106. In another implementation, distributor device 108 can communicate indirectly with device 106 via an intermediate device such as test device 107.

[0076] Device 106a receives a digital asset and stores it for use during operation. For example, if device 106a is an on-vehicle unit (OBU) or an electronic control unit (ECU) of an automobile and the digital asset is a security asset (e.g., a public key certificate) required for participating in a wireless network, this digital security asset is stored by the OBU. Later, the OBU installed in the automobile and operated by the automobile attempts to connect to the wireless network. The network attempts to authenticate the OBU before permitting the OBU to connect to the network. The OBU can be authenticated and can participate in the network only if it has the digital security asset provided by the distributor device 108 of the manufacturer 105.

[0077] At 245, the distributor device 108 receives or accesses status information from the device 106a that indicates whether the digital asset transmitted at 240 was successfully received and installed (e.g., stored) by the device 106a.

[0078] At 250, the distributor device 108 transmits the status information to the provisioning controller 120. At 255, the provisioning controller 120 receives the status information and stores it together with the log information stored in step 227. Therefore, the provisioning controller 120 maintains an audit trail or audit log for all system 100 activities related to each device 106. In various implementations, the audit log may include, for each device 106, information indicating the success or failure of manufacturer provisioning (e.g., steps 235 - 245), the identification information of the digital asset (and / or a copy of the digital asset itself), the type of encryption technology, and the like.

[0079] When the device 106a is successfully provisioned with the digital asset, the manufacturer 105 sells the device to the market at 270. For example, the manufacturing company 105 can physically ship the device 106a to the company that installs the device in its operating environment (e.g., the installation company 130 in FIG. 1). In some implementations, the device 106a may be fully programmed or provisioned at this point and can operate in a fully functional manner. However, in other implementations, the device 106a may only be partially programmed or provisioned at this point and may not be able to operate in a fully functional manner or may lack functionality.

[0080] The example shown in FIG. 2 is for illustrative purposes only and is not intended to be limiting. Further, the process 200 shown is a somewhat simplified example for clearly explaining certain new and innovative features that match the disclosed specific implementation. This example is not intended to be limiting, and numerous variations are possible. For example, the functions and steps are shown as being performed in a specific order, but the described order is only an example, and the steps can be performed in various different orders according to the disclosed specific implementation. Further, the steps are described as individual steps solely for the purpose of explanation, but in some implementations, multiple steps may be performed simultaneously and / or as part of a single calculation or as part of a larger process. The described steps are not intended to be exhaustive, limiting, or absolute, and various steps can be modified, inserted, or deleted. As an example of a variation, FIG. 2 is generally described in the context of a single digital asset (e.g., a single digital certificate), but the system and process can function and process in the same way with multiple digital assets (e.g., two or more digital certificates). As another example, if the device 106a does not have secure communication capabilities, steps 235 and 240 can be deleted, and the distributor device 108 can communicate with the device 106b using unencrypted communication.

[0081] As yet another example, in various implementations, an agency such as the provisioning controller 120 or a special signature device can similarly send another digital asset or an additional digital asset, including digital assets such as software, firmware, fuse blobs, manifest files, etc., to the distributor device 108 and cause the distributor device 108 to load it into the device 106b. In such an implementation, the provisioning controller 120 can, in addition or instead, search for the requested digital asset from storage, obtain the requested digital asset, or access the requested digital asset, or direct access to the requested digital asset. For example (not shown in FIG. 2), the provisioning controller 120 or its authorized agent can search for an executable software image (e.g., a compiled computer program stored in the database 125) that is loaded into and executed by the device 106a and send this executable software image to the distributor device 10 to program the device. In various implementations, the digital assets accessed by the provisioning controller 120 may consist only of software, etc., that has been securely supplied, released, and / or authorized by the manufacturer 105 of the device 106a, in which case unauthorized software cannot be loaded into the device 106a. In some implementations, the digital assets searched for by the provisioning controller 120 may be stored in a storage device or database associated with the provisioning controller 120, such as the database 125 of FIG. 1.

[0082] Figure 3 is a swimlane diagram showing an example of process 200 for securely provisioning a computerized device that conforms to the implementation of the present invention. In various implementations, some or all of the processes 300 or steps shown may be performed by code executed on a general-purpose 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 these two. As shown spanning the top of Figure 3, the entities involved in process 300 include installer 130 of computerized device 106, distributor device 131 at installer 130, provisioning controller 120, and DAMS 110. In various implementations, these entities may be as described with respect to Figure 1, may be as described throughout the present disclosure, and may communicate with each other.

[0083] As shown in the example of Figure 3, process 300 begins at 305, where installer 130 receives device 106b (e.g., OBU or ECU) manufactured, sold, or shipped by manufacturer 105 (see step 270 of Figure 2). At 310, installer 130 can install device 106b in its operating environment, e.g., in a larger system. For example, installer 130 may be an automobile manufacturer that purchases an OBU from manufacturer 105, and installer 130 can install the OBU in an automobile. In various implementations, installation of device 106b may include testing the operation, functionality, etc. of device 106b after installation and collecting relevant status data.

[0084] In some implementations, device 106b may only be partially provisioned and may not function fully. For example, manufacturer 105 of device 106b may have provisioned device 106b with only a certificate of enrollment, and in order to obtain full functionality, for example, in order to obtain the ability to communicate with another fully programmed device 106, device 106b may need to be further provisioned with another digital certificate, such as an anonymity certificate.

[0085] At 315, installer 130 (e.g., staff member 132) sends installation status data to provisioning controller 120. In various implementations, the installation status data includes an immutable identifier of the installed device, such as a serial number, or other information that fixedly and uniquely identifies, such as the public key of a key pair that is never erased once generated. The installation status data may include other information, such as a unique identifier of installer 130, information indicating how and when device 106b was installed, information regarding the results of tests performed on installed device 106b, information proving that installer 130 installed device 106b in accordance with applicable specifications, contractual conditions, and / or instructions, and / or other similar information.

[0086] At 320, the provisioning controller 120 determines whether the user of the installer 130 is an authorized user. If the user is not an authorized user, the provisioning controller 120 rejects the contact of the installation status (not shown in FIG. 3). On the other hand, if an authorized user makes a request (320, yes), the provisioning controller 120 determines whether the device 106b specified by the installation status data is an authorized device (325). In some implementations, the provisioning controller 120 can determine that the device 106b is authorized by verifying, with reference to the information pre-stored in its database 125, that 1) there is a record of the device 106b in its dbase 125, 2) the record indicates that the device 106b has been successfully provisioned by the manufacturer 105, and 3) the record indicates that the device 106b has been sent to the installer 130 (confirmed to be the installer authorized at 320).

[0087] If the device specified by the installation status data is not authorized, the provisioning controller 120 rejects the contact of the installation status (not shown in FIG. 3). On the other hand, if the device 106b specified by the installation status data is authorized (325, yes), at 330, the provisioning controller 120 stores the installation status data together with the log information related to the device 106b. For example, the log information related to the device 106b may be pre-stored in the database 125 as described with respect to step 227 in FIG. 2.

[0088] At 335, the provisioning controller 120 instructs, commands, or controls the DAMS 110 to fulfill the provisioning request by, for example, sending a request to provision the device 106b at the installer 130 to the DAMS 110. At 340, in response to receiving the request from 335 and conditional on receiving the request from 335, the DAMS 110 generates and / or searches for the digital asset requested at 335. In various implementations, as described with respect to FIG. 2, the DAMS 110 can create or generate the requested digital asset, such as an anonymous certificate or other public key certificate. In various implementations, the DAMS 110, or the provisioning controller 120 instead of the DAM 110, can also or instead search for, retrieve, or access the requested digital asset, such as an executable image pre-stored in the database 125 for use on a device of type 106b, from storage.

[0089] At 345, the DAMS 110 sends the digital asset to the distributor device 131 of the installer 130 that sent the installation status at 315. For example, the DAMS 110 can securely send an anonymous certificate to the distributor device 131 of the installer 130.

[0090] At 350, the distributor device 131 performs the same or similar steps as steps 230 - 245, as described with respect to FIG. 2. At 355, the distributor device 131 sends status information to the provisioning controller 120. At 360, the provisioning controller 120 receives the status information and stores the status information together with the stored information related to the device 106b, such as the status information stored at 227. Therefore, the provisioning controller 120 maintains an audit trail or audit log for all system 100 activities related to each device 106.

[0091] The process 300 shown in FIG. 3 is an example for illustrative purposes and is not intended to be limiting. Further, the process 300 shown is a somewhat simplified example for clearly explaining new and innovative specific features that match the disclosed specific implementation, but numerous variations are possible. For example, the functions and steps are shown as being performed in a specific order, but the described order is merely an example, and the steps can be performed in various different orders in accordance with the disclosed specific implementation. Further, the steps are described as individual steps solely for illustrative purposes, but in some implementations, multiple steps may be performed simultaneously and / or as part of a single calculation or as part of a larger process. The described steps are not intended to be exhaustive, limiting, or absolute, and various steps can be modified, inserted, or deleted.

[0092] FIG. 4A and FIG. 4B are both block diagrams of an exemplary architecture implementing an extensible and secure Certificate Management System (CMS) 400 according to an implementation of the present invention. Various implementations of the extensible CMS 400 may be used for ultra-large-scale device transactions and certificate generation processes. In various implementations, the extensible CMS 400 may be implemented using multiple servers, HSMs, multiple computing engines or computing engines, and multiple application platforms. In the exemplary implementations shown in FIGS. 4A and 4B, the application platforms may each include one or more virtual machines (VMs). In additional or alternative implementations, the application platforms may each include one or more hardware platforms, such as application servers, computers, or other computer hardware that can host and execute software applications, etc. In the example of FIGS. 4A and 4B, the application platform of the subscriber certificate authority 430 may be one or more VMs that execute the subscriber certificate authority application, and the application platform of the anonymous certificate authority 440 may be one or more VMs that function to host and execute the anonymous certificate authority application. Similarly, the application platform of the combining station 1 450 may be one or more VMs configured to host and execute the combining station 1 application, and the application platform of the combining station 2 460 may be one or more VMs that function to host and execute the combining station 2 application. Examples of the extensible CMS 400 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.

[0093] In some implementations, the extensible CMS400 can provide security certificates, such as manufacturing certificates, anonymous certificates, etc. that can function as described with respect to FIG. 1 and as described in other parts of this disclosure, and can be used by the distributor device 108 of manufacturer 105. In some implementations, the extensible CMS40 0 can interact with the digital asset management system (DAMS) 110 described with respect to FIG. 1 to provide certificates to the distributor device 108.

[0094] As shown in the example of FIG. 4A, the architecture of the CMS400 may desirably include two provisioning controllers 120 implemented on separate servers, namely a primary provisioning controller and a standby provisioning controller. The two provisioning controllers 120 include the function of copying or accommodating objects, data, etc. contained in the primary provisioning controller to the standby (secondary) provisioning controller. The standby provisioning controller can be brought online and replace the primary provisioning controller if the primary provisioning controller goes offline for some reason. This provides continuous (or very high) availability of the provisioning controller 120. In various implementations, the primary and standby provisioning controllers may be as described with respect to FIG. 1 and as described in other parts of this disclosure. In various implementations, the provisioning controller 120 may be connected to the extensible CMS400 in the same or a similar manner as described herein with respect to the connection and communication between the provisioning controller 120 of FIG. 1 and the manufacturer's distributor device 108.

[0095] Generally, the provisioning controller 120 manages system elements with infrastructure such that only explicitly authorized elements can participate in and communicate with the extensible CMS 400. In various implementations, the provisioning controller 120 can be integrated with the employee identification and authorization system of a user (e.g., the manufacturer 105 or the installer 130), or can provide its own identification and authorization function to enable only authorized users to use the extensible CMS 400. In some implementations, the provisioning controller 120 may be a device lifecycle management (DLM) controller, for example, a primary and standby DLM controller. In various implementations, the provisioning controller 120 may be a controller that exists within a component of the CMS 400 type. For example, in FIGS. 4A and 4B, the provisioning controller 120 may be one set or pair of controllers that exist for the registration office 420, the certificate of membership office 430, the anonymous certificate office 440, and the binding offices 450, 460.

[0096] As shown in FIGS. 4A and 4B, the architecture of the extensible CMS 400 includes a registration office 405, a registration office 420, a registration office computing engine 425, a certificate of membership office 430, a certificate of membership office computing engine 435, an anonymous certificate office 440, an anonymous certificate office computing engine 445, a binding office 1 450, a binding office 1 computing engine 455, a binding office 2 460, a binding office 1 computing engine 465, message queues 410, 411, 412, 413, 414, 415, 416, 417, 418, 419, and one or more databases 470 implemented as representational state transfer (REST) web services. Each of these components will be described in the following paragraphs.

[0097] The architecture of the extensible CMS400 advantageously separates non-security-related applications from security functions. As shown in the examples of FIGS. 4A and 4B, the registration office 420, the membership certificate office 430, the anonymous certificate office 440, and the combination offices 450, 460 are all implemented as applications on their respective VMs that run on their respective dedicated computing engines 425, 435, 445, 455, and 465, independent of non-security-related applications and functions. This provides both technical and security advantages and advancements that surpass conventional systems where the performance of the HSM is slow, or the cloud service provider cannot supply the HSM, or its proper HSM management is uncertain. In the extensible CMS400, all cryptographic operations that require an HSM are performed by a computing engine (e.g., any one or more of computing engines 425, 435, 445, 455, and 465).

[0098] As shown in FIGS. 4A and 4B, by separating important security functions from each other and also separating them into separate computing engines, for example, cryptographic functions and security functions that involve a lot of calculations performed by the registration office 420, the certificate-issuing office 430, the anonymous-certificate office 440, and the combining offices 450, 460 (such as elliptic curve butterfly extension calculations or elliptic curve digital signatures) are performed much faster than existing registration office systems. This design enables a significant improvement in transaction processing by making it possible to individually expand the "bottleneck" applications as needed. Therefore, an implementation consistent with the present disclosure particularly provides a technically advantageous system architecture to reduce the bottlenecks associated with existing registration office systems. For example, if the registration office applications running on the registration offices 405 and 420 need to be expanded, additional VMs can be added without the need to modify the secure computing capabilities of the registration office computing engine 425. Instead, if the security calculations are limiting performance, additional secure registration office computing engines 425 can be added. The same multi-dimensional expansion also applies to other components of the CMS 400. These capabilities provide a significant performance improvement and scalability that exceed existing security credential management systems (SCMS).

[0099] In the example shown in FIGS. 4A and 4B, the registration office 405 is connected to other components by a messaging subsystem or message queuing service that includes input message queues 410, 411, 412, 413, 414, 415, 416, 417, 418, and 419, and the other components are connected to each other. In the exemplary implementation of FIGS. 4A and 4B, since the input message queues 410, 411, 412, 413, 414, 415, 416, 417, 418, and 419 are unidirectional, messages flow in one direction (e.g., from the client to the server) through these queues. This provides the technical advantage of simplicity by providing a single input queue for each of the VMs and the computing engines.

[0100] In some implementations, the messaging service may be a high-speed message queuing service, such as, for example, Amazon Simple Queue Service (SQS) provided by Amazon Web Services. For example, according to such an implementation, message queues 410, 411, 412, 413, 414, 415, 416, 417, 418, and 419 may be SQS message queues. By connecting the input message queues 410, 411, 412, 413, 414, 415, 416, 417, 418, 419 to enable the application VMs and the compute engines to communicate with each other, the application VMs and the compute engines can be individually scaled as needed. That is, each application platform of the registration office 420, the certificate authority 430, the anonymous certificate authority 440, and the combination offices 450, 460 is connected so as to be communicable with the compute engines 425, 435, 445, 455, and 465 through their respective input message queues. Therefore, these components of the CMS 400 and the database 470 can all be scaled separately from each other.

[0101] As described above and as shown in the non-limiting examples of FIGS. 4A and 4B, each of the registration offices 405, 420, the certificate authorities 430, 440, and the combination offices 450, 460 may be implemented as an application on its own virtual machine (VM). In additional or alternative implementations, any one or more of the registration offices 405, 420, the certificate authorities 430, 440, and the combination offices 450, 460 may run on a hardware platform (e.g., a server or a compute engine). In the following paragraphs, the role and function of each of these applications running on an application platform (e.g., a VM or a hardware platform) will be described.

[0102] In various implementations, the registration authority 405 may be the authority that verifies user requests for digital certificates and other types of digital security assets in a provisioning network and causes a certificate authority (e.g., the subscriber certificate authority 430 and the anonymous certificate authority 440) to issue such digital certificates. In various implementations, the registration authority 405 may be similar to a registration authority known in a public key infrastructure (PKI) system. In various implementations, the registration authority 405 may be implemented as a representational state transfer (REST) web service. As represented by three "stacked" rectangles for the registration authority 405 in FIG. 4A, in various implementations there may be multiple instances of the registration authority 405 that execute concurrently. This is similarly represented for the other "stacked" elements in FIGS. 4A and 4B. The registration authority functionality of the CMS 400 is decentralized and the functionality can be performed by multiple instances of the registration authority 405 implemented as a REST web service and multiple instances of the registration authority 420. The first role of the registration authorities 405, 420 is to accept and fulfill certificate provisioning requests and, at the same time, prevent the signing anonymous certificate authority 440 from knowing which certificate is going to a particular computerized device. The registration authorities 405, 420 communicate directly with the anonymous certificate authority 440, the binding authorities 450, 460 through message queues 414, 416, and 418 to perform their roles within the CMS 400.

[0103] As represented by the arrow "DB" that appears from the lower left of the rectangle, the registration office 405 (as well as the other components in FIGS. 4A and 4B indicated by the arrow "DB") may each be connected to a respective database 470. Although only a single database 470 is shown in FIG. 4A, it should be understood that the CMS 400 can utilize a group of data stores or databases 470 for data storage and retrieval. For example, the database 470 may be composed of one or more database logical or physical units, each having one or more tables that allow for data separation as needed. The term "database" as used herein refers to one or more databases or data stores. In some implementations, the use of multiple databases 470 allows for data separation between the registration office 405 and the other components in FIGS. 4A and 4B indicated by the arrow "DB". For example, the use of such multiple databases 470 allows for data separation between the registration offices 405, 420, the certificate offices 430, 440, and the combining offices 450, 460.

[0104] In a preferred implementation, the database 470 is a collection consisting of one or more high - speed access, low - latency databases. In some implementations, the database 470 may be a NoSQL database, or, for example, a database service such as the DynamoDB data service provided by Amazon Web Services. In various implementations, the data stored in the database 470 depends on the application, but may include past issued certificates, values of various combining offices, data regarding the devices on which certificates were issued, actions of operators, etc. Note that the data may be stored in an unencrypted state, an encrypted state, or a combination of these states.

[0105] In various implementations, the digital certificates created by the registration office 405 are split into separate parts, for example, into a joining digital certificate and an anonymous digital certificate, so the extensible CMS 400 includes a joining certificate office 430 and an anonymous certificate office 440.

[0106] Since there may be multiple instances of the enrollment certificate authority 430 that execute simultaneously, the enrollment certificate authority 430 is a non-central component of the CMS 400. As shown by the three "stacked" rectangles in Figure 4A for the enrollment certificate authority 430, in some implementations, there may be multiple instances of the enrollment certificate authority 430 that execute simultaneously. The enrollment certificate authority 430 can receive a request for an enrollment certificate from the registration authority 420. The first role of the enrollment certificate authority 430 is to fulfill the request from the registration authority 420 and issue an enrollment certificate to an end-user device, such as the distributor device 108 of the manufacturer 105 shown in FIG. 1. As will be described later with reference to FIG. 5A, the enrollment certificate authority 430 communicates directly with the registration authority 420 in order to perform its role within the CMS 400.

[0107] The anonymous certificate authority 440 is a non-central component of the CMS 400, and there may be multiple instances of the anonymous certificate authority 440 that execute simultaneously. To reiterate, as shown by the three "stacked" rectangles in Figure 4A for the anonymous certificate authority 440, in various implementations, there may be multiple instances of the anonymous certificate authority 440 that execute in parallel simultaneously. The anonymous certificate authority 440 can receive a request for an anonymous certificate from the registration authority 420. The first role of the anonymous certificate authority 440 is to fulfill the request from the registration authority 420 and issue an anonymous certificate to an end-user device, such as the distributor device 108 of the manufacturer 105 shown in FIG. 1. In some implementations, the anonymous certificate authority 440 fulfills requests for short-term anonymous certificates for V2V functionality. As will be described later with reference to FIG. 5B, the anonymous certificate authority 440 communicates directly with the registration authority 420 in order to perform its function within the CMS 400.

[0108] In various implementations, the binding stations 450, 460 shown in FIG. 4B associate the identification information of the certificate requester (i.e., the unique identifier of the certificate requester's device) with the issued anonymous certificate for cancellation purposes. That is, the binding station 1 450 and the binding station 2 460 each provide their respective binding values to the issued anonymous certificate as the unique identifier of the certificate requester's device. The binding station 1 450 and the binding station 2 460 can receive a request for obtaining a binding value from the registration station 420 and then provide the requested binding value to the registration station 420. As will be described later with reference to FIG. 5A, the binding stations 450, 460 communicate directly with the registration station 420 to fulfill the request for the binding value.

[0109] In various implementations, since the computing engines 425, 435, 445, 455, and 465 and the provisioning controller 120 include an HSM, these components can perform secure computations without being unduly threatened by hackers. In some implementations, the computing engines 425, 435, 445, 455, and 465 may be designed to perform secure computations autonomously without requiring an embedded HSM, and in such implementations, the computing engine embodies the HSM.

[0110] In various implementations, various HSM versions may be used in the CMS 400. For example, the HSM may include an embedded HSM that is attached as a plug-in card in any one or more of the computing engines 425, 435, 445, 455, and 465. In such an exemplary implementation, the embedded HSM may be attached to any one or more of the computing engines as a Peripheral Component Interconnect (PCI) HSM or as a PCI Express (PCIe) HSM. Also, for example, the HSM within the CMS 400 may also include a network-attached or network-connected external HSM that is housed in a dedicated enclosure and is independent of the computing engine.

[0111] Those skilled in the art will appreciate that the components, processes, data, steps, and implementation details shown in Figures 4A and 4B are examples presented for simplicity and clarity of explanation. This example is not intended to be limiting, and since numerous variations are possible, other components, processes, implementation details, and variations may be used without departing from the principles of the invention.

[0112] Both FIG. 5A and FIG. 5B show a method for transmitting credentials, such as a certificate, consistent with an implementation of the present invention. FIG. 5 is a swim lane diagram illustrating an example process 500 for secure provisioning. In various implementations, some or all of the illustrated process 500 or steps may be performed by code executing on a general-purpose 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 across the top of FIGS. 5A and 5B, the entities involved in the process 500 include a distributor device 108 at the manufacturer 105, a registration authority 420 at the CMS host, binding authorities 450, 460, an anonymous certificate authority 440, and a subscription certificate authority 430. In various implementations, these entities may be as described with respect to FIGS. 4A and 4B and as described throughout this disclosure, and may communicate with each other.

[0113] As shown in the example of Figure 5A, process 500 begins with subscription-related steps 505-535. The primary role of subscription certificate authority 430 is to fulfill requests from registration authority 420 to issue subscription certificates to end-user devices, such as distributor device 108. As described below with reference to subscription-related steps 505-535, subscription certificate authority 430 interacts directly with registration authority 420 to issue requested subscription certificates to distributor device 108.

[0114] At 505, the distributor device 108 of manufacturer 105 requests the registration authority 420 to register a certificate of membership that is provisioned to (e.g., used by) device 106a. This request can identify device 106a, which is the destination of the certificate of membership. The request may be, for example, the distributor device 108 of manufacturer 105 requesting a certificate of membership for a new device 106A (e.g., a new product). As described above with reference to FIG. 2, the certificate of membership is a public key certificate that identifies its holder as an authorized participant within the ecosystem. In this ecosystem, all participants must share a valid certificate of membership. (For example, in the V2X ecosystem of the U.S. Department of Transportation), authorized participants may also receive an anonymous certificate that enables communication and processes of device 106 within the ecosystem (e.g., in the example of the V2X ecosystem of the U.S. Department of Transportation, to enable communication and processes between vehicles and roadside infrastructure).

[0115] At 510, a request for a membership certificate is received at the registration office 420 and then sent from the registration office 420 to the membership certificate office 430. In various implementations, this process may involve the registration office 420 decrypting and verifying the request, such as verifying signatures, checking the revocation status of the device (e.g., device 106a) that the membership certificate is destined for using a list of unauthorized devices (e.g., a blacklist), and determining whether the requester (e.g., the distributor device 108) is able to request a membership certificate from the registration office 420. For example, step 510 may include determining whether the user of the manufacturer 105 is an authorized user (e.g., a member of the staff 109). In some implementations, the registration office 420 may also determine at 510 whether the device 106a (e.g., the product) that will receive the membership certificate is approved for use in the system 100. Optionally, a list of approved devices (e.g., a whitelist) may be provided by the coordinator 140 of FIG. 1 and used by the provisioning controller 120 to make this determination. After the request for the membership certificate is verified, the request is sent from the registration office 420 to the membership certificate office 430. This request may be sent as a membership certificate generation request created by the registration office 420.

[0116] At 515, the request for the membership certificate is received at the membership certificate office 430. In response to receiving the request, at 520, the membership certificate office 430 generates the requested membership certificate and sends the generated membership certificate back to the registration office 420. At 525, the membership certificate is received at the registration office 420, and at 53 0, the registration office 420 sends the membership certificate to the distributor device 108. At 535, the distributor device 108 receives the membership certificate. At this point, the distributor device 108 can provision the membership certificate to a device (e.g., device 106a), thereby enabling the device to use the membership certificate and completing the membership-related process.

[0117] Steps 540 to 599 relate to the provisioning of anonymous certificates. In step 540, the distributor device 108 requests anonymous certificates from the registration authority 420. These anonymous certificates are to be provisioned to device 106a (e.g., used by device 106a), and this request can identify device 106a, which is the destination of the anonymous certificates. The request may be, for example, the distributor device 108 of manufacturer 105 requesting anonymous certificates for a computerized device (e.g., enrolled device 106A) that has previously received an enrollment certificate. The anonymous certificates include a certain quantity (e.g., for one week, one month, or one year) of public key certificates.

[0118] In step 545, the request for anonymous certificates is received at the registration authority 420, and the registration authority 420 then initiates the provisioning of the anonymous certificates.

[0119] In steps 550 to 570, the combining authorities 450, 460 communicate directly with the registration authority 420 to fulfill the request for combined values. In step 550, the registration authority 420 sends a request to combining authority 1 450 to obtain a first set of combined values (LA1).

[0120] In step 555, in response to receiving the request for the first set of combined values, combining authority 1 450 generates the first set of combined values and sends it to the registration authority 420. In step 557, the first set of combined values is received at the registration authority 420. In step 560, the registration authority 420 sends a request to combining authority 2 460 to obtain a second set of combined values (LA2).

[0121] Next, as shown in Figure 5B, in step 565, in response to receiving the request for the second set of combined values, combining authority 2 460 generates the second set of combined values and sends it to the registration authority 420. In step 570, the second set of combined values is received at the registration authority 420.

[0122] In some implementations, the linkage authorities 450, 460 shown in FIGS. 5A and 5B can be associated with an issued anonymous certificate for the purpose of revocation with the identity information of the certificate requester (i.e., the unique identifier of the certificate requester's device). That is, Linkage Authority 1 450 and Linkage Authority 2 460 each provide, as the unique identifier of the certificate requester's device, a first and a second set of linkage values to an anonymous certificate issued by the anonymous certificate authority 440 as part of process 500. Linkage Authority 1 450 and Linkage Authority 2 460 receive requests for linkage values sent from the registration authority 420 in steps 550 and 560, and then provide the requested linkage values to the registration authority 420 in steps 555 and 565.

[0123] In a non-limiting exemplary implementation, the requests for linkage values exchanged in steps 550-570 and the responses to those requests may include messages having the following header fields and payload data fields. # Registration Authority(RA)->Linkage Authority-x(LA-x):Initial Linkage Seed Request { header:{ msgID:mt.MSG_RA_LA_LINKAGE_SEED_REQUEST_MSG, taskPosition:‘‘Linkage Authority number 1 or 2’’ }, payload:{ identifier:‘‘Message identifier’’, iMin:Number, iMax:Number, jMax:Number } } # LA-x->RA:Initial Linkage Seed Response { header:{ msgID: mt.MSG_LA_RA_LINKAGE_SEED_RESPONSE_MSG, taskPosition: ‘‘Linkage Authority number 1 or 2’’ }, payload: { identifier: ‘‘Incoming Message identifier’’, linkageChainIdentifier: ‘‘Linkage Chain ID--HashedId8 of AES CCM Encrypted Linkage Seed’’, iMin: Number, iMax: Number, jMax: Number } } # RA->LA-x: PreLinkage Value Chain Request(Chunked 10 iRange at a time){ header: { msgID: mt.MSG_RA_LA_PRE_LINKAGE_VALUE_REQUEST_MSG, iRangeSegmentChunkSize: ‘‘set to 10’’, currentIRangeSegment: ‘‘Index of segment in total request’’, taskPosition: ‘‘Linkage Authority number 1 or 2’’ }, payload: { identifier: ‘‘Incoming Message identifier’’, linkageChainId: ‘‘Linkage Chain ID to use to create P Linkage Values(PLVs)’’, iMin: Number, iMax: Number, jMax: Number } } # LA-x->RA: PreLinkage Value Chain Response { header: { msgID: mt.MSG_LA_RA_PRE_LINKAGE_VALUE_RESPONSE_MSG, iRangeSegmentChunkSize: ‘‘set to 10’’, currentIRangeSegment: ‘‘Index of segment in total request’’, taskPosition: ‘‘Linkage Authority number 1 or 2’’ }, payload: { identifier: ‘‘Incoming Message identifier’’, preLinkageValues: Array of Encryped Prelinkage values for this segment of i,j tuples, linkageChainIdentifier: ‘‘Linkage Chain ID to use to create P Linkage Values(PLVs)’’, iMin: Number, iMax: Number, jMax: Number } }

[0124] Continuing to refer to FIG. 5B, at 575, the registration office 420 sends a request for an anonymous certificate to the anonymous certificate authority 430. This request may be sent as a batch of anonymous certificate generation requests created by the registration office 420.

[0125] At 580, a request for an anonymous certificate is received at the anonymous certificate authority 430. In response to receiving the request, at 585, the anonymous certificate authority 430 generates the requested anonymous certificate and sends the generated anonymous certificate back to the registration authority 420. At 590, the anonymous certificate is received at the registration authority 420.

[0126] At 595, the distributor device 108 can send multiple requests to the registration authority 420 to inquire whether the requested anonymous certificate is ready (i.e., generated and available for use). In some implementations, the inquiry in step 595 may be sent at any time after the request for the anonymous certificate is sent in step 540. For example, after sending a request for an anonymous certificate to the registration authority 420 in step 540, the distributor device 108 can periodically send inquiries to the registration authority 420 to determine whether the requested anonymous certificate is ready. In this example, any one or more of the inquiries in step 595 may be sent in parallel with steps 545 - 590 (i.e., while the anonymous certificate is being generated).

[0127] At 598, when the anonymous certificate is ready, the registration authority 420 sends the anonymous certificate to the distributor device 108. At 599, the distributor device 108 receives the anonymous certificate. At this point, the distributor device 108 can provision the anonymous certificate to a device (e.g., device 106a), thereby enabling the device to use the anonymous certificate, and the process of provisioning the anonymous certificate is completed.

[0128] In some non - limiting exemplary implementations, the requests for anonymous certificates and the responses to those requests exchanged in steps 575 - 590 may include messages having the following header items and payload data items. # Registration Authority(RA)->Pseudonym Certificate Authority(PCA):Generate an individual Certificate { header:{ msgID: mt.MSG_RA_PCA_CERT_REQUEST_MSG, iRangeSegmentChunkSize: ‘‘set to 10’’ }, payload: { identifier: ‘‘hash of payload minus this field’’ i: Number, plv1: ‘‘Encrypted PLV from LA1’’, plv2: ‘‘Encrypted PLV from LA2’’, seedPublicKey: ‘‘Seed Verify Public key’’, encryptKey: ‘‘Seed Encrypt Public key’’, startSeconds: ‘‘start time for this certificate’’, endSeconds: ‘‘end time for this certificate’’, region: ‘‘requested region’’, certRequestPermissions: ‘‘the cert request permissions from the enrollment cert(will be turned into app permissions)’’ } } # PCA->RA:Certificate Response { header: { msgID: mt.MSG_PCA_RA_IDENTITY_CERT_RESPONSE_MSG }, payload: { data: ‘‘Signed and Encrypted SCMS certificate response’’, identifier: ‘‘hash of original payload request’’ } }

[0129] Both FIGS. 6A and 6B are block diagrams of an exemplary architecture implementing an extensible and secure CMS600 with bidirectional message queues 610, 611, 612, 613, 614, 615, 616, 617, 618, 619 that conform to the implementation of the present invention.

[0130] Similar to the CMS400 described above with reference to FIGS. 4A and 4B, various implementations of the extensible CMS600 may be utilized for ultra-large-scale device transactions and certificate generation processes. In some implementations, the extensible CMS600 may be implemented using multiple servers, HSMs, multiple computing engines or computing engines, and multiple application platforms (e.g. For example, a VM or a hardware platform). In the exemplary implementation shown in FIGS. 6A and 6B, the application platform may each include one or more virtual machines (VMs). In additional or alternative implementations, the application platform may each include one or more hardware platforms, such as servers, computers, or other computer hardware capable of running software applications, etc. Examples of the extensible CMS600 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. For the sake of brevity, only the differences between FIGS. 6A and 6B compared to FIGS. 4A and 4B will be described below.

[0131] As shown in the example of FIG. 6A, the architecture of the CMS600 may desirably include two provisioning controllers 602 implemented on separate servers, namely a primary provisioning controller and a standby provisioning controller. Since the two provisioning controllers 602 include functions similar to those of the provisioning controller 102 in FIG. 4A, objects, data, etc. accommodated in the primary provisioning controller are copied or accommodated in the standby (secondary) provisioning controller for the purpose of failover, as described above with reference to FIG. 4A. In some implementations, the provisioning controller 602 may be a DLM controller, for example, a primary and standby DLM controller. In various implementations, the provisioning controller 602 may be a controller existing for each of the various components within the CMS600. In the examples of FIGS. 6A and 6B, the provisioning controller 602 may be a pair of controllers (for example, primary and standby) existing for the registration authority 620, the certificate-issuing authority 430, the anonymous certificate authority 440, and the combining authorities 450, 460.

[0132] As shown in FIGS. 6A and 6B, the architecture of the extensible CMS600 includes a registration authority 605 implemented as a REST web service, a registration authority 620, a registration authority computing engine 625, a certificate-issuing authority 630, a certificate-issuing authority computing engine 635, an anonymous certificate authority 640, an anonymous certificate authority computing engine 645, a combining authority 1 650, a combining authority 1 computing engine 655, a combining authority 2 660, a combining authority 1 computing engine 665, bidirectional message queues 610, 611, 612, 613, 614, 615, 616, 617, 618, 619, and a database 670.

[0133] The architecture of the extensible CMS600 advantageously separates non-security-related applications from security functions. As shown in the non-limiting examples of FIGS. 6A and 6B, the registration office 620, the membership certificate office 630, the anonymous certificate office 640, and the binding offices 650, 660 are all implemented as applications on their respective VMs that run on their respective dedicated computing engines 625, 635, 645, 655, and 665 independent of non-security-related applications and functions. This provides both technical and security advantages and advancements that exceed conventional systems where the performance of the HSM is slow, or the cloud service provider cannot supply the HSM, or its proper HSM management is uncertain. In the extensible CMS600, all cryptographic operations that require an HSM are performed by a computing engine (e.g., any one or more of computing engines 625, 635, 645, 655, and 665). That is, in the CMS600, all cryptographic operations that require an HSM are performed by a computing engine.

[0134] As shown in FIGS. 6A and 6B, by separating important security functions from each other and also separating them into separate computing engines, cryptographic functions and security functions with a large amount of computation performed, for example, by the registration office 620, the membership certificate office 630, the anonymous certificate office 640, and the binding offices 650, 660, are performed much faster than in existing registration office systems. This design enables a significant improvement in transaction processing by making it possible to individually extend the "bottleneck" applications as needed. For example, when the registration office applications running on registration offices 605 and 620 need to be extended, an additional application platform (e.g., a VM or a hardware platform) can be added without the need to modify the secure computing capabilities of the registration office computing engine 625. Also, for example, when security computations are limiting performance, an additional secure registration office computing engine 625 can be added. The same multi-dimensional extension applies to other components of the CMS600.

[0135] In the examples shown in FIGS. 6A and 6B, the registration office 605 is connected to other components by bidirectional message queues 610, 611, 612, 613, 614, 615, 616, 617, 618, and 619, and the other components are connected to each other. In the exemplary implementation of FIGS. 6A and 6B, since the bidirectional message queues 610, 611, 612, 613, 614, 615, 616, 617, 618, and 619 are bidirectional, messages flow in both directions within these queues (e.g., between a client and a server). This provides a performance advantage of separating new requests from responses that are pending within the message queues. By using the bidirectional message queues 610, 611, 612, 613, 614, 615, 616, 617, 618, 619 to connect an application platform (e.g., a VM and / or a hardware platform) and a computing engine so that they can communicate with each other, the application platform (e.g., a VM and / or a hardware platform) and the computing engine can be individually scaled. In the CMS600, the application platforms (e.g., VMs and / or hardware platforms) of the registration office 620, the membership certificate office 630, the anonymous certificate office 640, and the combination offices 650, 660 are connected to the computing engines 625, 635, 645, 655, and 665 so that they can communicate through their respective sets of bidirectional message queues.

[0136] In the CMS600, the registration office 605 (as well as the other components in FIGS. 6A and 6B indicated by the "DB" arrow) may be connected to the database 670. In a preferred implementation, the database 670 is a high-speed access and low-latency database. In some implementations, the database 670 may be a NoSQL database, or, for example, a database service such as the DynamoDB data service provided by Amazon Web Services. In various implementations, the data stored in the database 670 depends on the application, but may include issued certificates, values of various combining stations (e.g., combined values), data related to the device on which the certificate was issued, actions of the operator, etc. The data may be stored in an unencrypted state, an encrypted state, or a combination of these states.

[0137] In various implementations, the digital certificates created by the registration office 605 are split into separate segments, e.g., subscriber digital certificates and anonymous digital certificates, so the extensible CMS600 includes a subscriber certificate office 630 and an anonymous certificate office 640.

[0138] As shown by the three "stacked" rectangles for the subscriber certificate office 630 in FIG. 6A, in some implementations, there may be multiple instances of the subscriber certificate office 630 running simultaneously. This is also represented in the same way for the other "stacked" elements in FIGS. 6A and 6B. The subscriber certificate office 630 may receive multiple requests for subscriber certificates from the registration office 620.

[0139] In various implementations, since the computing engines 625, 635, 645, 655, and 665 and the provisioning controller 602 include an HSM, these components It can perform secure calculations without being unduly threatened by hackers. In some implementations, the calculation engines 625, 635, 645, 655, and 665 may be designed to perform secure calculations autonomously without requiring an embedded HSM. In such implementations, the calculation engine embodies the HSM.

[0140] Those skilled in the art will recognize that the components, processes, data, steps, and implementation details shown in FIGS. 6A and 6B are examples presented to simplify and clarify the description. This example is not intended to be limiting, and since numerous variations are possible, other components, processes, implementation details, and variations can be used without departing from the principles of the present invention.

[0141] Both FIGS. 7A and 7B are block diagrams of an exemplary architecture implementing an extensible and secure CMS 700 with load balancers 710, 711, 712, 713, 714, 715, 716, 717, 718, 719 that conform to an implementation of the present invention.

[0142] Similar to the CMS 400 and 600 described above with reference to FIGS. 4 and 6, various implementations of the extensible CMS 700 may be utilized for ultra-large-scale device transactions and certificate generation processes. For the sake of brevity, only the differences between FIGS. 7A and 7B compared to FIGS. 4 and 6 will be described below. In the exemplary implementations shown in FIGS. 7A and 7B, the application platform is shown as including one or more virtual machines (VMs). In additional or alternative implementations, the application platform may each include one or more hardware platforms, such as application servers, server farms, cloud-based servers, processors configured to perform application steps, or other computer hardware capable of executing software applications, and the like.

[0143] As shown in the example of FIG. 7A, the architecture of the CMS700 may desirably include two provisioning controllers 702 implemented on separate servers, namely a primary provisioning controller and a standby provisioning controller. Each of the two provisioning controllers 702 includes functions similar to those of the provisioning controllers 120 and 602 in FIGS. 4A and 6A. That is, as described above with reference to FIG. 4A, objects, data, etc. accommodated in the primary provisioning controller are copied or accommodated in the standby (secondary) provisioning controller for the purpose of failover.

[0144] As shown in FIGS. 7A and 7B, the architecture of the extensible CMS700 includes a registration office 705 implemented as a REST web service, a registration office 720, a registration office computing engine 725, an affiliation certificate office 730, an affiliation certificate office computing engine 735, an anonymous certificate office 740, an anonymous certificate office computing engine 745, an association office 1 750, an association office 1 computing engine 755, an association office 2 760, an association office 1 computing engine 765, load balancers 710, 711, 712, 713, 714, 715, 716, 717, 718, 719, and a database 770.

[0145] Similar to the CMS400 and CMS600 in FIGS. 4 and 6, the architecture of the extensible CMS700 advantageously separates non-security related applications from security functions. As shown in the non-limiting examples of FIGS. 7A and 7B, the registration office 720, the affiliation certificate office 730, the anonymous certificate office 740, and the association offices 750, 760 are each implemented as applications on their respective VMs running on their respective dedicated computing engines 725, 735, 745, 755, and 765 independent of non-security related applications and functions. In the extensible CMS700, all cryptographic operations that require an HSM are performed by a computing engine (e.g., any one of the computing engines 725, 735, 745, 755, and 765 or more). In the CMS700, all cryptographic operations that require an HSM are performed by a computing engine.

[0146] As shown in FIGS. 7A and 7B, by separating important security functions from each other and also separating them into separate computing engines, for example, cryptographic functions and security functions with a large number of calculations performed by the registration office 720, the certificate-issuing office 730, the anonymous certificate office 740, and the combining offices 750, 760 are performed much faster than known registration office solutions. This design is not restricted by the processing capacity or storage capacity of the server, and enables a significant improvement in transaction processing by making it possible to individually expand "bottleneck" applications as needed. For example, when the registration office applications executed by the registration offices 705 and 720 need to be expanded, an additional application platform (for example, a VM or a hardware platform) can be added, and there is no need to change the secure computing capacity of the registration office computing engine 725. Also, for example, when security calculations are limiting performance, additional secure registration office computing engines 725 can be added. The same multi-dimensional expansion also applies to other components of the CMS 700.

[0147] In the examples shown in FIGS. 7A and 7B, the registration office 705 is connected to other components by load balancers 710, 711, 712, 713, 714, 715, 716, 717, 718, and 719, and the other components are connected to each other. In the exemplary implementation of FIGS. 7A and 7B, the load balancers 710, 711, 712, 713, 714, 715, 716, 717, 718, and 719 may be implemented as virtual load balancers (e.g., running on a VM) or by dedicated hardware. As seen in FIGS. 7A and 7B, in the CMS700, each of the load balancers 710, 711, 712, 713, 714, 715, 716, 717, 718, and 719 is inserted in front of each group consisting of similar types of VMs or computing engines. This provides the advantage of making only a single server endpoint recognizable to one or more clients and having the load balancer determine which server processes a particular request. In this way, the load balancers 710, 711, 712, 713, 714, 715, 716, 717, 718, 719 connect the application platform (e.g., VM and / or hardware platform) and the computing engine so that they can communicate with each other. In the CMS700, the application platforms of the registration office 720, the membership certificate office 730, the anonymous certificate office 740, and the combination offices 750, 760 are connected through their respective load balancer sets so that they can communicate with the computing engines 725, 735, 745, 755, and 765.

[0148] In various implementations, the digital certificates created by the registration office 705 are split into separate parts, for example, membership digital certificates and anonymous digital certificates, so the extensible CMS700 includes a membership certificate office 730 and an anonymous certificate office 740.

[0149] As shown by the three "stacked" rectangles in FIG. 7A for the anonymous certificate authority 740, in various implementations, there may be multiple instances of the anonymous certificate authority 740 running simultaneously. This is also represented similarly for the other "stacked" elements in FIGS. 7A and 7B. The anonymous certificate authority 740 may receive from the registration authority 720 multiple requests for a batch of anonymous certificates (e.g., requests for anonymous certificates for one week, one month, or one year).

[0150] Those skilled in the art will recognize that the components, processes, data, steps, and implementation details shown in FIGS. 7A and 7B are examples presented for the sake of brevity and clarity of the description. This example is not intended to be limiting, and since numerous variations are possible, without departing from the principles of the present invention, other components, processes, implementation details, and variations can also be used.

[0151] FIG. 8 is a block diagram of an example of a system 800 implementing an extensible and secure CMS with round-robin requests that conforms to an implementation of the present invention. For simplicity, FIG. 8 shows only one set of application platforms (e.g., VM and / or hardware platforms) 820, 830, 840, 850 and one set of computing engines 825, 835, 845, 855. Note that the application platforms 820, 830, 840, 850 and the computing engines 825, 835, 845, 855 in FIG. 8 can be any one set of application platforms and computing engines used to implement any of the registration authority 720, the membership certificate authority 730, the anonymous certificate authority 740, and the combining authorities 750, 760 described above with reference to FIG. 7. Similar to the CMS 700 in FIG. 7, in the system 800, all cryptographic operations that require an HSM are performed by the computing engine, and both the application platform and the computing engine can be individually extended.

[0152] Continuing to refer to FIG. 8, round robin refers to using knowledge about each available server (e.g., each computing engine). The round robin requests sent in system 800 use knowledge about the available computing engines (e.g., computing engines 825, 835, 845, 855) to distribute requests and messages sent to that one set of computing engines.

[0153] To clearly illustrate the order of round robin requests in system 800, an expanded one set of computing engines 865, 875, 885, 895 available in application VM 850 is shown. In the example of FIG. 8, there are "n" application platforms (e.g., VMs and / or hardware platforms), and "m" available computing engines. A client (e.g., application VM 895) that wants to make a request to a computing engine does so in the order shown in FIG. 8. As shown, the first request from application VM 895 goes to CE1 (computing engine 865), the second request goes to CE2 (computing engine 875), and so on. When reaching the last CE, CEm (computing engine 895), the client (application VM 895) starts over from CE1.

[0154] In system 800, all clients (e.g., application platforms 820, 830, 840, 850) recognize all the servers (e.g., one set of available computing engines) with which they need to communicate. Each client makes a round robin request to each server, and thereby the workload is advantageously evenly distributed across all the servers. In some implementations, to evenly distribute the workload across the computing engines, the load balancers 710, 711, 712, 713, 714, 715, 716, 717, 718, 719 of CMS 700 shown in FIG. 7 can send round robin requests to the computing engines.

[0155] FIG. 9 is a block diagram of an example of a system 900 that implements an extensible and secure CMS with requirements based on workload that is consistent with the implementation of the present invention. For the sake of brevity, only the differences between FIG. 9 and FIGS. 7 and 8 will be described below.

[0156] Similar to FIG. 8, for simplicity and clarity, only one set of application platforms 920, 930, 940, 950 and one set of computing engines 925, 935, 945, 955 are shown in FIG. 9. Note that the application platforms (e.g., VMs and / or hardware platforms) 920, 930, 940, 950 and computing engines 925, 935, 945, 955 in FIG. 9 are the same as those described above with reference to FIG. 7 and may be any one of a set of application platforms and computing engines used to implement any of the registration authority 720, the membership certificate authority 730, the anonymous certificate authority 740, and the combining authorities 750, 760. Similar to the CMS 700 in FIG. 7, in the system 900, all cryptographic operations that require an HSM are performed by the computing engine, and both the application platform (e.g., VM and / or hardware platform) and the computing engine can be individually extended.

[0157] Continuing to refer to FIG. 9, the workload distribution method is made possible by adding information about the workload of each server used to the first query. This workload distribution method is a workload-based method because it utilizes knowledge about the workload of each available server (e.g., each computing engine). The requests sent in the system 900 use knowledge about the current workload of the available computing engines (e.g., computing engines 925, 935, 945, 955) to distribute the requests and messages sent to that one set of computing engines. In the system 900, requests are sent to the computing engines based on the reported workload of each computing engine.

[0158] To clearly illustrate the requirements based on the workload in system 900, an extended set of one or more computing engines 965, 975, 985, 995 that report their respective workloads to application VM 950 is shown. In the example of FIG. 9, "m" is the number of application platforms and "n" is the number of computing engines that report their respective workloads. In the example of FIG. 9, the workload is reported as a percentage. A 30% workload for computing engine 975 means that computing engine 975 is currently operating at 30% of its full capacity. Similarly, an 80% workload reported by computing engines 965, 985, and 995 means that these computing engines are currently operating at 80% of their full capacity. In some implementations, the current workload reported by a particular computing engine represents the workload of the HSM incorporated in that computing engine. For example, when performing cryptographic operations, if the processing capacity of the computing engine is bound or restricted by the capacity of its HSM, the percentage of the workload reported by that computing engine can reflect the current workload of the HSM. For example, if the HSM used by computing engine 975 is operating at 30% of its processing capacity, computing engine 975 can report that it is operating at 30% of its full capacity. In some implementations, the workload percentage may be a weighted measure of the processing capacity of the server (e.g., the computing engine), the communication capacity (e.g., a measure of the bandwidth available for a direct communication link or a wireless module), and the storage / memory capacity. In one example, equal one-third weights may be given to the processing capacity, the communication capacity, and the memory capacity. In this example, if computing engine 975 is using 25% of its central processing unit (CPU) capacity, 35% of its communication capacity, and 30% of its available memory or storage, computing engine 975 reports that its workload is 30%.

[0159] In some implementations, the environmental measurement values of the computing engine may be weighted and considered in conjunction with the measurement values of the workload. For example, a measurement value indicating the overall health of the computing engine may be determined and reported together with the measurement value of the workload of the computing engine. In some examples, the measurement value indicating the health of a particular computing engine may be the operating temperature of the computing engine (e.g., a temperature value higher than the average from a temperature sensor may indicate that the CPU, memory module, or disk drive may be at risk of thermal shutdown or malfunction), the humidity level within the housing of the computing engine, the frequency of restarts or reboots (e.g., thermal shutdowns or crashes), the elapsed time since the last restart, the number of disk failures or memory errors that occurred during a recent period (e.g., the previous day, week, or month), the time until the next scheduled maintenance operation for the computing engine (e.g., software or firmware updates, replacement of defective hardware components), information indicating that the computing engine is operating on backup power, or any one or more functions of the duration since the last power outage or voltage drop of the power supply of the computing engine. It may be any one or more functions of

[0160] In additional or alternative implementations, other weights, metrics, and criteria may be used to determine the workload of the computing engine. For example, if a computing engine performing cryptographic operations has been subject to greater constraints from CPU capabilities than from communication capabilities or memory capacity, a greater weight can be given to CPU capabilities when calculating the total workload percentage for those computing engines.

[0161] In system 900, a client (e.g., application VM 995) that wants to make a request to a compute engine does so based on the workload reported by the compute engine. In the example of FIG. 9, the next request from application VM 995 goes to CE2 (compute engine 975) based on a relatively low workload of 30%. That is because the workload of compute engine 975 is the lowest among one set of compute engines 965, 975, 985, 995. When the next request is sent from application VM 995 to a compute engine, any of CE1 (compute engine 965), or CE3 (compute engine 985), or CEm (compute engine 995), which are currently reporting an equal 80% workload, may be used. If each available compute engine reports the same or a similar workload, a series of requests can be used to evenly distribute the load across these compute engines with equal load. That is, if each available compute engine reports a substantially equal or equal workload, the requests described above with reference to FIG. 8 can be used. As the workload changes over time, the client (application VM 995) sends subsequent requests to the available compute engine with the lowest load.

[0162] In system 900, all clients (e.g., application platforms 920, 930, 940, 950) are aware of the workload of all the servers (e.g., one set of available compute engines) with which they need to communicate. Each client submits a workload query to each server and can advantageously and evenly distribute the workload across all servers based on the reported workload. In some implementations, to evenly distribute the workload across compute engines, the load balancers 710, 711, 712, 713, 714, 715, 716, 717, 718, 719 of CMS 700 shown in FIG. 7 can send requests based on the workload to the compute engines.

[0163] FIG. 10A and FIG. 10B are both block diagrams of an exemplary architecture implementing an extensible and secure Certificate Management System (CMS) 400 according to the implementation of the present invention. For the sake of brevity, only the differences between FIGS. 10A and 10B compared to FIGS. 4A and 4B will be described below.

[0164] As shown in the example of FIG. 10A, the architecture of CMS 1000 may include two provisioning controllers 1002, desirably implemented on separate servers, namely a primary provisioning controller and a standby provisioning controller. The two provisioning controllers 1002 each include functions similar to the provisioning controllers 120 and 602 of FIGS. 4A and 6A. That is, as described above with reference to FIG. 4A, objects, data, etc. housed in the primary provisioning controller are copied or housed in the standby (secondary) provisioning controller for failover purposes.

[0165] As shown in FIGS. 10A and 10B, the architecture of CMS 1000 includes a registration authority 1005, a registration authority 1020, computing engines 1025, 1035, 1045, 1050, 1060, message queues 1010, 10 12, 1014, 1016, 1018, implemented as REST web services, and a database 1070.

[0166] Examples of the CMS1000 may be implemented in a private data center, a cloud data center, or a hybrid of a private data center and a cloud data center. The various implementations of the CMS1000 may be utilized for ultra-large device transactions and certificate generation processes. In the various implementations, the CMS1000 may be implemented using a plurality of servers, HSMs, and a plurality of computing engines or computing engines that function as an application platform. That is, as shown in FIGS. 10A and 10B, the illustrated applications of the registration office, the certificate office, and the combination office each operate one or more computing engines capable of hosting and executing software applications.

[0167] The CMS1000 is similar to the CMS400 described above with reference to FIGS. 4A and 4B, the difference being that the computing engines 1025, 1035, 1045, 1050, 1060 are used to host and execute the application. That is, the CMS1000 architecture is an alternative to the CMS400 architecture, and the applications of the registration office, the membership certificate office, the anonymous certificate office, and the combination office are executed on their respective dedicated computing engines 1025, 1035, 1045, 1050, 1060. In the CMS1000, all cryptographic operations that require an HSM are performed by the computing engines (e.g., computing engines 1025, 1035, 1045, 1050, and 1060), and the computing engines also execute the related applications. Advantageously, by executing the application and the cryptographic operations on the computing engines 1025, 1035, 1045, 1050, 1060, the CMS1000 architecture reduces the number of required message queues.

[0168] In the examples of FIGS. 10A and 10B, the computing engine includes a registration authority computing engine 1025 that hosts and executes the registration authority application, a certificate authority computing engine 1035 that functions to host and execute the certificate authority application, an anonymous certificate authority computing engine 1045 that functions to host and execute the anonymous certificate authority application, a combining station 1 computing engine 1050 that hosts and executes the combining station 1 application, and a combining station 2 1060 that functions to host and execute the combining station 2 application.

[0169] As shown in FIGS. 10A and 10B, the registration authority 1005 is connected to other components by a messaging subsystem or message queuing service that includes input message queues 1010, 1012, 1014, 1016, 1018, and the other components are connected to each other. In the exemplary implementation of FIGS. 10A and 10B, since the input message queues 1010, 1012, 1014, 1016, 1018 are unidirectional, messages flow in one direction (e.g., from the client to the server) through these queues. This provides a technical advantage of simplicity by providing a single input queue for each of the computing engines that host and execute the respective applications.

[0170] By connecting the computing engines to communicate with each other using the input message queues 1010, 1012, 1014, 1016, 1018, the computing engines can be individually extended as needed. That is, each computing engine that serves as an application platform for the registration authority, certificate authority, anonymous certificate authority, and combining station applications is connected to be communicable through its respective input message queue, so that these components of the CMS 1000 and the database 1070 can all be individually extended from each other.

[0171] FIG. 11 is a block diagram of an example of a computing environment 1101 that includes a computing system 1100 that may be used to implement a system and method consistent with the implementation of the present invention. Other components and / or mechanisms may be used. In some implementations, the computing system 1100 may be used to at least partially implement various components of FIGS. 1-10, such as, among other things, the provisioning controller 120, DAMS 110, and computing engines of FIGS. 4 and 6-10, and the load balancers 710-719 of FIG. 7. In some implementations, a series of computing systems similar to the computing system 1100 may be customized individually with special hardware and / or programmed individually as special servers to implement any one of the components of FIGS. 1-10, and these components may communicate with each other through the network 1135. In some implementations, the computing system 1100 may be used to at least partially implement various components of FIGS. 1-10, such as, among other things, the provisioning controller 120, DAMS 110, and computing engines of FIGS. 4 and 6-10, and the load balancers 710-719 of FIG. 7. In some implementations, a series of computing systems similar to the computing system 1100 may be customized individually with special hardware and / or programmed individually as special servers to implement any one of the components of FIGS. 1-10, and these components may communicate with each other through the network 1135.

[0172] In the example shown in FIG. 11, computing system 1100 includes a number of components such as CPU 1105, memory 1110, input / output (I / O) device 1125, hardware security module (HSM) 1140, non-volatile storage device 1120, and so on. System 1100 may be implemented in various forms. For example, an implementation as an integrated platform (server, workstation, personal computer, laptop, etc.) may include CPU 1105, memory 1110, non-volatile storage 1120, and I / O device 1125. In such a configuration, components 1105, 1110, 1120, and 1125 may be connected and communicate through a local data bus and access a data repository 1130 through an external I / O connection (e.g., implemented as a separate database system). I / O component 1125 may be connected to external devices through a direct communication link (e.g., a wired connection or a local wifi connection), through a network such as a local area network (LAN) or a wide area network (WAN such as a cellular phone network or the Internet), and / or through other suitable connections. System 1100 may be stand-alone or may be a subsystem of a larger system.

[0173] The CPU 1105 may be one or more known processors or processing devices, such as a microprocessor belonging to the Core (registered trademark) family manufactured by Intel (registered trademark) Corporation of Santa Clara, CA, or a microprocessor belonging to the Athlon (registered trademark) family manufactured by AMD (registered trademark) Corporation of Sunnyvale, CA. The memory 1110 may be one or more high-speed storage devices configured to store instructions and information that are executed or used by the CPU 1105 to perform any functions, methods, and processes related to the implementation of the present invention. The storage 1120 may be a volatile or non-volatile, magnetic, semiconductor, tape, optical, or other type of storage device or computer-readable medium, including devices such as CDs, DVDs, and solid-state devices for long-term storage.

[0174] In the illustrated implementation, the memory 1110 houses one or more programs or applications 1115 loaded from the storage 1120 or from a remote system (not shown), and when the one or more programs or applications 1115 are executed by the CPU 1105, they perform various steps, procedures, processes, or methods consistent with the present invention. Alternatively, the CPU 1105 may execute one or more programs located at a location remote from the system 1100. For example, the system 1100 may access one or more remote programs through the network 1135, and when the one or more remote programs are executed, they perform functions and processes related to the implementation of the present invention.

[0175] In one implementation, the memory 1110 can include a program 1115 that performs the special functions and processes described herein for the provisioning controller 120, DAMS 110, and / or distributor devices 118, 131. In some implementations, the memory 1110 implements other methods and processes that provide auxiliary functions to the present invention. It may also include other programs or applications to be executed.

[0176] Memory 1110 may be composed of other programs (not shown) unrelated to the present invention and / or an operating system (not shown) that performs some known functions when executed by CPU 1105. As an example, the operating system may be Microsoft Windows (registered trademark), Unix (registered trademark), Linux (registered trademark), an operating system of Apple Computers (registered trademark), or other operating systems. The choice of the operating system is not important for the present invention, and even the use of the operating system is not important for the present invention.

[0177] HSM 1140 may be a device that includes its own processor, securely generates and stores digital security assets, and / or securely performs various cryptographic calculations and confidential calculations. HSM 1140 protects digital security assets such as cryptographic keys and other confidential data from access by attackers. In some implementations, the HSM may be a plug-in card or board directly attached to computing system 1100.

[0178] The I / O device 1125 may include one or more input / output devices that enable the system 1100 to receive and / or transmit data. For example, the I / O device 1125 may include one or more input devices such as a keyboard, a touch screen, a mouse, and the like that enable data input from a user. Further, the I / O device 1125 may include one or more output devices such as a display screen, a CRT monitor, an LCD monitor, a plasma display, a printer, a speaker device, and the like that enable data output or presentation to a user. The I / O device 1125 may also include one or more digital and / or analog communication input / output devices that enable the computing system 1100 to communicate with other machines and devices, for example, in a digital manner. Another configuration and / or number of input and / or output devices may be incorporated into the I / O device 1125.

[0179] In the illustrated implementation, the system 1100 is connected to a network 1135 (such as the Internet, a private network, a virtual private network, a cellular network, or other network, or a combination thereof), and the network 1135 may be connected to various systems and computing machines including servers, personal computers, laptop computers, client devices, and the like. Generally, the system 1100 can input data from external machines and devices and output data to external machines and devices through the network 1135.

[0180] In the exemplary implementation shown in FIG. 11, data source 1130 is an independent database external to system 1100, such as database 125. In another implementation, data source 1130 may be hosted by system 1100. In various implementations, data source 1130 can manage and store data used to implement systems and methods consistent with the present invention. For example, data source 1130 can manage and store a data structure that includes status information and log information of each device 116 provisioned by system 110, and the like.

[0181] Data source 1130 may comprise one or more databases that store information and are accessed and / or managed through system 1100. As an example, database 1130 may be an Oracle® database, a Sybase® database, or other relational database. However, the systems and methods consistent with the present invention are not limited to separate data structures or databases, nor even to the use of databases or data structures.

[0182] Those skilled in the art will recognize that the components and implementation details of the system of FIG. 11 are examples presented to keep the description brief and clear. Other components and implementation details may be used.

[0183] In the foregoing examples, specific examples of computerized devices such as OBU, ECU, and RSU are used to clarify the description, but the present invention is not limited to those specific examples. Various implementations consistent with the present invention may be utilized, inter alia, with various computerized devices including, but not limited to, medical devices (e.g., dialysis devices, infusion pumps, etc.), robots, drones, autonomous vehicles, wireless communication modules (e.g., embedded universal integrated circuit cards (eUICC)), and may be utilized for various computerized devices.

[0184] The various steps of the applications described herein may be performed, at least in part, by one or more VMs. In additional or alternative implementations, the steps of the applications described herein may be performed, at least in part, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the corresponding steps. Such processors, whether temporarily or permanently configured, may constitute processor-implemented modules that serve to perform the steps, functions, and roles of one or more of the applications described herein. As used herein, the term “processor-implemented module” refers to a hardware module implemented using one or more processors.

[0185] Similarly, the methods described herein may be at least in part processor-implemented, where a particular one or more processors are an example of hardware. For example, at least some of the multiple steps of a method may be performed by one or more processors or processor-implemented modules. Further, one or more processors may serve to assist in the performance of the corresponding steps within a “cloud computing” environment or as “software as a service” (SaaS). For example, at least some of the multiple steps may be performed by a group of computers (an example of machines including processors), and these steps may be accessible through a network (e.g., the Internet) and also through one or more appropriate interfaces (e.g., APIs).

[0186] The performance of some steps may be distributed among processors that are not only within a single machine but also deployed across several machines. In some exemplary implementations, the processors or processor-implemented modules may be located in a single geographical location (e.g., within an office environment, a manufacturing environment, or a server farm). In other exemplary implementations, the processors or processor-implemented modules may be distributed across a number of geographical locations.

[0187] Other implementations of the invention will be apparent to those skilled in the art from a consideration of this specification and practice of the invention disclosed herein. This specification and examples are to be considered exemplary only, and the true scope of the invention is indicated by the following claims.

Claims

1. 1. An extensible certificate management system for securely providing certificates to a provisioning controller, the certificate management system comprising: one or more application platforms that execute registration authority applications and are communicatively connected to one or more computation engines that perform cryptographic computations required by the registration authority applications; one or more application platforms executing a subscriber certificate authority application and communicatively connected to one or more computation engines performing cryptographic computations requested by said subscriber certificate authority application, said subscriber certificate authority application operative to generate and conditionally transmit a subscriber certificate to said registration authority application; one or more application platforms executing an anonymous certificate authority application and communicatively connected to one or more computation engines performing cryptographic computations required by said anonymous certificate authority application, said anonymous certificate authority application operative to generate and conditionally transmit anonymous certificates to said registration authority application; one or more application platforms that execute a first associated station application and are communicatively connected to one or more computation engines that perform cryptographic computations required by the first associated station application; 1. A certificate management system comprising: one or more application platforms executing a second binding authority application and communicatively connected to one or more computation engines that perform cryptographic computations required by the second binding authority application, wherein the first binding authority application and the second binding authority application are operative to generate and conditionally transmit a binding value to the registration authority application.

2. 2. The certificate management system of claim 1, further comprising one or more databases operatively connected to the one or more application platforms that run the registration authority application, the one or more application platforms that run the subscriber certificate authority application, the one or more application platforms that run the anonymous certificate authority application, the one or more application platforms that run the first binding authority application, and the one or more application platforms that run the second binding authority application.

3. 3. The certificate management system of claim 2, wherein each of the registration authority application, the subscribing certificate authority application, the anonymous certificate authority application, the first binding authority application, the second binding authority application, and the one or more databases function to be extended independently of each other.

4. said subscription certificate authority application being operative to generate a subscription certificate in response to receiving a request for a subscription certificate from said registration authority application; said subscribing certificate authority application being operative to generate an anonymous certificate in response to receiving a request for an anonymous certificate from said registration authority application; the first binding station application and the second binding station application are operative to generate a binding value in response to receiving a request for a binding value from the registration authority application; The certificate management system of claim 1 .

5. 2. The certificate management system of claim 1, wherein each of the registration authority application, the subscriber certificate authority application, the anonymous certificate authority application, the first binding authority application, and the second binding authority application are communicatively coupled to each other by a message queuing service comprising a plurality of message queues.

6. the one or more application platforms executing the subscriber certificate authority applications are one or more virtual machines communicatively connected by a first plurality of message queues to the one or more computation engines performing the cryptographic computations requested by the subscriber certificate authority applications; the one or more application platforms executing the first coupled station application are one or more virtual machines communicatively connected by a second plurality of message queues to the one or more computation engines performing the cryptographic computations requested by the first coupled station application; the one or more application platforms executing the second coupled station application are one or more virtual machines communicatively connected by a third plurality of message queues to the one or more computation engines performing the cryptographic computations requested by the second coupled station application. The certificate management system of claim 1 .

7. the first plurality of message queues comprising: a first message queue for queuing messages to be delivered to the one or more virtual machines executing the subscriber certificate authority application; a second message queue for queuing messages to be sent to the one or more computation engines that perform the cryptographic computations requested by the subscriber certificate authority application; the second plurality of message queues: a third message queue for queuing messages to be delivered to the one or more virtual machines executing the first bound station application; a fourth message queue for queuing messages to be sent to the one or more computation engines performing the cryptographic computations requested by the first binding station application; the third plurality of message queues: a fifth message queue for queuing messages to be delivered to the one or more virtual machines executing the second bound station application; a sixth message queue for queuing messages to be sent to the one or more computation engines performing the cryptographic computations requested by the second binding station application. The certificate management system of claim 6.

8. the first plurality of message queues comprising: a first bidirectional message queue for queuing messages to be sent to and from the one or more virtual machines executing the subscriber certificate authority application; a second bidirectional message queue for queuing messages to be sent to and from the one or more computation engines performing the cryptographic computations requested by the subscriber certificate authority application; the second plurality of message queues: a third bidirectional message queue for queuing messages to be sent to and from the one or more virtual machines executing the first binding station application; a fourth bidirectional message queue for accommodating messages sent to and from the one or more computation engines performing the cryptographic computations requested by the first binding station application; the third plurality of message queues: a fifth bidirectional message queue for queuing messages to be sent to and from the one or more virtual machines executing the second binding station application; a sixth bidirectional message queue for accommodating messages sent to and from the one or more computation engines performing the cryptographic computations requested by the second binding station application; The certificate management system of claim 6.

9. the one or more application platforms executing the subscriber certificate authority applications are communicatively connected by a first load balancer to the one or more computation engines performing the cryptographic computations requested by the subscriber certificate authority applications; the one or more application platforms executing the first associated station application are communicatively connected by a second load balancer to the one or more computation engines performing the cryptographic computations requested by the first associated station application; the one or more application platforms executing the second coupled station application are communicatively connected by a third load balancer to the one or more computation engines performing the cryptographic computations requested by the second coupled station application. The certificate management system of claim 1 .

10. each of the first load balancer, the second load balancer, and the third load balancer includes at least one of a load balancer virtual machine and a load balancer server; the load balancer virtual machine and the load balancer server are each configured to distribute workload across multiple application platforms and multiple compute engines; The certificate management system of claim 9.

11. The certificate management system of claim 10 , wherein the load balancer virtual machine and the load balancer server are each configured to distribute workload across the multiple application platforms and the multiple computing engines using a round robin approach.

12. 11. The certificate management system of claim 10, wherein the load balancer virtual machine and the load balancer server are each configured to distribute workload across the plurality of application platforms and the plurality of compute engines based on respective workloads reported by each of the plurality of application platforms and each of the plurality of compute engines.

13. The provisioning controller: Transmitting a request for a subscription certificate to said registration authority application on behalf of the computerized device; receiving the subscription certificate from the registration authority application, the subscription certificate being generated by the subscription certificate authority application; Sending said subscription certificate to said computerized device; sending a request for a plurality of anonymous certificates to the registration authority application on behalf of the computerized device; receiving from the registration authority application the plurality of anonymous certificates that are generated by the anonymous certificate authority application; transmitting said plurality of anonymous certificates to said computerized device; Creating and maintaining logs associated with said computerized devices; and operative to store information regarding certificate activity of said computerized device; The certificate management system of claim 1 .

14. 14. The certificate management system of claim 13, further operable to transmit information regarding certificate activity relating to said computerized device to said provisioning controller for storage in said log.

15. 14. The certificate management system of claim 13, wherein said provisioning controller is further operative to authenticate said computerized device prior to sending said request for said subscription certificate to said registration authority application.

16. 2. The certificate management system of claim 1, wherein the membership certificate is a public key certificate that identifies a holder 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 anonymous certificates that enable communication with the plurality of computerized devices.

Images