Scalable certificate management system, method, and non-transitory computer readable medium

Abstract

The invention relates to a scalable certificate management system, method and non-transitory computer readable medium for securely providing certificates. The system may include one or more application platforms running a registered approval authority, the application platforms communicatively coupled to one or more compute engines that perform encrypted computations requested by the registered approval authority; one or more application platforms running a registered certificate authority, the application platforms communicatively coupled to one or more compute engines that perform cryptographic computations requested by the registered certificate authority; one or more application platforms running a pseudonymous certificate authority, the application platforms communicatively coupled to one or more compute engines that perform cryptographic computations requested by the pseudonymous certificate authority; and one or more application platforms running a first linked authority and a second linked authority, the application platforms communicatively coupled to one or more compute engines that perform cryptographic computations requested by the linked authorities.

Description

[0001] This application is a divisional application with an application date of July 1, 2019, application number 201980045450.3, and invention name “Scalable Certificate Management System Architecture”. The parent application is an application entering the Chinese national phase of international application number PCT / US2019 / 040064 submitted to the International Patent Office on July 1, 2019, claiming the priority of application number 16 / 029,559 submitted to the United States Patent Office on July 7, 2018. The above application is fully incorporated herein by reference. This parent application involves a partial continuation application of the U.S. application with application number US 15 / 812,510, filed on November 14, 2017 (which claims the benefit of the U.S. provisional application with application number US 62 / 421,878, filed on November 14, 2016); a U.S. provisional application with application number US 62 / 421,852, filed on November 14, 2016; and a U.S. provisional application with application number US 62 / 487,909, filed on April 20, 2017, the entire contents of which are incorporated herein by reference as a whole. Technical Field

[0002] The present invention relates to systems, devices and methods for securely provisioning computerized devices. Background Art

[0003] As computers become increasingly miniaturized and commoditized, manufacturers are now producing an increasing variety of devices that contain one or more embedded computers or processors. The computer in a computerized device is able to control the operation of the device, collect, store and share data, communicate with other computers and other computerized devices, and update its own software, among other things.

[0004] The Internet of Things (IoT) is a network of computerized physical devices with embedded processors, electronics, software, data, sensors, actuators, and / or network connections that enable these devices to connect and exchange data via digital networks, including the Internet, cellular networks, and other wireless networks. Typically, each "thing"

[0005] All can be uniquely identified by their embedded computing systems and can interoperate within the existing Internet infrastructure.

[0006] “Things” in the IoT sense can refer to a variety of computerized devices, such as consumer home appliances, commercial equipment used in business and corporate environments, manufacturing machinery, agricultural facilities, energy-consuming devices in homes and buildings (switches, power sockets, appliances, lighting systems, light bulbs, televisions, garage door openers, sprinkler systems, security systems, etc.), healthcare equipment, infrastructure management equipment, robots, drones, and transportation equipment and vehicles.

[0007] For example, most, if not all, modern vehicles and transportation machinery (e.g., cars, trucks, airplanes, trains, ships, motorcycles, scooters, etc.) contain several embedded processors or embedded computers in their subsystems that are computer controlled in at least some aspects. Similarly, an increasing number of modern transportation infrastructure devices (e.g., traffic lights, traffic cameras, traffic sensors, bridge monitors, bridge control systems, etc.) contain at least one (usually many) embedded processors or embedded computer systems that are computer controlled in at least some aspects. These computer-controlled elements of the transportation network typically communicate with each other, passing various types of information back and forth, and they may react, respond, and change their operations, or operate safely, correctly, efficiently, and reliably based on information received / sent from other vehicles via vehicle-to-vehicle communication (V2V; also known as C2C, Car-to-Car) and / or information received / sent from infrastructure elements to infrastructure elements via vehicle-to-infrastructure communication (V2I, Vehicle-to-Infrastructure, also known as C2I, Car-to-Infrastructure).

[0008] The computers in a computerized device operate according to its software and / or firmware and data. To ensure secure and correct operation, the computerized device must be properly initialized and updated with the correct software, firmware, executable instructions, digital certificates (such as public key certificates), encryption keys, etc. (hereinafter collectively referred to as "digital assets" or "software") as required by the manufacturer so that the Internet of Things consists only of devices executing authorized known good software and data. However, problems arise when unauthorized people or organizations (such as hackers) replace or change the software in a computerized device. Problems also arise when older versions of software, untested software, unapproved software, and / or software with known vulnerabilities are installed to computerized devices.

[0009] In view of the above, it is desirable to provide improved systems, methods and techniques for securely provisioning digital assets into computerized devices to prevent the computerized devices from operating with software and data that is prone to errors, improper operation, untested, maliciously tampered with, or otherwise undesirable. Summary of the invention

[0010] The present disclosure relates to systems, methods, and devices for securely generating and providing certain types of digital assets, such as security credentials and digital certificates. In various embodiments, the systems, methods, and devices use a scalable certificate management system (CMS) to create and provide certain types of digital assets, such as security credentials and public key certificates. In some embodiments, the CMS provides certificates, such as enrollment certificates and pseudonym certificates, in response to requests for such certificates.

[0011] In various embodiments, the CMS has a scalable architecture that includes a registration authority, one or more link authority authorities, a pseudonymous certificate authority, and a registration certificate authority. An example CMS may include one or more application platforms running a registration authority application, which are communicatively connected to one or more computing engines that 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 application platforms running a registration certificate authority, which are communicatively connected to one or more computing engines that perform cryptographic calculations required by the registration certificate authority. The registration certificate authority application is operable to generate a registration certificate and conditionally transmit the registration certificate to the registration authority application. The example CMS may further include one or more VMs running a pseudonymous certificate authority application, which are communicatively connected to one or more computing engines that perform cryptographic calculations required by the pseudonymous certificate authority; the pseudonymous certificate authority application is operable to generate a pseudonymous certificate and conditionally transmit the pseudonymous certificate to the registration authority application. The CMS may also include one or more VMs running the first link authority and the second link authority, the VMs being communicatively connected to one or more computing engines that perform cryptographic computations required by the first link authority and the second link authority. The first link authority application and the second link authority application are operable to generate link values ​​and conditionally transmit the link values ​​to the registration approval authority application.

[0012] In some embodiments, a scalable CMS for secure provisioning of certificates to a provisioning controller includes: one or more application platforms running a registration authority application, the application platforms communicatively connected to one or more computing engines that perform cryptographic calculations required by the registration authority application; one or more application platforms running an enrollment certificate authority application, the application platforms communicatively connected to one or more computing engines that perform cryptographic calculations required by the enrollment certificate authority application, the enrollment certificate authority application being operable to generate an enrollment certificate and conditionally transmit the enrollment certificate to the registration authority application; one or more application platforms running a pseudonym certificate authority application, the application platforms communicatively connected to one or more computing engines that perform cryptographic calculations required by the pseudonym certificate authority application, the pseudonym certificate authority application being operable to generate a pseudonym certificate and conditionally transmit the pseudonym certificate to the registration authority application; one or more application platforms running a first link authority application, the application platforms communicatively connected to one or more computing engines that perform cryptographic calculations required by the first link authority application; and one or more application platforms running a second link authority application, the application platforms communicatively connected to one or more computing engines that perform cryptographic calculations required by the second link authority application. The link authority application is operable to generate a link value and conditionally transmit the link value to the registration authority application.

[0013] In other embodiments, the CMS may further include one or more databases, which are operably connected to one or more application platforms running registration and approval authority applications, one or more application platforms running registration certificate authority applications, one or more application platforms running pseudonym certificate authority applications, one or more application platforms running first link authority application, and one or more application platforms running second link authority application.

[0014] In yet other embodiments, each of the registration authority application, the enrollment certificate authority application, the pseudonym certificate authority application, the first link authority application, the second link authority application, and the one or more databases are operable to scale independently of one another.

[0015] In still other embodiments, the enrollment certificate authority application is operable to generate an enrollment certificate in response to receiving a request for an enrollment certificate from the enrollment approval authority application; the enrollment certificate authority application is operable to generate a pseudonym certificate in response to receiving a request for a pseudonym certificate from the enrollment approval authority application; and the first link authority application and the second link authority application are operable to generate a link value in response to receiving a request for a link value from the enrollment approval authority application.

[0016] In some embodiments, each of the registration authority application, the enrollment certificate authority application, the pseudonym certificate authority application, the first link authority application, and the second link authority application are communicatively coupled to each other via a message queuing service including a plurality of message queues.

[0017] In certain embodiments, one or more application platforms running an enrollment certificate authority application are connected via a first plurality of message queue communications to one or more virtual machines of one or more computing engines that perform cryptographic calculations required for the enrollment certificate authority application; one or more application platforms running a first link authority agency application are connected via a second plurality of message queue communications to one or more virtual machines of one or more computing engines that perform cryptographic calculations required for the first link authority agency application; and one or more application platforms running a second link authority agency application are connected via a third plurality of message queue communications to one or more virtual machines of one or more computing engines that perform cryptographic calculations required for the second link authority agency application.

[0018] According to certain embodiments having a first plurality of message queues, a second plurality of message queues, and a third plurality of message queues, the first plurality of message queues include: a first message queue for queuing messages to be delivered to one or more virtual machines running a registration certificate authority application; and a second message queue for queuing messages to be delivered to one or more computing engines that perform cryptographic calculations required for the registration certificate authority application; the second plurality of message queues include: a third message queue for queuing messages to be delivered to one or more virtual machines running a first link authority agency application; and a fourth message queue for queuing messages to be delivered to one or more computing engines that perform cryptographic calculations required for the first link authority agency application; and the third plurality of message queues include: a fifth message queue for queuing messages to be delivered to one or more virtual machines running a second link authority agency application; and a sixth message queue for queuing messages to be delivered to one or more computing engines that perform cryptographic calculations required for the second link authority agency application.

[0019] In other embodiments having a first plurality of message queues, a second plurality of message queues, and a third plurality of message queues, the first plurality of message queues include: a first bidirectional message queue for queuing messages to be delivered to and sent from one or more virtual machines running a registration certificate authority application; and a second bidirectional message queue for queuing messages to be delivered to and sent from one or more computing engines that perform cryptographic calculations required for the registration certificate authority application; the second plurality of message queues include: a third bidirectional message queue for queuing messages to be delivered to and sent from one or more virtual machines running a first link authority agency application; and a fourth bidirectional message queue for queuing messages to be delivered to and sent from one or more computing engines that perform cryptographic calculations required for the first link authority agency application; and the third plurality of message queues include: a fifth bidirectional message queue for queuing messages to be delivered to and sent from one or more virtual machines running a second link authority agency application; and a sixth bidirectional message queue for queuing messages to be delivered to and sent from one or more computing engines that perform cryptographic calculations required for the second link authority agency application.

[0020] In other embodiments of the CMS, one or more application platforms running a registration certificate authority application are connected to one or more computing engines that perform cryptographic calculations required for the registration certificate authority application via a first load balancer; one or more application platforms running a first link authority agency application are connected to one or more computing engines that perform cryptographic calculations required for the first link authority agency application via a second load balancer; and one or more application platforms running a second link authority agency application are connected to one or more computing engines that perform cryptographic calculations required for the second link authority agency application via a third load balancer.

[0021] In certain embodiments where the CMS includes a first load balancer, a second load balancer, and a third load balancer, each load balancer may include one or more of the following: a load balancer virtual machine and a load balancer server; and the load balancer virtual machine and the load balancer server are both configured to distribute workloads across multiple application platforms and multiple computing engines.

[0022] In other embodiments having a load balancer virtual machine and a load balancer server, both the load balancer virtual machine and the load balancer server are configured to distribute workload across multiple application platforms and multiple computing engines using a round-robin scheduling technique.

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

[0024] In various embodiments, the provisioning controller is operable to: transmit a request for an enrollment certificate to a registration authority application on behalf of a computerized device; receive an enrollment certificate from the registration authority application, which enrollment certificate may be generated by the enrollment certificate authority application; transmit the enrollment certificate to the computerized device; transmit a request for multiple pseudonymous certificates to the registration authority application on behalf of the computerized device; receive multiple pseudonymous certificates from the registration authority application, which multiple pseudonymous certificates may be generated by the pseudonymous certificate authority application; transmit the multiple pseudonymous certificates to the computerized device; create and retain a log associated with the computerized device; and store information about certificate activity of the computerized device.

[0025] In some embodiments where the provisioning controller is operable to create and retain a log, the provisioning controller is further operable to transmit information regarding credential activity associated with the computerized device to the provisioning controller for storage in the log.

[0026] In certain embodiments where the provisioning controller is operable to transmit a request for an enrollment certificate to the registration approval authority application, the provisioning controller is further operable to authenticate the computerized device prior to transmitting the request for an enrollment certificate to the registration approval authority application.

[0027] In other embodiments, the enrollment certificate can be a public key certificate that identifies the holder of the public key certificate as an authorized participant in an ecosystem including multiple computerized devices, and each authorized participant in the ecosystem can receive one or more pseudonymous certificates that enable communication with the multiple computerized devices.

[0028] In some embodiments, a system for provisioning one or more computerized devices includes: a distributor, the distributor is communicatively connected to the computerized device and is operable to receive a digital asset and load the digital asset into the computerized device; a digital asset management system, the digital asset management system is connected to the distributor via a first secure communication channel and is operable to generate a digital asset and conditionally transmit the digital asset to the distributor; and a provisioning controller, the provisioning controller is connected to the distributor via a second secure communication channel and is connected to the digital asset management system via a third secure communication channel and is operable to direct the digital asset management system to transmit the digital asset to the distributor. Due to the absence of the digital asset, the computerized device may not function or only partially function before the digital asset is loaded into the computerized device. The digital asset can be at least one of a digital certificate, an encryption key, and executable software. In some embodiments, the system can interact with a scalable CMS or receive credentials from a scalable CMS.

[0029] In various embodiments, the system may further include a second distributor connected to the digital asset management system via a fourth secure communication channel and communicatively connected to the computerized device after the distributor is disconnected, and operable to receive a second digital asset and load the second digital asset into the computerized device, and the provisioning controller is further operable to direct the digital asset management system to transfer the second digital asset to the distributor. After the second digital asset is loaded into the computerized device, the computerized device may be fully functional.

[0030] In various embodiments, the digital asset management system may further include: one or more application platforms running a registration and approval authority application, which are communicatively connected to one or more computing engines that perform cryptographic calculations required for the registration and approval authority application; one or more application platforms running an enrollment certificate authority application, which are communicatively connected to one or more computing engines that perform cryptographic calculations required for the enrollment certificate authority application; one or more application platforms running a pseudonymous certificate authority application, which are communicatively connected to one or more computing engines that perform cryptographic calculations required for the pseudonymous certificate authority application; one or more application platforms running a first link authority application, which are communicatively connected to one or more computing engines that perform cryptographic calculations required for the first link authority application; and one or more application platforms running a second link authority application, which are communicatively connected to one or more computing engines that perform cryptographic calculations required for the second link authority application.

[0031] In other embodiments, the digital asset management system may further include one or more databases, which are operably connected to one or more application platforms running registration and approval authority applications, one or more application platforms running registration certificate authority applications, one or more application platforms running pseudonym certificate authority applications, one or more application platforms running first link authority application, and one or more application platforms running second link authority application.

[0032] In some other embodiments, the system may further include: a portal that is operably connected to the provisioning controller and 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 and authenticates the installer of the computerized device and enables the installer to manage the provisioning of the computerized device, and / or the portal is operably connected to the provisioning controller and authenticates the supervisor of the computerized device and enables the supervisor to supervise the provisioning of the computerized device.

[0033] In yet other embodiments, the provisioning controller is further operable to transmit the digital asset (e.g., executable software image) to the distributor for loading into the computerized device. In still other embodiments, the provisioning controller is further operable to create and retain a log associated with the digital device and storing information about provisioning activities for the digital device, and the distributor is further operable to transmit information about provisioning activities related to the digital device to the provisioning controller for storage in the log.

[0034] In still other embodiments, the provisioning controller is further operable to authenticate the digital device prior to directing the digital asset management system to transfer the digital asset. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] The accompanying drawings are incorporated into and constitute a part of the specification, illustrate the embodiments of the present invention, and explain the principles of the present invention in conjunction with the content of the invention. In the drawings:

[0036] Figure 1 is a block diagram illustrating an example of a system for secure provisioning according to an embodiment of the present invention;

[0037] Figure 2 is a swim lane diagram illustrating an example of a process for securely provisioning a computerized device according to an embodiment of the present invention;

[0038] Figure 3 is a swim lane diagram illustrating another example of a process for securely provisioning a computerized device according to an embodiment of the present invention;

[0039] Figure 4Ais a first partial block diagram of a system example for implementing a scalable and secure digital asset management system through a message queue according to an embodiment of the present invention;

[0040] Figure 4B is a second partial block diagram of a system example for implementing a scalable and secure certificate management system through a message queue according to an embodiment of the present invention;

[0041] Figure 5A is a first portion of a swim lane diagram illustrating an example of a process for securely providing credentials such as certificates according to an embodiment of the present invention;

[0042] Figure 5B is a second partial swimlane diagram illustrating an example of a process for securely providing credentials such as certificates according to an embodiment of the present invention;

[0043] Fig. 6A is a first partial block diagram of a system example for implementing a scalable and secure certificate management system through a bidirectional message queue according to an embodiment of the present invention;

[0044] Figure 6B is a second partial block diagram of a system example for implementing a scalable and secure certificate management system through a bidirectional message queue according to an embodiment of the present invention;

[0045] Fig. 7A is a first partial block diagram of a system example for implementing a scalable and secure certificate management system through a load balancer according to an embodiment of the present invention;

[0046] Figure 7B is a second partial block diagram of a system example for implementing a scalable and secure certificate management system through a load balancer according to an embodiment of the present invention;

[0047] Figure 8 is a block diagram of an example of a system for implementing a scalable and secure certificate management system through polling scheduling requests according to an embodiment of the present invention;

[0048] Fig. 9 is a block diagram of an example of a system for implementing a scalable and secure certificate management system through workload-based requests according to an embodiment of the present invention;

[0049] Fig. 10A is a first partial block diagram of a system example for implementing a scalable and secure digital asset management system through a message queue according to an embodiment of the present invention;

[0050] Fig. 10B is a second partial block diagram of an example of a system for implementing a scalable and secure certificate management system through a message queue according to an embodiment of the present invention; and

[0051] Fig.11 is a block diagram of an example computing system that may be used to host systems and methods according to embodiments of the present invention. DETAILED DESCRIPTION

[0052] Now, specific reference will be made to various embodiments of the present invention, which will be described in conjunction with the accompanying drawings. For simplicity, the same reference numerals are used in the various drawings to refer to the same or similar parts.

[0053] In order to ensure safe and correct operation in the field, embedded devices, such as automotive electronic control units (ECUs), need to be properly initialized during manufacturing by provisioning digital assets (such as security assets). Digital assets may include various encryption keys, unique identifiers, digital certificates, and software. In most cases, the sources of these digital assets and manufacturing plants are located in different geographical locations, which are conventionally interconnected via unsecured Internet communications. Therefore, it is desirable to create an end-to-end secure channel from the source of these digital assets to the device so that malicious parties or accidental persons cannot access or modify the digital assets.

[0054] The drawback of conventional network security protocols (such as TLS / SSL) for end-to-end protection is that they require pre-shared keys or certain confidential security materials to exist in advance on both sides of the communication. This creates a periodic technical problem, namely, in order to provision digital assets, some initial confidential materials must exist in advance. This problem includes how to protect the initial confidential materials. This problem is particularly serious for computerized devices because a single version of initial software is usually loaded onto computerized devices during manufacturing to simplify logistics. If this initial software must contain initial security materials, this requires the existence of global secrets. As a result, destroying the initial security materials will result in destroying all digital assets provisioned to all devices because they all share the same global secret. The systems, methods and devices according to the present disclosure solve these and other problems of conventional provisioning systems.

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

[0056] These actions may also include properly installing the device into its operating environment and testing the device to verify that it operates properly. The ability to securely provision only known good devices is complicated by the fact that a device may be built by one manufacturer and subsequently installed into a larger system or device by another manufacturer, such as an on-board unit (OBU) built by a parts manufacturer that may be installed into a car built by an automobile manufacturer. An incorrectly installed device may not function properly.

[0057] Various embodiments of the present invention provide secure provisioning of computerized devices, including IoT devices, to prevent or inhibit malicious, negligent, or erroneous tampering, modification, updating, or publishing of digital assets used by computerized devices, and to prevent or inhibit erroneous installation of computerized devices and their software.

[0058] Various embodiments of the present invention may also generate audit logs, records, reports, etc. that can be used to analyze and resolve problems discovered later during the security provisioning process.

[0059] Various embodiments according to the present invention may also provide a secure provisioning and management platform that can be provided as a service to device and system manufacturers.

[0060] Figure 1 is a block diagram illustrating an example of a system 100 for securely provisioning a computerized device according to an embodiment of the present invention. Figure 1 As shown in the example in , the system 100 includes a provisioning controller 120. The provisioning controller 120 can be implemented as a server computer (e.g., having at least one processor and associated memory) whose embedded hardware security module (HSM) securely generates and stores digital security assets and securely performs various cryptographic and sensitive calculations. The HSM protects digital security assets (such as encryption keys) and other sensitive data from possible access by attackers. In various embodiments, the provisioning controller 120 operates to: authenticate and securely communicate with users of the system 100; securely communicate with and manage one or more distributors 108, 131; securely communicate with and direct the operation of the digital asset management system (DAMS) 110; create and store provisioning records; create, store and distribute provisioning records; create, store and distribute audit logs; create and distribute certificates to cryptographically bind the DAMS 110 to the distributor 108, 131 elements; revoke them as needed if users and managed devices are no longer trusted; and create and distribute secure encrypted backups of critical keys and data for off-site storage to enable business continuity and disaster recovery.

[0061] like Figure 1As shown in the example of , the provisioning controller 120 is communicatively connected to a database 125 that can store data, information, and digital assets related to the secure provisioning devices 106a, 106b (collectively referred to as 106).

[0062] The provisioning controller 120 is also securely communicatively connected to the manufacturer's user portal 115, which can be implemented, for example, as a server or interface to the provisioning controller 120. In various embodiments, an employee 109 of the device manufacturer 105 can use the manufacturer's user portal 115 to interface with the provisioning controller 120 (and therefore the DAMS 110) and manage their device provisioning activities. In various embodiments, the manufacturer's user portal 115 can collect identification information from the employee user 109, such as a username, password, two-factor identification data, facial recognition image, fingerprint, etc., and provide the identification information to the provisioning controller 120. The provisioning controller 120 can authenticate the employee 109 before allowing the employee 109 to access the secure provisioning system 100. For example, the provisioning controller 120 can look up identification information associated with the employee user 109 and previously verified and stored in its database 125, and compare the stored identification information with the identification information collected by the manufacturer's user portal 115. Alternatively, the user portal 115 of the provisioning controller 120 or DAMS can be integrated with the user's enterprise identification and authentication system, which will determine whether the employee 109 is authorized to use the system 100. In various embodiments, the user portal 115 of the provisioning controller 120 or DAMS can assign roles to successfully authenticated employees 109 to constrain their actions within the system 100. In some embodiments, the provisioning controller 120 will only allow access if the two sets of identification information match.

[0063] Similarly, the provisioning controller 120 is also communicatively connected to an installer's user portal 116, which may be implemented, for example, as a server or interface to the provisioning controller 120. In various embodiments, an employee 132 of a device installer may interface with the provisioning controller 120 (and therefore the DAMS 110) and manage their device installation and provisioning activities using the installer's user portal 116. The provisioning controller 120 may authenticate the employee 132 before allowing them to access the secure provisioning system 100 and perform authorized functions on the system, and may assign roles to the employee 132 before allowing them to access the secure provisioning system 100 and perform authorized functions on the system.

[0064] Likewise, the provisioning controller 120 is also communicatively connected to a supervisor portal 117, which may be implemented, for example, as a server or interface to the provisioning controller 120. In various embodiments, the supervisor 140, once authenticated by the provisioning controller 120, may use the supervisor portal 117 to interface with the provisioning controller 120 and manage the review and approval of the manufacturer 104, the installer 130, the device 106, and / or the software / digital assets installed in the device 106. The provisioning controller 120 may authenticate the supervisor 140 before allowing the supervisor 140 to access the secure provisioning system 100. In some embodiments of the system 100, the supervisor 140 and the supervisor portal 117 may be optional.

[0065] The provisioning controller 120 is further communicatively connected to the DAMS 110. In various embodiments, the DAMS 110 may be implemented as a server, device, or system of security devices and / or servers. The DAMS 110 securely retrieves public keys from end-entity devices to be provisioned via the distributors 108, 131 or other secure and authenticated connections, and securely supplies digital certificates and related data installed in the devices 106. In addition, the DAMS 110 securely receives status information about the provisioning, installation, functionality, etc. of the computerized devices 106 from the manufacturers 105 and installers 130 via the distributors 108, 131. In addition, as Figure 1 As shown, DAMS 110 can perform this provisioning at a single site or at multiple sites. Figure 2 In detail, DAMS 110 may include the following main elements: root certificate authority (CA), policy generator, CRL generator, misconduct authority, intermediate CA, enrollment CA, chaining authority, pseudonymous CA, and registration approval authority.

[0066] DAMS 110 adds new functionality and improves upon the components and functionality described in the paper "A Secure Credential Management System for V2V Communications" by William Whyte et al., presented at the 2013 IEEE Vehicular Networking Conference (VNC) in December 2013. In various embodiments, DAMS 110 includes multi-stage programming and flexible management (e.g., allowing for the inclusion of a supervisor 140). Various embodiments of DAMS 110 also enable the ability to allow a single DAMS 110 to provide different levels of provisioning to different subscribers. Various embodiments of DAMS 110 also enable the ability to allow subscribers to be assigned different digital certificate usages over a time period (e.g., weekly) and different certificate loads (such as one week, rather than three years in conventional systems). Various embodiments of DAMS 110 may also provide a subscriber-specific URL so that a particular manufacturer's computerized device 106 (e.g., an OEM's vehicle) can stay within the manufacturer's scope (e.g., its URL displays its name).

[0067] As shown, the provisioning controller 120 is also communicatively connected to the distributors 108, 131. In various embodiments, the distributors 108, 131 can be implemented as standalone secure devices installed at a company location (as shown), or as web or cloud services, etc. In various embodiments, the distributors 108, 131 are implemented as trusted endpoint devices that preferably securely transmit and receive digital assets and other information to and from the DAMS 110 and the provisioning controller 120 via a dedicated non-Internet communication channel. As shown, the distributors 108, 131 are also directly or indirectly connected to the devices 106a, 106b to download digital assets to the devices 106a, 106b and receive data from the devices 106a, 106b. In various embodiments, the distributors 108, 131 can be implemented as an electrical box including a server computer (e.g., having at least one processor and associated memory), including a hardware security module (HSM), a hardened operating system (OS), an internal firewall, and an internal host intrusion detection / prevention system. The distributor can be specifically designed to operate in an untrusted environment, but still provide trusted and reliable operation. The distributor has a secure communication channel between itself and the secure provisioning controller 120 and DAMS 110. The channel is used to control the distributor and send and retrieve provisioning-related data and log information. The distributor can also have a secure communication channel to the tester 107 for programming or provisioning the device 106. The channel prevents the provisioning data and log data from being leaked or modified on the communication network at the manufacturing site. The distributor 108 can also establish a secure communication channel directly with the device 106 to be programmed so that the provisioning data will not be damaged or modified by a third party (including a rogue tester 107). In various embodiments, the distributor can collect public keys and other data, such as microprocessor serial numbers, from the device 106 to be provisioned. It can send this information to the provisioning controller 120 and / or DAMS 110. It can also accept data and commands and other information from the provisioning controller 120 and / or DAMS 110 to be programmed into the device 106. It may return its own log data, and it may return data from the tester 107 to the provisioning controller 120 and / or the DAMS 110 .

[0068] As shown with reference to the device manufacturer 105, the distributor 108 can be communicatively connected to a tester 107 (e.g., computerized manufacturing equipment, product testing equipment, etc.), which in turn is connected to a device 106a, such as an OBU device, produced by the manufacturer 105. The manufacturer 105 may include or may be a factory that manufactures and / or supplies the computerized device 106a to the market. As one of many possible examples, the computerized device 106a may be an embedded universal integrated circuit card (eUICC) that is used for a cellular modem for telecommunications, incorporated as part of an on-board unit (OBU), which is then installed in a car to communicate between the car and traffic infrastructure equipment. It may also be a V2V security microprocessor installed in the OBU to communicate 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 correctly. Employees 109 of the manufacturer 105 may use a user portal 115 to interact with the provisioning controller 120 and manage product provisioning activities through the DAMS 110.

[0069] As shown with reference to the installer 130, the distributor 131 may alternatively be directly communicatively connected to the device 106b when or after the device 106b is installed in its operating environment. The installer 130 may include or may be a factory or store that installs the computerized device 106b into its operating environment, for example, installing an OBU into a car. Upon installation, the computerized device 106b must be further properly provisioned with digital assets, such as additional digital certificates from the DAMS 110, in order to operate correctly. An employee 132 of the installer 130 may interact with the provisioning controller 120 using the installer's user portal 116 and manage product provisioning activities through the DAMS 110.

[0070] In various embodiments, the provisioning controller 120, the distributors 108, 131, and the DAMS 110 may have secure communication links or channels between them that are not publicly accessible, and in various embodiments, Figure 1All communication links shown can be secure communication channels that are not publicly accessible. In various embodiments, these secure channels are encrypted and mutually authenticated to prevent unauthorized endpoints from communicating within the secure infrastructure. A variety of security mechanisms can be used to protect these communication channels so that if the outer layer is damaged to some extent, the inner layer will remain secure. For example, a mutually authenticated TLS tunnel can be used as an outer layer, and the inner layer uses another protocol, such as a dedicated secure communication protocol. These secure connections between infrastructure components including system 100 are used to protect sensitive communications between components and ensure that they operate correctly. By using these secure paths, provisioning controller 120 and DAMS 110 can send digital data between components without worrying about it being damaged or modified during transmission. Command and control information can also be transmitted through these channels. For example, provisioning controller 120 can control which distributor 108, 131 to send certain digital assets and data to. It can also instruct distributors 108, 131 how to meter the data to the equipment 106 on the production line being provisioned. In addition, the distributors 108, 131 are able to report information back to the provisioning controller 120 without having to worry about it being corrupted or modified in transit. For example, the secure provisioning controller 120 is able to program the distributors 108, 131 to provision up to 10,000 devices using any type of digital asset (e.g., certificates, software, FUSE content, etc.). The distributor 108, 131 is able to count the devices it is provisioning, and when the provisioning reaches its limit, it reports this to the provisioning controller 120. In various embodiments, the devices (e.g., 108, 110, 131, 115, 116, 117) managed by the provisioning controller 120 include functionality that causes them to cease operation if they do not communicate with the provisioning controller 120 on a regular basis; therefore, if the devices are stolen, they will become useless. This functionality prevents lost / stolen devices from continuing to operate and provisioning devices 106 as if they were still in the correct manufacturing environment.

[0071] Continue to refer to Figure 1In the example shown, in operation, a distributor 108 located at a manufacturer 105 securely receives digital assets from a DAMS 110 and supplies these digital assets to a tester 107 of a device 106a. As the manufacturer 105 manufactures each device 106a, the tester 107 communicates with the device 106a to obtain information from the device 106a, such as its unique identification number and status, and to download or otherwise install digital assets into the device, such as a digital certificate. The tester 107 may also supply information from the device 106a (e.g., provisioning status) to the distributor 108, which securely communicates the information to the DAMS 110 and / or provisioning controller 120. In some embodiments, the tester 107 may include a software transport layer security (TLS) agent that securely transmits data between the distributor 108 and the device 106a, in effect creating a secure encrypted communication path between the DAMS 110 and the device 106a via the distributor 108 and the tester 107 using a short key associated with each device 106a.

[0072] After initially provisioning the device 106, the manufacturer 105 ships the device 106a to the installer 130, who installs the device 106b. In various embodiments, the device 106a is not functional before the initial provisioning of the device 106a, and the device 106a is partially functional but not yet fully functional after the manufacturer 105 initially provisions the device 106a. In such embodiments, the initial provisioning renders the device functional only to the extent required for installation and further final provisioning, which is a necessary condition for it to be fully operational.

[0073] The installer 130 installs the device 106b into its operating environment, and an employee 132 of the installer 130 notifies the provisioning controller 120 of this fact via the installer portal 116. The notification proves that the installation was completed correctly, and preferably includes information that uniquely identifies the device 106b to the provisioning controller 120. In some embodiments, the distributor 131 may automatically notify the provisioning controller 120 after querying the device 106b for status and identification information. In various embodiments where the installer 130 proves via the installer portal 116 that he has correctly installed the device 106b, the proof may be recorded / saved by the provisioning controller 120 into the database 125. The proof may include specific test data about each specific installed device 106b, such as radio transmit power measurements or GPS antenna location verification.

[0074] In response to the installation notification, the provisioning controller 120 verifies that: (i) the device 106b is listed in its database 125 as a device legitimately manufactured by the manufacturer 105; (ii) the device 106b is listed in its database 125 as having been successfully initially provisioned by the manufacturer 105; and (iii) the installer 130 is listed in its database 125 as an authorized installer. If this verification is successful, the controller 120 directs the DAMS 110 to send a digital asset (e.g., a pseudonym certificate) to the DAMS 110.

[0075] (PC)) and / or other information required to operably provision the device 106b so that the device 106b can function properly when installed in its operating environment.

[0076] In various embodiments, the supervisor 140 interacts with the provisioning controller 120 via the supervisor portal 117 to identify, authenticate, and manage the installer 130 and / or the manufacturer 105 so that unauthorized installers (e.g., hackers) cannot obtain real digital assets from the system 100. Employees of the supervisor 140 can be authenticated by the provisioning controller 120 and can have a unique ID with the system 100 so that their actions can be uniquely recorded. In various embodiments, the supervisor 140 can use the supervisor portal 117 to query the provisioning controller 120 to obtain copies and reports of information recorded by the controller 120, such as certification reports, installer actions, the number and identity of manufactured devices 106a, the number and identity of installed fully provisioned devices 106b, etc.

[0077] In various embodiments, the installer 130 must be authenticated as authorized by the provisioning controller 120 in order to interact with the system 100. To obtain authorization, the installer 130 may, for example, have to execute appropriate contract documents stating that they will properly install the device 106b in the target environment (e.g., target vehicle or site, etc.). The regulator 140 may, for example, require the installer 130 to certify other contract elements. Preferably, each installer 130 has a unique ID within the system 100 so that their actions can be uniquely recorded by the provisioning controller 120.

[0078] The described implementation of the system 100 and its functionality ensures that only devices 106 manufactured by the manufacturer 105 and properly installed and tested by the authorized installer 130 are fully provisioned with the digital assets required to make the device 106 operational. The provisioning controller 120 generates extensive logs and reports on what actions were taken by whom at each stage of the provisioning process, providing critical audit capabilities not available in conventional systems.

[0079] Those skilled in the art will recognize that Figure 1The components, processes, data, operations, and implementation details shown are examples presented for simplicity and clarity of explanation. Other components, processes, implementation details, and variations may be used without departing from the principles of the present invention, as this example is not intended to be limiting and many variations are possible. For example, although Figure 1 Only one manufacturer 105, only one installer 130, and only one supervisor 140 are shown, but other embodiments may have any number of each of these entities. For another example, although the DAMS 110 and the provisioning controller 120 are shown as separate devices, other embodiments may combine their functions into a single device (e.g., a single server). As yet another example, this may also apply to the portals 115-117. For yet another example, the system 100 may additionally include an asset management device.

[0080] (AMA, not shown), see U.S. Provisional Application No. 62 / 421,852, filed November 14, 2016, the contents of which are incorporated herein by reference. In such embodiments, the AMA may be communicatively coupled to the provisioning controller 120 and / or the distributors 108, 131 and / or the DAMS 110. In various embodiments, the AMA may include a user-friendly GUI and functionality that allows a production coordinator to simply and effectively manage the configuration and build of a product (e.g., device 106), and allows an asset owner to simply and effectively manage the inventory of digital assets.

[0081] Figure 2 2 is a swim lane diagram illustrating an example of a process 200 for securely provisioning a computerized device according to an embodiment of the present invention. In various embodiments, some or all of the process 200 or operations illustrated may be performed by executing code on a general purpose computing system (which may include one or more processors or one or more computing subsystems) by a pure hardware system or a system that has both. Figure 2 As shown above, the entities involved in process 200 include a manufacturer 105 of a computerized device 106, a distributor 108 located at the manufacturer 105, a provisioning controller 120, and a DAMS 110. In various embodiments, these entities may be as described with reference to Figure 1 and entities described throughout this disclosure, and may communicate with each other.

[0082] like Figure 2As shown in the example in , process 200 begins at 205, where a manufacturer 105 (e.g., employee 109) requests a digital asset provisioning service from a provisioning controller 130, where the digital asset is to be provisioned to a device 106a (e.g., for use by it), and the request may identify the device 106a as the destination of the digital asset. The request may be, for example, the manufacturer 105 may be requesting a provisioning service for a new product 106A, or issuing a new provisioning service request for an existing product 106B. In various embodiments, the operation may involve an authorized user logging into the provisioning controller 130, for example, via a user portal 115. In some cases, the requested digital asset may be: a security credential, such as a registration certificate; executable code to be run by the device 106; digital operating parameters; and the like. A registration certificate is a public key certificate that identifies its holder as an authorized participant in an ecosystem, such as USDOT's V2X ecosystem, in which all participants must share a valid registration certificate, and authorized participants can also receive pseudonymous certificates that enable devices 106 within the ecosystem to communicate and operate (for example, in the example of USDOT's V2X ecosystem, enabling communication and operation between vehicles and roadside infrastructure).

[0083] At 210, the provisioning controller 120 determines whether the user from the manufacturer 109 is an authorized user. In some embodiments, at 210, the provisioning controller 120 may also determine whether the device 106a (e.g., product) to be provisioned is approved for use with the system 100. In some cases, the list of approved devices may be provided by Figure 1 Provided by the supervisor 140 in and used by the provisioning controller 120 to make such a determination.

[0084] If the user (and / or product) is not authorized, the provisioning controller 120 denies the request for digital asset provisioning services ( Figure 2 On the other hand, if an authorized user (e.g., for an authorized product) makes a request (210, yes), provisioning controller 120 directs, instructs, or otherwise controls DAMS 110 to fulfill the service request, such as by transmitting a service request instruction to DAMS 110 (at 215).

[0085] At 220, in response to and based on the condition of receiving the request from 215, DAMS 110 configures itself to begin servicing device 106a based on the request. In some embodiments, DAMS 110 may also send (not shown) instructions to distributor 108 to configure distributor 108 to service device 106a.

[0086] At 222, DAMS 110 generates, creates, calculates and / or retrieves digital assets for device 106a according to the request at 205. In various embodiments, DAMS 110 may create or generate the requested digital security assets, such as public and private key pairs and enrollment certificates and pseudonym certificates for device 106a.

[0087] In an alternative implementation of operation 222 ( Figure 2 106a), DAMS 110 requests and receives digital asset generation information associated with device 106a from distributor 108, such as enrollment and pseudonym public keys generated by and retrieved from device 106a, and data uniquely identifying device 106a (e.g., a microprocessor serial number). In such an embodiment, DAMS 110 then uses the enrollment and pseudonym public keys to generate digital assets, such as an enrollment certificate for device 106a and an appropriate number of pseudonym certificates.

[0088] At 225, the DAMS 110 transmits the digital asset to the distributor 108 of the manufacturer 105 that requested the digital asset service at 205. For example, the DAMS 110 may securely transmit the public and private key pair, the enrollment certificate, and the pseudonym certificate to the distributor 108 of the manufacturer 105.

[0089] At 226, the DAMS 110 transmits log information about the digital asset to the provisioning controller 120. In various embodiments, the log information may include information describing the request and transfer of the digital asset, such as the requester ID, the digital asset ID, the distributor ID, timestamps of the request and transfer actions, the received microprocessor serial number, etc. In some embodiments, 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, a database 125. The provisioning controller 120 actually retains an audit trail of all activities that occur in the system 100, which allows the compilation of multiple types of data, such as data about how and when the manufacturer 105 built and provisioned the device 106a. Such data and log information can be used for billing and auditing purposes.

[0090] At 230 , the distributor 108 receives and stores the digital assets (eg, public and private key pairs, enrollment certificates, and pseudonym certificates) sent by the DAMS 110 .

[0091] At 235, the distributor 108 requests and receives a digital security asset, such as a public key, from the device 106a, which can be used to securely transfer the digital asset from the distributor 108 to the device 106a. Various types of devices 106a can use a security processor built into the device 106 to generate a short key pair, and the public key can be part of the short key pair. At 240, the distributor 108 uses the digital security asset (e.g., the public key) to securely transfer the digital asset (e.g., the enrollment certificate) to the device 106a. In various embodiments, the distributor 108 can use the public key of the device 106a to form, for example, a virtual private network (VPN) with the device 106a and securely transfer the digital asset therein.

[0092] In various embodiments, the distributor 108 may employ transport layer security between it and the tester 107.

[0093] (TLS) to ensure secure communication with the tester 107 that can connect to the device 106a. In an embodiment where it is desired to securely communicate directly with the device 106a, the system can create a short-term public key pair for the device 106a and use the public key and the certificate from the distributor 108 (containing the public key of the distributor 108) to create a secure tunnel to the device 106a. In such an embodiment, the device 106a will run special code with the root public key of the system 100 to verify the certificate sent to it by the distributor 108.

[0094] Once a secure path is established between the device 106a or tester 107 and the distributor 108, the device 106a can create a registration and pseudonym public key pair (e.g., for a V2X ecosystem) and export the public key and other data to the distributor 108, which can then send the data to the DAMS 110 and the provisioning controller 120. As described above with reference to the alternative embodiment of operation 222, the DAMS 110 can use the received public key to create a registration certificate and a pseudonym certificate, and in some embodiments, there may be a large number of pseudonym certificates (e.g., 3000). In an alternative example of one embodiment, at operation 225, the DAMS 110 returns these certificates to the distributor 108 as described above. In some other embodiments, depending on where the provisioning is performed, the DAMS 110 may transmit these certificates to the distributor 131 instead of the distributor 108.

[0095] In some embodiments, for example, if device 106 has its own wireless or wired communication functionality and is at least partially operational, distributor 108 can communicate directly with device 106. In other embodiments, distributor 108 can communicate indirectly with device 106 via an intermediate device such as tester 107.

[0096] Device 106a receives the digital asset and stores it for use during operation. For example, if device 106a is an automotive onboard unit (OBU) or electronic control unit (ECU), and the digital asset is a security asset (e.g., a public key certificate) required to join a wireless network, the digital security asset is stored by the OBU. When the OBU is later installed and activated in the car, it will attempt to connect to the wireless network. Before allowing the OBU to connect to the network, the network will attempt to authenticate the OBU. Only when the OBU has a digital security asset provided by the distributor 108 at the manufacturer 105 can the OBU be authenticated and join the network.

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

[0098] At 250, the distributor 108 transmits the state information to the provisioning controller 120. Also, at 255, the provisioning controller 120 receives and stores the state information associated with the log information stored in operation 227. Thus, the provisioning controller 120 maintains an audit trail or audit log for all system 100 activities associated with each particular device 106. In various embodiments, the audit log may include: information indicating the success or failure of manufacturer provisioning (e.g., operations 235-245); the identity of the digital asset (and / or a copy of the digital asset itself); the type of password; and the like.

[0099] At 270, if the digital assets are successfully provisioned for the device 106a, the manufacturer 105 releases the device to the market. For example, the manufacturing company 105 may physically ship the device 106a to a company (e.g., a retailer) that is to install the device in its operating environment. Figure 1 In some embodiments, the device 106a may be fully programmed or provisioned and fully functional at this point in time; while in other embodiments, the device 106a may be only partially programmed or provisioned, or may not be fully functional or may not be functional at this point in time.

[0100] Figure 2The examples depicted are for illustrative purposes only and are not intended to be limiting. In addition, the example of process 200 depicted is intended to concisely and clearly explain certain novel and innovative features consistent with certain embodiments of the present disclosure, but the example is not intended to be limiting, and many variations are possible. For example, although the functions and operations are illustrated as being performed in a particular order, the order described is merely an example, and a variety of different sequences of operations consistent with certain embodiments of the present disclosure can be performed. In addition, for illustrative purposes only, operations are described as discrete steps, and in some embodiments, multiple operations may be performed simultaneously and / or as part of a single calculation or larger operation. The operations described are not intended to be exhaustive, limiting, or absolute, and various operations can be modified, inserted, or deleted. As examples of variations, although Figure 2 Generally described in the context of a single digital asset (e.g., a single digital certificate), the systems and processes will operate similarly to handle multiple digital assets (e.g., more than two digital certificates). For example, in the case where device 106a does not have secure communication capabilities, operations 235 and 240 may be omitted, and distributor 108 may communicate with device 106b using unencrypted communications.

[0101] As another example, in various embodiments, the provisioning controller 120 or a proxy authority (such as a specialized signer) may similarly communicate to the distributor 108 and cause it to load another or additional digital asset into the device 106b, including digital assets such as software, firmware, FUSE objects, manifest files, etc. In such embodiments, the provisioning controller 120 may additionally or alternatively retrieve, obtain, or otherwise access the requested digital asset from storage or direct access to the requested digital asset. For example ( Figure 2 106a), the provisioning controller 120 or its authorized agent can retrieve an executable software image (e.g., a compiled computer program stored in the database 125) to be loaded into and run by the device 106a, and send the executable software image to the distributor 10 to be programmed into the device. In various embodiments, the digital assets accessed by the provisioning controller 120 can only include software that is securely provisioned, released, and / or authorized by the manufacturer 105 of the device 106a, so that no unauthorized software is loaded into the device 106a. In some embodiments, the digital assets retrieved by the provisioning controller 120 can be stored in a storage device or database associated with the provisioning controller 120, such as Figure 1 in database 125.

[0102] Figure 32 is a swim lane diagram illustrating an example of a process 200 for securely provisioning a computerized device according to an embodiment of the present invention. In various embodiments, some or all of the processes 300 or operations shown may be performed by executing code on a general purpose computing system (which may include one or more processors or one or more computing subsystems) by a pure hardware system or a system that has both. Figure 3 As shown above, the entities involved in process 300 include an installer 130 of computerized device 106, a distributor 131 located at installer 130, provisioning controller 120, and DAMS 110. In various embodiments, these entities may be as described with reference to Figure 1 and entities described throughout this disclosure, and may communicate with each other.

[0103] like Figure 3 As shown in the example in FIG. 3 , the process 300 begins at 305, and the installer 130 receives a device 106b (eg, an OBU or ECU) manufactured and released or shipped by the manufacturer 105 (see Figure 2 270 in operation 310). At 310, the installer 130 may install the device 106b into its operating environment, such as into a larger system. For example, the installer 130 may be an automobile manufacturer that purchases the OBU from the manufacturer 105, and the installer 130 may install the OBU into the automobile. In various embodiments, installing the device 106b may include testing the operation, function, etc. of the device 106b after installation and collecting relevant status data.

[0104] In some embodiments, the device 106b may be only partially provisioned and not fully functional. For example, the manufacturer 105 of the device 106b may only provision the device 106b with a registration certificate, such that the device 106b needs to be further provisioned with another digital certificate, such as a pseudonym certificate, in order to obtain full functionality, such as the ability to communicate with another fully programmed device 106.

[0105] At 315, the installer 130 (e.g., employee 132) transmits the installation status data to the provisioning controller 120. In various embodiments, the installation status data includes an immutable identifier of the installed device, such as a serial number or other fixed unique identification information, such as a public key in a key pair that is never erased once generated. The installation status data may also include other information, such as a unique identifier of the installer 130, information indicating how and when the device 106b was installed, information about test results completed on the installed device 106b, information certifying that the installer 130 installed the device 106b in accordance with applicable specifications, contract requirements and / or instructions, and / or other similar information.

[0106] At 320, the provisioning controller 120 determines whether the user from the installer 130 is an authorized user. If not, the provisioning controller 120 rejects the installation status communication ( Figure 3 (not shown). On the other hand, if an authorized user is making a request (320, yes), the provisioning controller 120 determines (325) whether the device 106b identified in the installation status data is an authorized device. In some embodiments, the provisioning controller 120 can determine that the device 106b is authorized by verifying against information previously stored in its database 125 that: 1) there is a record for the device 106b in its database 125; 2) the record indicates that the device 106b has been successfully provisioned at the manufacturer 105; 3) the record indicates that the device 106b has been sent to the installer 130 (which has been verified as an authorized installer at 320).

[0107] If the device identified in the installation state data is not authorized, the provisioning controller 120 rejects the installation state communication ( Figure 3 On the other hand, if the device 106b identified in the installation status data is authorized (325, yes), then at 330, the provisioning controller 120 stores the installation status data and log information associated with the device 106b. Figure 2 As described in operation 227 in , log information associated with device 106 b may have been previously stored in database 125 .

[0108] At 335, the provisioning controller 120 directs, instructs, or otherwise controls the DAMS 110 to fulfill the provisioning request, for example, by transmitting to the DAMS 110 a request to provision the device 106b at the installer 130. At 340, in response to and based on the request received from 335, the DAMS 110 generates and / or retrieves the digital asset requested at 335. In various embodiments, as described with reference to Figure 2 As described, the DAMS 110 may create or generate the requested digital asset, such as a pseudonym certificate or other public key certificate. In various embodiments, the DAMS 110 or the provisioning controller 120 instead of the DAMS 110 may additionally or alternatively retrieve, obtain, or otherwise access the requested digital asset from storage, such as an executable image previously stored in the database 125, for use in a device of the device 106b type.

[0109] At 345, the DAMS 110 transmits the digital asset to the distributor 131 of the installer 130 that transmitted the installation status at 315. For example, the DAMS 110 may securely transmit the pseudonym certificate to the distributor 131 of the installer 130.

[0110] At 350, the distributor 131 performs the same Figure 2At 355, the distributor 131 transmits the state information to the provisioning controller 120. Also, at 360, the provisioning controller 120 receives and stores the state information associated with previously stored information about the device 106 b, such as the state information stored in operation 227. Thus, the provisioning controller 120 continues an audit trail or audit log for all system 100 activities associated with each particular device 106.

[0111] Figure 3 The example of process 300 depicted in the description is for illustrative purposes only and is not intended to be limiting. In addition, the example of process 300 depicted is intended to concisely and clearly explain certain novel and innovative features consistent with certain embodiments of the present disclosure, but many variations are possible. For example, although functions and operations are illustrated as being performed in a particular order, the described order is merely an example, and various different sequences of operations consistent with certain embodiments of the present disclosure can be performed. In addition, for illustrative purposes only, operations are described as discrete steps, while in some embodiments, multiple operations can be performed simultaneously and / or as part of a single calculation or larger operation. The operations described are not intended to be exhaustive, limiting, or absolute, and various operations can be modified, inserted, or deleted.

[0112] Figure 4A and Figure 4B is an example architecture block diagram for implementing a scalable and secure certificate management system (CMS) 400 according to an embodiment of the present invention. Various embodiments of the scalable CMS 400 can be used for a very large number of devices to perform transaction and certificate generation processing. In various embodiments, the scalable CMS 400 can be implemented using multiple servers, HSMs, multiple computers or computing engines, and multiple application platforms. Figure 4A and Figure 4B In the example implementation shown, the application platform may include one or more virtual machines.

[0113] (VM). In additional or alternative embodiments, the application platforms may each include one or more hardware platforms, such as an application server, computer, or other computer hardware capable of hosting and executing software applications. Figure 4A and Figure 4BIn the example of , the application platform 430 for the enrollment certificate authority can be one or more VMs running the enrollment certificate authority application, and the application platform 440 for the pseudonymous certificate authority can be one or more VMs operable to host and run the pseudonymous certificate authority application. Similarly, the application platform 450 for the first link authority can be one or more VMs configured to host and run the first link authority application, and the application platform 460 for the second link authority can be one or more VMs operable to host and run the second link authority application. The example of the scalable CMS 400 can be implemented in a private data center, a cloud data center such as Amazon Web Services (AWS) from Amazon, or a hybrid of a private data center and a cloud data center.

[0114] In some embodiments, the scalable CMS 400 can provide security certificates, such as registration certificates and pseudonym certificates, for use by the distributor 108 of the manufacturer 105, which can be described in detail in detail in detail in FIG. Figure 1 and operate as described elsewhere in this disclosure. In some embodiments, the scalable CMS 400 may be used in conjunction with the scalable CMS 400 described above. Figure 1 A digital asset management system (DAMS) 110 is described to interact in order to provide certificates to the distributor 108.

[0115] like Figure 4A As shown in the example in , the architecture of CMS 400 may include two provisioning controllers 120, namely a primary provisioning controller and a backup provisioning controller, which are preferably implemented in separate servers. The two provisioning controllers 120 include functionality that causes objects, data, etc. contained in the primary provisioning controller to be replicated or otherwise contained in the backup (secondary) provisioning controller. If the primary provisioning controller goes offline for any reason, the backup provisioning controller can be brought online to replace the primary provisioning controller. This provides continuous availability (or extremely high availability) of the provisioning controllers 120. In various embodiments, the primary provisioning controller and the backup provisioning controller can be as described in reference to Figure 1 In various embodiments, the provisioning controller 120 may be configured as described in the referenced Figure 1 The connection and communication between the provisioning controller 120 and the manufacturer's distributor 108 is connected to the scalable CMS 400 in the same or similar manner as described above.

[0116] In general, the provisioning controller 120 manages the system elements comprising the infrastructure so that only explicitly authorized elements can participate in and interact with the scalable CMS 400. In various embodiments, the provisioning controller 120 can be integrated with the employee identification and authorization system of the user (e.g., the manufacturer 105 or the installer 130), or it can provide its own identification and authorization capabilities so that only authorized users can use the scalable CMS 400. In some embodiments, the provisioning controller 120 can be a device lifecycle management (DLM) controller, such as a primary DLM controller and a backup DLM controller. In various embodiments, the provisioning controller 120 can be a controller that exists in the CMS 400 by component type. For example, in Figure 4A and Figure 4B In the example, the provisioning controller 120 may be a set or a pair of controllers that exist for the registration approval authority 420 , the enrollment certificate authority 430 , the pseudonym certificate authority 440 , and the linking authority 450 , 460 .

[0117] like Figure 4A and Figure 4B As shown, the architecture of the scalable CMS 400 includes a representational state transfer

[0118] (REST) ​​Web services, a registration authority 405, a registration authority 420, a registration authority computing engine 425, an enrollment certificate authority 430, an enrollment certificate authority computing engine 435, a pseudonymous certificate authority 440, a pseudonymous certificate authority computing engine 445, a first link authority 450, a first link authority computing engine 455, a second link authority 460, a first link authority computing engine 465, message queues 410, 411, 412, 413, 414, 415, 416, 417, 418, 419, and one or more databases 470. The following paragraphs describe each of these components.

[0119] The architecture of the scalable CMS 400 advantageously distinguishes between non-safety related applications and safety functions. Figure 4A and Figure 4BAs shown in the example in , the registration approval authority 420, the enrollment certificate authority 430, the pseudonym certificate authority 440, and the link authority 450, 460 are implemented as applications on their own VMs, which are executed on their own dedicated computing engines 425, 435, 445, 455 and 465, all of which are separated from any non-security related applications and functions. This has technical and security advantages and improvements over conventional systems, in which the HSM's performance is slower, the cloud service provider cannot supply the HSM, or it is impossible to determine the correct management of the HSM by the system. In the scalable CMS 400, all cryptographic operations requiring the HSM are performed in a computing engine (e.g., one or more of the computing engines 425, 435, 445, 455 and 465).

[0120] like Figure 4A and Figure 4B As shown, by separating critical security functions from each other and onto separate compute engines, for example, computationally intensive cryptographic and security functions (e.g., elliptic curve butterfly expansion computations or elliptic curve digital signatures) performed by registry authority 420, enrollment certificate authority 430, pseudonym certificate authority 440, and link authority 450, 460 can be performed much faster than existing registry authority systems. This design can significantly improve transaction processing by enabling "bottleneck" applications to be individually scaled as needed. As such, a specific system architecture with technical advantages is provided according to embodiments of the present disclosure that can reduce bottlenecks associated with existing registry authority systems. For example, if the registry authority applications running on registry authorities 405 and 420 need to be scaled, additional VMs can be added without making any changes to the secure computing capabilities of registry authority compute engine 425. Alternatively, if secure computing is limiting performance, additional secure registry authority compute engines 425 can be added. The same multi-dimensional scaling also applies to other components of CMS 400. These capabilities can provide significant performance improvements and scalability compared to existing security credential management systems (SCMS).

[0121] exist Figure 4A and Figure 4B In the example shown, the registration authority 405 is connected to other components, and the other components are connected to each other, through a messaging subsystem or message queuing service, including input message queues 410, 411, 412, 413, 414, 415, 416, 417, 418, and 419. Figure 4A and Figure 4BIn the example implementation, input message queues 410, 411, 412, 413, 414, 415, 416, 417, 418, and 419 are unidirectional queues because the messages in these queues flow in one direction (e.g., from the client to the server). By using a single input queue for each VM and compute engine, a simplified technical advantage can be provided.

[0122] In some embodiments, the messaging service may be a fast message queuing service, such as Amazon Simple Queue Service (SQS) provided by Amazon Web Services. For example, according to such an embodiment, the message queues 410, 411, 412, 413, 414, 415, 416, 417, 418, and 419 may be SQS message queues. By using the input message queues 410, 411, 412, 413, 414, 415, 416, 417, 418, 419 to communicatively connect the application VMs and the computing engines to each other, the application VMs and the computing engines can be scaled independently as needed. In other words, since each application platform for the registration approval authority 420, the registration certificate authority 430, the pseudonym certificate authority 440, and the link authority 450, 460 is communicatively connected to the computing engines 425, 435, 445, 455, and 465 via each set of input message queues, these components of the CMS 400 and the database 470 are all scaled independently of each other.

[0123] As mentioned above and Figure 4A and Figure 4B As shown in the non-limiting example of , each of the registration approval authorities 405, 420, the certificate issuing authorities 430, 440, and the link authority authorities 450, 460 can be implemented as applications on their own virtual machines (VMs). In additional or alternative embodiments, one or more of the registration approval authorities 405, 420, the certificate issuing authorities 430, 440, and the link authority authorities 450, 460 can be executed on a hardware platform (e.g., a server or a computing engine). The following paragraphs describe the role and function of each application executed on the application platform (e.g., a VM or a hardware platform).

[0124] In various embodiments, the registration authority 405 may be an authority in the provisioning network that verifies user requests for digital certificates or other types of digital security assets and enables certificate authorities (e.g., the enrollment certificate authority 430 and the pseudonym certificate authority 440) to issue digital certificates. In various embodiments, the registration authority 405 may be similar to registration authorities known in public key infrastructure (PKI) systems. In various embodiments, the registration authority 405 may be implemented as a representational state transfer (REST) ​​Web service. Figure 4AAs represented by the three "stacked" rectangles shown for the Registration Approval Authority 405, in various embodiments, there may be multiple instances of the Registration Approval Authority 405 executing simultaneously. Figure 4A and Figure 4B The other "stacked" elements of the CMS 400 are similarly represented. The registration authority function of the CMS 400 is decentralized in that its functions can be performed by multiple instances of the registration authority 405 and multiple instances of the registration authority 420 implemented as REST Web services. The primary role of the registration authorities 405, 420 is to grant and fulfill certificate provisioning requests while the signing pseudonymous certificate authority 440 is unaware of which certificates ultimately appear in a particular computerized device. The registration authorities 405, 420 interact directly with the pseudonymous certificate authority 440, the chaining authorities 450, 460 via message queues 414, 416 and 418 in order to fulfill their roles in the CMS 400.

[0125] As indicated by the "DB" arrow that appears in the lower left corner of the rectangle, the registration authority 405 (and Figure 4A and Figure 4B Other components shown by "DB" arrows in the figure) can be connected to respective databases 470. Although Figure 4A Only a single database 470 is shown, but it should be understood that CMS 400 may utilize a collection of data stores or databases 470 for data storage and retrieval. For example, database 470 may be composed of one or more database logical or physical units, each with one or more tables, to achieve data separation when necessary. As used herein, the term "database" refers to one or more databases or data stores. In some embodiments, the use of multiple databases 470 allows the registration authority 405 to communicate with the registration authority 405. Figure 4A and Figure 4B The data separation between other components shown by the "DB" arrows in FIG. For example, such use of multiple databases 470 allows data separation between registration approval authorities 405, 420, certificate issuing authorities 430, 440 and linking authority authorities 450, 460.

[0126] In a preferred embodiment, database 470 is a collection of one or more fast-access, low-latency databases. In some embodiments, database 470 may be a NoSQL database or database service, such as the DynamoDB data service provided by Amazon Web Services. In various embodiments, the data stored in database 470 is application-related, but may include certificates issued in the past, various link authority values, data on devices to which certificates have been issued, operator actions, etc. It should be noted that this data may be stored unencrypted, encrypted, or some combination thereof.

[0127] In various embodiments, scalable CMS 400 includes an enrollment certificate authority 430 and a pseudonymous certificate authority 440 because the digital certificates generated by registration authority 405 are divided into different segments, eg, enrollment digital certificates and pseudonymous digital certificates.

[0128] The enrollment certificate authority 430 is a decentralized component of the CMS 400, as there may be multiple instances of the enrollment certificate authority 430 executing simultaneously. Figure 4A As shown in the figure, there may be multiple instances of the enrollment certificate authority 430 executing simultaneously. The enrollment certificate authority 430 may receive a request for an enrollment certificate from the registration approval authority 420. The main role of the enrollment certificate authority 430 is to fulfill the request from the registration approval authority 420 to issue an enrollment certificate to the end-user device.

[0129] (such as Figure 1 The distributor 108 of the manufacturer 105 shown here issues a registration certificate. Figure 5A As described, the Enrollment Certificate Authority 430 interacts directly with the Registration Approval Authority 420 in order to perform its role within the CMS 400 .

[0130] The pseudonymous certificate authority 440 is a decentralized component of the CMS 400, as there may be multiple instances of the pseudonymous certificate authority 440 executing simultaneously. Figure 4A As shown in FIG. 1 , there may be multiple instances of the pseudonymous certificate issuing authority 440 executing in parallel in various embodiments. The pseudonymous certificate issuing authority 440 may receive a request for a pseudonymous certificate from the registration approval authority 420. The primary role of the pseudonymous certificate issuing authority 440 is to fulfill requests from the registration approval authority 420 to issue a pseudonymous certificate to an end-user device such as Figure 1 In some embodiments, the pseudonym certificate authority 440 fulfills requests for short-term pseudonym certificates for V2V functions. Figure 5B As described, the Pseudonym Certificate Authority 440 interacts directly with the Registration Authority 420 in order to perform its functions within the CMS 400 .

[0131] In various embodiments, Figure 4BThe link authority 450, 460 shown links the identity of the certificate requester (i.e., the unique identifier of the certificate requester device) to the issued pseudonym certificate for revocation. In other words, the first link authority 450 and the second link authority 460 provide their respective link values ​​as the unique identifier of the certificate requester device to the issued pseudonym certificate. The first link authority 450 and the second link authority 460 can receive a request for a link value from the registration approval authority 420 and then provide the requested link value to the registration approval authority 420. As described below with reference to Figure 5A As described, the link authority authorities 450, 460 interact directly with the registration approval authority 420 in order to fulfill requests for link values.

[0132] In various embodiments, the compute engines 425, 435, 445, 455, and 465 and the provisioning controller 120 include an HSM, which allows these components to perform secure computations without undue threat from hackers. In some embodiments, the compute engines 425, 435, 445, 455, and 465 can be designed to perform secure computations themselves without an embedded HSM, in which case they are embodied as an HSM.

[0133] In various embodiments, different HSM versions may be used in CMS 400. For example, the HSM may include an embedded HSM installed as a plug-in card within one or more of computing engines 425, 435, 445, 455, and 465. In such an example embodiment, the embedded HSM may be interconnected as a peripheral component.

[0134] (PCI) HSM or PCI Express (PCIe) HSM installed in one or more computing engines. Likewise, the HSM in CMS400, for example, may include network-attached or network-connected external HSMs that are separate from the computing engines in their own chassis.

[0135] Those skilled in the art will recognize that Figure 4A and Figure 4B The components, processes, data, operations and implementation details shown are examples presented for simplicity and clarity of explanation. Other components, processes, implementation details and variations may be used without departing from the principles of the present invention, as this example is not intended to be limiting, but many variations are possible.

[0136] Figure 5A and Figure 5Bis a swim lane diagram illustrating an example process 500 for securely providing credentials such as certificates according to an embodiment of the present invention. In various embodiments, some or all of the process 500 or operations shown may be performed by executing code on a general purpose computing system (which may include one or more processors or one or more computing subsystems) by a pure hardware system or a system that has both. Figure 5A and Figure 5B As shown above, the entities involved in process 500 include distributor 108 at manufacturer 105, registration authority 420 of CMS host, link authority 450, 460, pseudonym certificate authority 440 and enrollment certificate authority 430. In various embodiments, these entities may be as described in reference Figure 4A and Figure 4B and entities described throughout this disclosure, and may communicate with each other.

[0137] like Figure 5A As shown in the example of FIG, process 500 begins with registration-related operations 505-535. The primary role of the registration certificate authority 430 is to fulfill requests from the registration approval authority 420 to issue a registration certificate to an end-user device, such as the distributor 108. As described below with reference to the registration-related operations 505-535, the registration certificate authority 430 interacts directly with the registration approval authority 420 in order to issue the requested registration certificate to the distributor 108.

[0138] At 505, the distributor 108 of the manufacturer 105 requests a registration certificate from the registration authority 420, wherein the registration certificate is to be provisioned to (e.g., for use by) the device 106a, and the request may identify the device 106a as the destination for the registration certificate. The request may be, for example, the distributor 108 at the manufacturer 105 requesting a registration certificate for a new device 106A (e.g., a new product). Figure 2 As described, a registration certificate is a public key certificate that identifies its holder as an authorized participant in an ecosystem, in which all participants must share a valid registration certificate, and authorized participants can also receive pseudonymous certificates that enable devices 106 within the ecosystem to communicate and operate (for example, in the example of USDOT's V2X ecosystem, enabling communication and operation between vehicles and roadside infrastructure).

[0139] At 510, a request for an enrollment certificate is received at the enrollment approval authority 420 and then transmitted from the enrollment approval authority 420 to the enrollment certificate issuing authority 430. In various embodiments, the operation may involve the enrollment approval authority 420 decrypting and verifying the request, including signature verification, checking the revocation status of the device (e.g., device 106a) that is the destination of the enrollment certificate using a list of unapproved devices (e.g., a blacklist), and determining whether the requester (e.g., distributor 108) is allowed to request the enrollment certificate from the enrollment approval authority 420. For example, operation 510 may include determining whether a user from the manufacturer 105 is an authorized user (e.g., part of the staff 109). In some embodiments, at 510, the enrollment approval authority 420 may also determine whether the device 106a (e.g., a product) to receive the enrollment certificate has been approved for use with the system 100. In some cases, the list of approved devices (e.g., a whitelist) may be provided by Figure 1 The supervisor 140 in the and is used by the provisioning controller 120 to make such a determination. After verifying the request for the enrollment certificate, the request is transmitted from the registration approval authority 420 to the enrollment certificate issuing authority 430. The request can be sent as an enrollment certificate generation request created by the registration approval authority 420.

[0140] At 515, a request for an enrollment certificate is received at enrollment certificate authority 430. In response to receiving the request, at 520, enrollment certificate authority 430 generates the requested enrollment certificate and transmits the generated enrollment certificate back to registration approval authority 420. At 525, the enrollment certificate is received at registration approval authority 420, and at 530, registration approval authority 420 transmits the enrollment certificate to distributor 108. Distributor 108 receives the enrollment certificate at 535. At this point, distributor 108 may provision the enrollment certificate to a device (e.g., device 106a) so that the device can use the enrollment certificate and complete enrollment-related operations.

[0141] Operations 540-599 are related to provisioning a pseudonym certificate. At 540, the distributor 108 requests a pseudonym certificate from the registration authority 420. The pseudonym certificate is to be provisioned to the device 106a (e.g., for use by it), and the request may identify the device 106a as the destination of the pseudonym certificate. The request may be, for example, a request by the distributor 108 of the manufacturer 105 to a computerized device (e.g., the registered device 106A) that previously received a registration certificate for a pseudonym certificate. The pseudonym certificate includes a certain amount of public key certificates (e.g., one week's worth, one month's worth, or one year's worth).

[0142] At 545, a request for a pseudonym certificate is received at the registration approval authority 420, which then initiates provisioning of the pseudonym certificate.

[0143] At operations 550-570, the link authority 450, 460 interacts directly with the registration approval authority 420 to fulfill the request for link values. At 550, the registration approval authority 420 transmits to the first link authority 450 a request for a first set of link values ​​(LA1).

[0144] At 555, in response to receiving the request for the first set of link values, the first link authority 450 generates and transmits the first set of link values ​​to the registration approval authority 420. At 557, the first set of link values ​​is received at the registration approval authority 420. At 560, the registration approval authority 420 transmits a request for a second set of link values ​​(LA2) to the second link authority 460.

[0145] Next, if Figure 5B As shown, at 565, in response to receiving the request for the second set of linking values, the second linking authority 460 generates and transmits the second set of linking values ​​to the registration-approval authority 420. At 570, the second set of linking values ​​is received at the registration-approval authority 420.

[0146] In certain embodiments, Figure 5A and Figure 5B The chaining authorities 450, 460 are shown chaining the identity of the certificate requester (i.e., the unique identifier of the certificate requester device) to the issued pseudonym certificate for revocation. In other words, as part of process 500, the first chaining authority 450 and the second chaining authority 460 provide the first set of chaining values ​​and the second set of chaining values ​​as the unique identifier of the certificate requester device to the pseudonym certificate issued by the pseudonym certificate issuing authority 440, respectively. The first chaining authority 450 and the second chaining authority 460 receive the request for chaining values ​​sent from the registration approval authority 420 in operations 550 and 560, and then provide the requested chaining values ​​to the registration approval authority 420 in operations 555 and 565.

[0147] In a non-limiting example implementation, the request for link value and the response to the request exchanged in operations 550-570 may include messages having header and payload data items as follows:

[0148]

[0149]

[0150]

[0151] Continue to refer to Figure 5BAt 575, the registration approval authority 420 transmits a request for a pseudonym certificate to the pseudonym certificate issuing authority 430. The request may be sent as a batch of pseudonym certificate generation requests created by the registration approval authority 420.

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

[0153] At 595, the distributor 108 may send multiple requests to the registration approval authority 420 to query whether the requested pseudonym certificate is ready (i.e., generated and available). In some embodiments, the query in operation 595 may be sent at any time after the request for the pseudonym certificate is sent in operation 540. For example, after sending the request for the pseudonym certificate to the registration approval authority 420 in operation 540, the distributor 108 may periodically send queries to the registration approval authority 420 to determine whether the requested pseudonym certificate is ready. In this example, one or more queries in operation 595 may be sent in parallel with operations 545-590 (i.e., while the pseudonym certificate is being generated).

[0154] At 598, when the pseudonym certificates are ready, the registration authority 420 transmits the pseudonym certificates to the distributor 108. At 599, the distributor 108 receives the pseudonym certificates. At this point, the distributor 108 can provision the pseudonym certificates to the device (e.g., device 106a), enabling the device to use these pseudonym certificates, and completing the operation of provisioning the pseudonym certificates.

[0155] In certain non-limiting example embodiments, the request for a pseudonym certificate and the response thereto exchanged in operations 575-590 may include messages having header and payload data items as follows:

[0156]

[0157] Fig. 6A and Figure 6B 610 , 611 , 612 , 613 , 614 , 615 , 616 , 617 , 618 , 619 , 619 are block diagrams of an example architecture for implementing a scalable and secure CMS 600 using bidirectional message queues 610 , 611 , 612 , 613 , 614 , 615 , 616 , 617 , 618 , 619 , according to an embodiment of the present invention.

[0158] As mentioned above Figure 4A and Figure 4BVarious embodiments of the described CMS 400 and scalable CMS 600 can be used for extremely large numbers of device transactions and certificate generation processing. In some embodiments, the scalable CMS 600 can be implemented using multiple servers, HSMs, multiple computers or computing engines, and multiple application platforms (e.g., VMs or hardware platforms). Fig. 6A and Figure 6B In the example implementations shown, 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 servers, computers, or other computer hardware capable of executing software applications. Examples of scalable CMS 600 may be implemented in a private data center, a cloud data center such as Amazon Web Services (AWS) from Amazon, or a hybrid of a private data center and a cloud data center. For simplicity, only the following description will be given. Fig. 6A and Figure 6B Internal Figure 4A and Figure 4B The difference that exists.

[0159] like Fig. 6A As shown in the example in FIG. 1 , the architecture of CMS 600 may include two provisioning controllers 602, namely a primary provisioning controller and a backup provisioning controller, which are preferably implemented in separate servers. The two provisioning controllers 602 include Figure 4A The provisioning controller 102 in FIG. 100 has similar functions to those in FIG. 101 , so as to provide a reference to FIG. 102 in FIG. 101 for the purpose of Figure 4A For the purpose of failover, objects, data, etc. contained in the primary provisioning controller are replicated or otherwise included in the backup (secondary) provisioning controller. In some embodiments, the provisioning controller 602 may be a DLM controller, such as a primary DLM controller and a backup DLM controller. In various embodiments, the provisioning controller 602 may be a controller that exists in the CMS 600 by component type. Fig. 6A and Figure 6B In the example of , the provisioning controller 602 may be a pair of controllers (eg, a primary controller and a backup controller) that exist for the registration approval authority 620 , the enrollment certificate authority 430 , the pseudonym certificate authority 440 , and the linking authorities 450 , 460 .

[0160] like Fig. 6A and Figure 6BAs shown, the architecture of the scalable CMS 600 includes a registration authority 605 implemented as a REST web service, a registration authority 620, a registration authority computing engine 625, an enrollment certificate authority 630, an enrollment certificate authority computing engine 635, a pseudonymous certificate authority 640, a pseudonymous certificate authority computing engine 645, a first link authority 650, a first link authority computing engine 655, a second link authority 660, a first link authority computing engine 665, bidirectional message queues 610, 611, 612, 613, 614, 615, 616, 617, 618, 619 and a database 670.

[0161] The scalable CMS 600 architecture advantageously separates non-safety-related applications from safety functions. Fig. 6A and Figure 6B In a non-limiting example, the registration authority 620, the enrollment certificate authority 630, the pseudonym certificate authority 640, and the link authority 650, 660 are implemented as applications on their own VMs, which are executed on their own dedicated computing engines 625, 635, 645, 655 and 665, all of which are separated from any non-security related applications and functions. This provides technical and security advantages and improvements over conventional systems, in which the HSM's performance is slower, the cloud service provider cannot supply the HSM, or it is impossible to determine the correct management of the HSM by the system. In the scalable CMS 600, all cryptographic operations requiring the HSM are performed in the computing engine (e.g., one or more of the computing engines 625, 635, 645, 655 and 665). In other words, in the CMS 600, all cryptographic operations requiring the HSM are performed in the computing engine.

[0162] like Fig. 6A and Figure 6B As shown, by separating critical security functions from each other and onto separate compute engines, for example, computationally intensive cryptographic and security functions performed by registry authority 620, enrollment certificate authority 630, pseudonym certificate authority 640, and link authority 650, 660 can be performed much faster than existing registry authority systems. This design can significantly improve transaction processing by allowing "bottleneck" applications to be scaled individually as needed. For example, if the registry authority applications running on registry authorities 605 and 620 need to be scaled, additional application platforms (e.g., VMs or hardware platforms) can be added without making any changes to the secure computing capabilities of registry authority compute engine 625. Similarly, for example, if secure computing is limiting performance, additional secure registry authority compute engines 625 can be added. The same multi-dimensional scaling also applies to other components of CMS 600.

[0163] exist Fig. 6A and Figure 6B In the example shown, the registration authority 605 is connected to other components, and the other components are connected to each other, via bidirectional message queues 610, 611, 612, 613, 614, 615, 616, 617, 618, and 619. Fig. 6A and Figure 6B In the example implementation, bidirectional message queues 610, 611, 612, 613, 614, 615, 616, 617, 618, and 619 are bidirectional queues because messages in these queues flow bidirectionally.

[0164] (e.g., between a client and a server). This provides the performance advantage of separating new requests from pending responses in a message queue. By using two-way message queues 610, 611, 612, 613, 614, 615, 616, 617, 618, and 619 to allow application platforms (e.g., VMs and / or hardware platforms) and computing engines to communicate with each other, the application platforms (e.g., VMs and / or hardware platforms) and computing engines can be scaled independently. In CMS 600, each application platform (e.g., VM and / or hardware platform) for a registration approval authority 620, a registration certificate authority 630, a pseudonym certificate authority 640, and a link authority 650, 660 is communicatively connected to computing engines 625, 635, 645, 655, and 665 via each set of two-way message queues.

[0165] In CMS 600, the registration authority 605 (and Fig. 6A and Figure 6B 670) can be connected to a database 670. In a preferred embodiment, the database 670 is a fast-access, low-latency database. In some embodiments, the database 670 can be a NoSQL database or database service, such as the DynamoDB data service provided by Amazon Web Services. In various embodiments, the data stored in the database 670 is application-related, but can include previously issued certificates, various link authority values ​​(such as link values), data on devices to which certificates have been issued, operator actions, etc. The data can be stored unencrypted, encrypted, or some combination thereof.

[0166] In various embodiments, scalable CMS 600 includes an enrollment certificate authority 630 and a pseudonymous certificate authority 640 because the digital certificates generated by the registration authority 605 are divided into different segments, eg, enrollment digital certificates and pseudonymous digital certificates.

[0167] like Fig. 6AAs shown in the three "stacked" rectangles of the enrollment certificate authority 630, in some embodiments, there may be multiple instances of the enrollment certificate authority 630 executing simultaneously. Fig. 6A and Figure 6B The other "stacked" elements of are similarly represented. The enrollment certificate issuing authority 630 may receive multiple requests for enrollment certificates from the registration approval authority 620.

[0168] In various embodiments, the compute engines 625, 635, 645, 655, and 665 and the provisioning controller 602 include an HSM that allows these components to perform secure computations without undue threat from hackers. In some embodiments, the compute engines 625, 635, 645, 655, and 665 can be designed to perform secure computations themselves without an embedded HSM, in which case they are embodied as an HSM.

[0169] Those skilled in the art will recognize that Fig. 6A and Figure 6B The components, processes, data, operations and implementation details shown are examples presented for simplicity and clarity of explanation. Other components, processes, implementation details and variations may be used without departing from the principles of the present invention, as this example is not intended to be limiting, but many variations are possible.

[0170] Fig. 7A and Figure 7B is a block diagram of an example architecture of a scalable and secure CMS 700 using load balancers 710, 711, 712, 713, 714, 715, 716, 717, 718, 719 according to an embodiment of the present invention.

[0171] As with CMS 400 and CMS 600 described above with reference to FIGS. 4 and 6 , various embodiments of scalable CMS 700 may be used for very large numbers of device transactions and certificate generation processes. Fig. 7A and Figure 7B The difference between the figure 4 and the figure 6 is shown in the figure. Fig. 7A and Figure 7B In the illustrated example implementation, the application platform is depicted 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 an application server, a server farm, a cloud-based server, a processor configured to perform application operations, or other computer hardware capable of executing software applications.

[0172] like Fig. 7AAs shown in the example in FIG. 1 , the architecture of CMS 700 may include two provisioning controllers 702, namely a primary provisioning controller and a backup provisioning controller, which are preferably implemented in separate servers. The two provisioning controllers 702 respectively include Figure 4A and Fig. 6A The provisioning controller 120 and 602 in FIG. 6 have similar functions. In other words, for the above reference Figure 4A The purpose of the failover is to copy or otherwise include objects, data, etc. contained in the primary provisioning controller in the backup (secondary) provisioning controller.

[0173] like Fig. 7A and Figure 7B As shown, the architecture of the scalable CMS 700 includes a registration approval authority 705 implemented as a REST web service, a registration approval authority 720, a registration approval authority computing engine 725, an enrollment certificate authority 730, an enrollment certificate authority computing engine 735, a pseudonymous certificate authority 740, a pseudonymous certificate authority computing engine 745, a first link authority 750, a first link authority computing engine 755, a second link authority 760, a first link authority computing engine 765, load balancers 710, 711, 712, 713, 714, 715, 716, 717, 718, 719 and a database 770.

[0174] As with CMS 400 and CMS 600 in FIGS. 4 and 6 , the architecture of scalable CMS 700 advantageously separates non-safety-related applications from safety functions. Fig. 7A and Figure 7B As shown in the non-limiting example in FIG, the registration authority 720, the enrollment certificate authority 730, the pseudonym certificate authority 740, and the link authority 750, 760 are implemented as applications on their own VMs, which execute on their own dedicated compute engines 725, 735, 745, 755, and 765, all of which are separated from any non-security related applications and functions. In the scalable CMS 700, all cryptographic operations that require HSM are performed in the compute engines (e.g., one or more of the compute engines 725, 735, 745, 755, and 765). In the CMS 700, all cryptographic operations that require HSM are performed in the compute engines.

[0175] like Fig. 7A and Figure 7BAs shown, by separating critical security functions from each other and onto separate computing engines, for example, the computationally intensive cryptographic and security functions performed by the registry authority 720, the enrollment certificate authority 730, the pseudonym certificate authority 740, and the link authority 750, 760 can be performed much faster than known registry solutions. This design can significantly improve transaction processing by enabling "bottleneck" applications to be individually scaled on demand without being constrained by server processing or storage capabilities. For example, if the registry application running on the registry 705 and 720 needs to be scaled, additional application platforms (e.g., VMs or hardware platforms) can be added without making any changes to the secure computing capabilities of the registry computing engine 725. Similarly, for example, if secure computing is limiting performance, additional secure registry computing engines 725 can be added. The same multi-dimensional scaling also applies to other components of the CMS 700.

[0176] exist Fig. 7A and Figure 7B In the example shown, the registration authority 705 is connected to the other components, and the other components are connected to each other, through load balancers 710, 711, 712, 713, 714, 715, 716, 717, 718, and 719. Fig. 7A and Figure 7B In the example implementation of , load balancers 710, 711, 712, 713, 714, 715, 716, 717, 718, and 719 may be implemented as virtual load balancers (e.g., virtual load balancers running on VMs) or via dedicated hardware. Fig. 7A and Figure 7B As shown, in CMS 700, each load balancer 710, 711, 712, 713, 714, 715, 716, 717, 718 and 719 is inserted in front of each group of similar types of VMs or computing engines. This provides the following benefits, namely, one or more clients only see a single server endpoint, and the load balancer determines which server will handle a given request. In this way, the load balancers 710, 711, 712, 713, 714, 715, 716, 717, 718, 719 enable application platforms (such as VMs and / or hardware platforms) and computing engines to communicate with each other. In CMS 700, each application platform for the registration approval authority 720, the registration certificate authority 730, the pseudonym certificate authority 740 and the link authority 750, 760 is connected to the computing engines 725, 735, 745, 755 and 765 via each group of load balancers.

[0177] In various embodiments, scalable CMS 700 includes an enrollment certificate authority 730 and a pseudonymous certificate authority 740 because the digital certificates generated by the registration authority 705 are divided into different segments, eg, enrollment digital certificates and pseudonymous digital certificates.

[0178] like Fig. 7A As shown in the three "stacked" rectangles of the pseudonymous certificate authority 740, in various embodiments, there may be multiple instances of the pseudonymous certificate authority 740 executing simultaneously. Fig. 7A and Figure 7B The other "stack" elements of are similarly represented. Pseudonym certificate authority 740 may receive multiple requests for batches of pseudonym certificates from registration authority 720 (eg, requests for a week's worth, a month's worth, or a year's worth of pseudonym certificates).

[0179] Those skilled in the art will recognize that Fig. 7A and Figure 7B The components, processes, data, operations and implementation details shown are examples presented for simplicity and clarity of explanation. Other components, processes, implementation details and variations may be used without departing from the principles of the present invention, as this example is not intended to be limiting, but many variations are possible.

[0180] Figure 8 8 is a block diagram of an example of a system 800 for implementing a scalable and secure CMS by polling scheduling requests according to an embodiment of the present invention. Figure 8 Only one set of application platforms (e.g., VMs and / or hardware platforms) 820, 830, 840, 850 and computing engines 825, 835, 845, 855 are shown. It should be noted that Figure 8 The application platforms 820, 830, 840, 850 and computing engines 825, 835, 845, 855 in the system 800 can be any set of application platforms and computing engines used to implement any registration authority 720, enrollment certificate authority 730, pseudonym certificate authority 740, and link authority 750, 760 as described above with reference to Figure 7. As with the CMS 700 in Figure 7, in the system 800, all cryptographic operations requiring HSM are performed in the computing engine, and the application platform and computing engine are scaled independently.

[0181] Continue to refer to Figure 8 Round robin refers to using the knowledge of each available server (e.g., each computing engine). Round robin requests sent in system 800 use the knowledge of available computing engines (e.g., computing engines 825, 835, 845, 855) to distribute requests and messages sent to the group of computing engines.

[0182] To clearly illustrate the order of polling scheduling requests in the system 800, the figure shows a set of enlarged computing engines 865, 875, 885, 895 that can be used for application VM 850. Figure 8 In the example of , there are "n" application platforms (eg, VMs and / or hardware platforms), and there are "m" available computing engines. A client (eg, application VM 895) that wants to make a request to a computing engine follows Figure 8 As shown, the first request from application VM 895 is a request to CE1 (computing engine 865), the second request is a request to CE2 (computing engine 875), and so on. When the last CE, CEm (computing engine 895), is reached, the client (application VM 895) restarts at CE1.

[0183] In system 800, all clients (e.g., application platforms 820, 830, 840, 850) know all servers (e.g., a set of available computing engines) with which they need to communicate. Each client performs a round-robin scheduling request to each server, which advantageously distributes the workload evenly across all servers. In certain embodiments, the load balancers 710, 711, 712, 713, 714, 715, 716, 717, 718, 719 of CMS 700 shown in FIG. 7 can send round-robin scheduling requests to the computing engines to evenly distribute the workload across the computing engines.

[0184] Fig. 9 9 is a block diagram of an example of a system 900 for implementing a scalable and secure CMS through workload-based requests according to an embodiment of the present invention. Fig. 9 Figure 7 and Figure 8 The difference that exists.

[0185] As Figure 8 For the sake of brevity and clarity, Fig. 9 Only one set of application platforms 920, 930, 940, 950 and computing engines 925, 935, 945, 955 are shown. It should be noted that Fig. 9 The application platforms (e.g., VMs and / or hardware platforms) 920, 930, 940, 950 and computing engines 925, 935, 945, 955 in the system 900 may be any set of application platforms and computing engines used to implement any registration authority 720, enrollment certificate authority 730, pseudonym certificate authority 740, and link authority 750, 760 as described above with reference to FIG7. As with the CMS 700 in FIG7, in the system 900, all cryptographic operations requiring HSM are performed in the computing engine, and the application platforms (e.g., VMs and / or hardware platforms) and computing engines are scaled independently.

[0186] Continue to refer to Fig. 9 , workload distribution techniques are enabled by adding intelligence to first query the workload of each server used. The workload distribution technique is workload based in that it uses knowledge of the workload of each available server (e.g., each compute engine). Requests sent in system 900 use knowledge of the current workload of available compute engines (e.g., compute engines 925, 935, 945, 955) to distribute requests and messages sent to the group of compute engines. In system 900, requests are sent to compute engines based on the workload reported by each compute engine.

[0187] To clearly illustrate workload-based requests in system 900, a set of enlarged compute engines 965, 975, 985, 995 are shown, reporting their respective workloads to application VM 950. Fig. 9 In the example, "m" is the number of application platforms and "n" is the number of compute engines reporting their workload. Fig. 9 In the example of , workload is reported as a percentage, where a 30% workload of computing engine 975 indicates that computing engine 975 is currently running at 30% of its total capacity. Similarly, the 80% workload reported by computing engines 965, 985, and 995 indicates that these computing engines are currently running at 80% of their total capacity. In some embodiments, the current workload reported by a given computing engine indicates the workload of the HSM embedded in the computing engine. For example, in a situation where the processing capacity of the computing engine is bound or constrained by the ability of its HSM to perform cryptographic operations, the workload percentage reported by the computing engine can reflect the current workload of the HSM. For example, if the HSM used by computing engine 975 is running at 30% of its processing capacity, computing engine 975 can report that it is running at 30% of its total capacity. In some embodiments, the workload percentage can be a weighted measure of the processing capacity, communication capacity (e.g., available bandwidth measurement of a direct communication link or wireless module), and storage / memory capacity of a server (e.g., a computing engine). In one example, processing capacity, communication capacity, and storage capacity can be given an equal one-third weight. In this example, if compute 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, then compute engine 975 will report that its workload is 30%.

[0188] In some embodiments, the environmental metrics of the computing engines can be weighted and combined with the workload metrics. For example, an overall health metric of the computing engines can be determined and reported along with the workload metrics of the computing engines. In some examples, the health metric of a given computing engine can be a function of one or more of the following: the operating temperature of the computing engine (e.g., an average temperature reading above a thermal sensor can indicate that a CPU, memory module, or disk drive is susceptible to shutdown or failure due to overheating);

[0189] Humidity level inside the compute engine enclosure; frequency of reboots or restarts (e.g., thermal shutdowns or thermal crashes); time since the most recent reboot; number of disk failures or storage failures over a recent period of time (e.g., last day, week, or month); time until a scheduled maintenance event for the compute engine (e.g., software or firmware update, replacement of a failed hardware component); an indication that the compute engine is running on backup power; or the duration since the last power outage or brownout to the compute engine.

[0190] In additional or alternative embodiments, other weights, metrics, and indicators may be used to determine the workload of a compute engine. For example, if compute engines performing cryptographic operations have historically been more limited by CPU capacity than by their communication capacity or memory capacity, then when determining the overall workload percentage for those compute engines, the weight assigned to CPU capacity may be greater than the weight assigned to other capacities.

[0191] In system 900, a client (e.g., application VM 995) that is to make a request to a computing engine operates based on the workload reported by the computing engine. Fig. 9 In the example of , the next request from application VM 995 will go to CE2 (compute engine 975) based on its relatively lower 30% workload. In other words, because compute engine 975 has the lowest workload among a group of compute engines 965, 975, 985, 995. When the next request is to be sent from application VM 995 to the compute engine, any one of CE1 (compute engine 965) or CE3 (compute engine 985) or CEm (compute engine 995) can be used because they are all currently reporting an equal 80% workload. In the case where each available compute engine reports the same or similar workload, sequential requests can be used to evenly distribute the workload across these equally loaded compute engines. In other words, if each available compute engine is reporting a substantially equal or equal workload, the above referenced sequence of requests can be used. Figure 8 Over time, as the workload changes, the client (application VM 995) will send subsequent requests to the available compute engine with the least load.

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

[0193] Fig. 10A and Fig. 10B 400 is an example architecture block diagram for implementing a scalable and secure certificate management system (CMS) according to an embodiment of the present invention. Fig. 10A and Fig. 10B Internal Figure 4A and Figure 4B The difference that exists.

[0194] like Fig. 10A As shown in the example in FIG. 1 , the architecture of CMS 1000 may include two provisioning controllers 1002, namely a primary provisioning controller and a backup provisioning controller, which are preferably implemented in separate servers. The two provisioning controllers 1002 respectively include Figure 4A and Fig. 6A The provisioning controller 120 and 602 in FIG. 6 have similar functions. In other words, for the above reference Figure 4A The purpose of the failover is to copy or otherwise include objects, data, etc. contained in the primary provisioning controller in the backup (secondary) provisioning controller.

[0195] like Fig. 10A and 10B As shown, the architecture of CMS 1000 includes a registry 1005 implemented as a REST Web service, a registry 1020 , computing engines 1025 , 1035 , 1045 , 1050 , 1060 , message queues 1010 , 1012 , 1014 , 1016 , 1018 , and a database 1070 .

[0196] Examples of CMS 1000 can be implemented in a private data center, a cloud data center, or a hybrid of a private data center and a cloud data center. Various embodiments of CMS 1000 can be used for a large number of devices to perform transaction and certificate generation processing. In various embodiments, CMS 1000 can be implemented using multiple servers, HSMs, and multiple computers or computing engines used as application platforms. In other words, Fig. 10A and 10BAs shown, the described registration authority, certificate authority, and link authority applications all run one or more computing engines capable of hosting and executing software applications.

[0197] CMS1000 is similar to the above reference Figure 4A and Figure 4B 1025, 1035, 1045, 1050, 1060 to host and run applications. In other words, the CMS 1000 architecture is an alternative to the CMS 400 architecture, in which the applications of the registration authority, the enrollment certificate authority, the pseudonym certificate authority, and the chaining authority are executed on their own dedicated compute engines 1025, 1035, 1045, 1050, and 1060. In CMS 1000, all cryptographic operations requiring HSMs are performed in the compute engines (e.g., compute engines 1025, 1035, 1045, 1050, and 1060) that also run the relevant applications. Advantageously, by executing applications and cryptographic operations on the compute engines 1025, 1035, 1045, 1050, 1060, the architecture of CMS 1000 can reduce the number of message queues required.

[0198] exist Fig. 10A and 10B In the example, the computing engine includes a registration approval authority computing engine 1025 that hosts and runs a registration approval authority application, an enrollment certificate authority computing engine 1035 that is operable to host and run an enrollment certificate authority application, a pseudonym certificate authority computing engine 1045 that is operable to host and run a pseudonym certificate authority application, a first link authority computing engine 1050 that is operable to host and run a first link authority application, and a second link authority 1060 that is operable to host and run a second link authority application.

[0199] like Fig. 10A and Fig. 10B As shown, the registration approval authority 1005 is connected to other components, and the other components are connected to each other, through a message subsystem or message queuing service, including input message queues 1010, 1012, 1014, 1016, 1018. Fig. 10A and Fig. 10B In the example implementation, the input message queue 1010,

[0200] 1012, 1014, 1016, 1018 are unidirectional queues because messages in these queues flow in one direction (eg, from the client to the server). By using a single input queue for each computing engine, each computing engine also hosts and runs their own applications, a simplified technical advantage can be provided.

[0201] The computing engines can be independently scaled as needed by communicatively connecting the computing engines to each other using the input message queues 1010, 1012, 1014, 1016, 1018. In other words, because the computing engines that serve as the application platform for the registration authority, enrollment certificate authority, pseudonym certificate authority, and link authority applications are communicatively connected via their own input message queues, these components of the CMS 1000 as well as the database 1070 are all scaled independently of each other.

[0202] Fig.11 1 is an example block diagram of a computing environment 1101 including a computing system 1100 that can be used to implement systems and methods according to embodiments of the present invention. Other components and / or arrangements may also be used. In some embodiments, the computing system 1100 may be used to at least partially implement Figure 1 to Figure 1 0, such as the provisioning controller 120, DAMS 110 and computing engine of the CMS architecture in FIG. 4 and FIG. 6 to FIG. 10, and the load balancers 710-719 in FIG. 7. In some embodiments, a series of computing systems similar to computing system 1100 may be customized with dedicated hardware and / or programmed as dedicated servers to implement Figure 1 to Figure 1 One of the components in 0, these components can communicate with each other via network 1135.

[0203] exist Fig.11 In the example shown, computing system 1100 includes several components, such as CPU 1105, memory 1110, input / output (I / O) device 1125, hardware security module (HSM) 1140, and non-volatile storage device 1120. System 1100 can be implemented in various ways. For example, an implementation as an integrated platform (such as a server, workstation, personal computer, laptop computer, etc.) can include CPU 1105, memory 1110, non-volatile storage device 1120, and I / O device 1125. In such a configuration, components 1105, 1110, 1120, and 1125 can be connected and communicated through a local data bus, and can access data repository 1130 (e.g., implemented as a separate database system) via an external I / O connection. I / O component 1125 can communicate through a direct communication link (e.g., hardwired or local WiFi connection), through a local area network such as

[0204] (LAN) or a wide area network (WAN, such as a cellular telephone network or the Internet) and / or connected to external devices by other suitable connections. System 1100 can be a stand-alone system or can be a subsystem of a larger system.

[0205] CPU 1105 may be one or more known processors or processing devices, such as Intel® processors from Santa Clara, California.TM Core produced by the company TM AMD TM Athlon produced by the company TM The memory 1110 may be one or more flash memory devices configured to store instructions and information executed or used by the CPU 1105 to perform certain functions, methods and processes associated with embodiments of the present invention. The storage device 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 and DVDs and solid-state devices intended for long-term storage.

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

[0207] In one embodiment, memory 1110 may include programs 1115 for performing the specialized functions and operations described herein for provisioning controller 120, DAMS 110, and / or distributors 118, 131. In some embodiments, memory 1110 may also include other programs or applications that implement other methods and processes that provide auxiliary functions for the present invention.

[0208] The memory 1110 may also be configured with other programs (not shown) not related to the present invention and / or an operating system (not shown) that performs several functions known in the art when executed by the CPU 1105. For example, the operating system may be Microsoft Windows TM , Unix TM , Linux TM 、Apple Computers TM Operating system or other operating systems. The selection of an operating system or even the use of an operating system is not an essential technical feature of the present invention.

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

[0210] I / O devices 1125 may include one or more input / output devices that allow system 1100 to receive and / or send data. For example, I / O devices 1125 may include one or more input devices that allow data to be input from a user, such as a keyboard, a touch screen, a mouse, etc. In addition, I / O devices 1125 may include one or more output devices that allow data to be output or presented to a user, such as a display screen, a CRT monitor, an LCD monitor, a plasma display, a printer, a speaker device, etc. I / O devices 1125 may also include one or more digital and / or analog communication input / output devices that allow computing system 1100, for example, to communicate digitally with other machines and devices. Other configurations and / or numbers of input and / or output devices may be incorporated into I / O devices 1125.

[0211] In the illustrated embodiment, 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 of these networks), which in turn can be connected to various systems and computing machines, such as servers, personal computers, laptops, client devices, etc. In general, the system 1100 can input data from and output data to external machines and devices via the network 1135.

[0212] exist Fig.11 In the illustrated example implementation, the data source 1130 is a separate database external to the system 1100, such as the database 125. In other implementations, the data source 1130 may be hosted by the system 1100. In various implementations, the data source 1130 may manage and store data used to implement the systems and methods according to the present invention. For example, the data source 1130 may manage and store data structures containing, among other things, status and log information for each device 116 provisioned by the system 110.

[0213] Data source 1130 may include one or more databases that store information and can be accessed and / or managed by system 1100. For example, database 1130 may be an Oracle TM Database, Sybase TM Databases or other relational databases. However, the systems and methods according to the present invention are not limited to a single data structure or database, or even to the use of a database or data structure.

[0214] Those skilled in the art will recognize that Fig.11 The components and implementation details of the system are examples presented for simplicity and clarity of explanation. Other components and implementation details may be used.

[0215] Although the above examples use special cases of computerized devices such as OBU, ECU and RSU, for the sake of clarity of explanation, the present invention is not limited to those special cases. Various embodiments according to the present invention can be used with a variety of computerized devices, such as medical devices (e.g., dialysis machines, infusion pumps, etc.), robots, drones, autonomous vehicles, wireless communication modules (e.g., embedded universal integrated circuit cards (eUICCs)), etc.

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

[0217] Similarly, the methods described herein may be at least partially implemented by a processor, where one or more specific processors are examples of hardware. For example, at least some operations of a method may be performed by one or more processors or processor-implemented modules. One or more processors may also be operable to perform tasks in a "cloud computing" environment.

[0218] The execution of related operations in the environment may be supported or may be operated as SaaS. For example, at least some operations may be performed by a group of computers (as an example of a machine including a processor), which may be accessed via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., APIs).

[0219] The execution of certain operations may be distributed to processors that reside not only within a single machine but are deployed on multiple machines. In some exemplary embodiments, the processor or processor-implemented modules may be located in a single geographic location (e.g., within an office environment, within a manufacturing environment, or within a server farm). In other exemplary embodiments, the processor or processor-implemented modules may be distributed to multiple geographic locations.

[0220] Other embodiments of the present invention will be apparent to those skilled in the art from consideration of the specification and practice of the inventive content of the present disclosure. The specification and examples are to be considered as exemplary only, with the true scope of the present invention being specified by the appended claims.

Claims

1. A scalable certificate management system for securely provisioning certificates, wherein: The scalable certificate management system comprises: one or more application platforms running a registration authority application, communicatively coupled to one or more computing engines that perform cryptographic computations requested by the registration authority application; one or more application platforms running an enrollment certificate authority application, communicatively connected to one or more computing engines that perform cryptographic computations requested by the enrollment certificate authority application, wherein the enrollment certificate authority application is operable to generate an enrollment certificate and conditionally transmit the enrollment certificate to the registration approval authority application; one or more application platforms running a pseudonymous certificate authority application, communicatively coupled to one or more computing engines that perform cryptographic computations requested by the pseudonymous certificate authority application, wherein the pseudonymous certificate authority application is operable to generate a pseudonymous certificate and conditionally transmit the pseudonymous certificate to the registration approval authority application; one or more application platforms running the first link authority authority application, communicatively connected to one or more computation engines that perform cryptographic computations requested by the first link authority authority application; one or more application platforms running a second link authority application, communicatively connected to one or more computation engines that perform cryptographic computations requested by the second link authority application, wherein the first link authority application and the second link authority application are operable to generate link values ​​and conditionally transmit link values ​​to the registration approval authority application; and one or more load balancers communicatively connected to the one or more computing engines, the one or more load balancers performing operations including distributing at least one request to the one or more computing engines based on a health metric of the one or more computing engines; and wherein the scalable certificate management system distributes one or more certificate payloads to each of a plurality of computerized devices, the one or more certificate payloads indicating a number of pseudonymous certificates to be stored within each computerized device over a period of time, wherein the one or more certificate payloads are distributable such that each computerized device can store a different number of pseudonymous certificates than other computerized devices over the period of time.

2. The certificate management system according to claim 1, wherein: The normal condition metric includes one or more of the following: the operating temperature of the one or more computing engines, the humidity level inside the housing of the one or more computing engines, the CPU capacity, the storage capacity, the frequency of restarts or reboots of the one or more computing engines, the time since the most recent restart of the one or more computing engines, the number of disk failures or memory failures of the one or more computing engines over a period of time, the time until a scheduled maintenance event for the one or more computing engines, an indication that the one or more computing engines are running on a backup power source, or the duration since the last power outage or brownout of the one or more computing engines.

3. The certificate management system according to claim 1, wherein: The certificate management system further includes one or more databases, which are operably connected to the one or more application platforms running the registration approval authority application, the one or more application platforms running the enrollment certificate authority application, the one or more application platforms running the pseudonym certificate authority application, the one or more application platforms running the first link authority application, and the one or more application platforms running the second link authority application.

4. The certificate management system according to claim 2, wherein: Each of the registration authority application, the enrollment certificate authority application, the pseudonym certificate authority application, the first link authority application, the second link authority application, and the one or more databases are operable to scale independently of one another.

5. The certificate management system according to claim 1, wherein: the enrollment certificate authority application being operable to generate an enrollment certificate in response to receiving a request for an enrollment certificate from the registration approval authority application; the pseudonymous certificate authority application being operable to generate a pseudonymous certificate in response to receiving a request for a pseudonymous certificate from the registration approval authority application; as well as The first link authority application and the second link authority application are operable to generate a link value in response to receiving a request for a link value from the registration approval authority application.

6. The certificate management system according to claim 1, wherein: Each of the registration authority application, the enrollment certificate authority application, the pseudonym certificate authority application, the first link authority application, and the second link authority application are communicatively coupled to one another via a message queuing service including a plurality of message queues.

7. The certificate management system according to claim 1, wherein: The one or more application platforms running the enrolling certificate authority application are one or more virtual machines communicatively connected via a first plurality of message queues to the one or more computing engines that perform cryptographic computations requested by the enrolling certificate authority application; The one or more application platforms running the first link authority application are one or more virtual machines communicatively connected to the one or more computing engines performing cryptographic computations requested by the first link authority application via a second plurality of message queues; as well as The one or more application platforms running the second link authority application are one or more virtual machines communicatively connected to the one or more computing engines performing cryptographic computations requested by the second link authority application via a third plurality of message queues.

8. The certificate management system according to claim 7, wherein: The first plurality of message queues include: a first message queue for queuing messages to be delivered to one or more virtual machines running an enrollment certificate authority application; and a second message queue for queuing messages to be delivered to the one or more computing engines performing cryptographic computations requested by the enrollment certificate authority application; The second plurality of message queues comprises: a third message queue, for queuing messages to be delivered to one or more virtual machines running the first link authority application; and a fourth message queue for queuing messages to be delivered to the one or more computing engines performing the cryptographic computations requested by the first link authority application; and The third plurality of message queues comprises: a fifth message queue, for queuing messages to be delivered to one or more virtual machines running a second link authority application; and A sixth message queue is used to queue messages to be delivered to the one or more computing engines that perform the encryption computing requested by the second link authority application.

9. The certificate management system according to claim 7, wherein: The first plurality of message queues include: a first bidirectional message queue for queuing messages to be delivered to and sent from the one or more virtual machines running the enrollment certificate authority application; and a second bidirectional message queue for queuing messages to be delivered to and sent from the one or more computing engines performing cryptographic computations requested by the enrollment certificate authority application; The second plurality of message queues comprises: a third bidirectional message queue for queuing messages to be delivered to and sent from the one or more virtual machines running the first link authority application; and a fourth bidirectional message queue for queuing messages to be delivered to and sent from the one or more computing engines performing the cryptographic computations requested by the first link authority application; and The third plurality of message queues comprises: a fifth bidirectional message queue for queuing messages to be delivered to and sent from the one or more virtual machines running the second link authority application; and A sixth bidirectional message queue is used to queue messages to be delivered to and sent from the one or more computing engines that perform the encryption computing requested by the second link authority application.

10. The certificate management system according to claim 1, wherein: The one or more application platforms running the enrolling certificate authority application are communicatively connected to the one or more computing engines performing cryptographic computations requested by the enrolling certificate authority application through a first load balancer of the one or more load balancers; The one or more application platforms running the first link authority authority application are communicatively connected to the one or more computing engines performing cryptographic computations requested by the first link authority authority application via a second load balancer of the one or more load balancers; as well as The one or more application platforms running the second link authority authority application are communicatively connected to one or more computing engines that perform cryptographic computations requested by the second link authority authority application through a third load balancer of the one or more load balancers.

11. The certificate management system according to claim 10, wherein: The first load balancer, the second load balancer, and the third load balancer each include one or more of a load balancer virtual machine and a load balancer server; and The load balancer virtual machine and the load balancer server are both configured to distribute workload across multiple application platforms and multiple computing engines.

12. The certificate management system according to claim 11, wherein: The load balancer virtual machine and the load balancer server are both configured to distribute workloads across multiple application platforms and multiple computing engines using a round-robin scheduling technique.

13. The certificate management system according to claim 11, wherein: The load balancer virtual machine and the load balancer server are each configured to distribute workload across multiple application platforms and multiple computing engines based on respective workloads reported by each of the multiple application platforms and each of the multiple computing engines.

14. The certificate management system according to claim 1, wherein: The credential management system is further operable to transmit information regarding credential activity associated with the computerized device to the provisioning controller for storage in a log.

15. The certificate management system of claim 1, further comprising a provisioning controller operable to authenticate the computerized device prior to transmitting a request to enroll a certificate to the registration authority application.

16. The certificate management system according to claim 1, wherein: An enrollment certificate is a public key certificate that identifies the holder of the public key certificate as an authorized participant in an ecosystem including a plurality of computerized devices, and wherein each authorized participant in the ecosystem is capable of receiving one or more pseudonymous certificates that enable communication with the plurality of computerized devices.

17. The certificate management system according to claim 1, wherein: The certificate payload may be distributed by subscriber.

18. The certificate management system according to claim 1, wherein: The scalable certificate management system allocates a pseudonym certificate usage for each subscriber, indicating a number of pseudonym certificates available for use over a period of time.

19. A method for securely providing a certificate, wherein: The method comprises: performing cryptographic computations requested by a registration approval authority application, the registration approval authority application being communicatively coupled to one or more computation engines that perform the cryptographic computations requested by the registration approval authority application; performing cryptographic computations requested by an enrollment certificate authority application, the enrollment certificate authority application being communicatively coupled to one or more computation engines that perform cryptographic computations requested by the enrollment certificate authority application, wherein the enrollment certificate authority application generates an enrollment certificate and conditionally transmits the enrollment certificate to the registration approval authority application; performing cryptographic computations requested by a pseudonymous certificate authority application, the pseudonymous certificate authority application being communicatively coupled to one or more computation engines that perform cryptographic computations requested by the pseudonymous certificate authority application, wherein the pseudonymous certificate authority application generates a pseudonymous certificate and conditionally transmits the pseudonymous certificate to the registration approval authority application; performing cryptographic computations requested by a first link authority application, the first link authority application being communicatively coupled to one or more computation engines that perform cryptographic computations requested by the first link authority application; performing cryptographic computations requested by a second link authority application, the second link authority application being communicatively coupled to one or more computation engines that perform cryptographic computations requested by the second link authority application, wherein the first link authority application and the second link authority application generate link values ​​and conditionally transmit the link values ​​to the registration approval authority application; and distributing one or more certificate payloads to each of a plurality of computerized devices, the one or more certificate payloads indicating a number of pseudonymous certificates to be stored within each computerized device over a period of time, wherein the certificate payloads are distributable such that each computerized device may store a different number of pseudonymous certificates than the other computerized devices over the period of time, and Wherein one or more load balancers communicatively connected to one or more computing engines perform operations including distributing at least one request to the one or more computing engines based on health metrics of the one or more computing engines.

20. The method according to claim 19, wherein: The normal condition metric includes one or more of the following: the operating temperature of the one or more computing engines, the humidity level inside the housing of the one or more computing engines, the CPU capacity, the storage capacity, the frequency of restarts or reboots of the one or more computing engines, the time since the most recent restart of the one or more computing engines, the number of disk failures or memory failures of the one or more computing engines over a period of time, the time until a scheduled maintenance event for the one or more computing engines, an indication that the one or more computing engines are running on a backup power source, or the duration since the last power outage or brownout of the one or more computing engines.

21. The method according to claim 19, wherein: The method further comprises: generating an enrollment certificate in response to receiving a request for an enrollment certificate from the registration authority application; generating the pseudonym certificate in response to receiving a request for a pseudonym certificate from the registration authority application; and The link value is generated in response to receiving a request for a link value from the registration authority application.

22. The method of claim 19, further comprising transmitting information about credential activity associated with the computerized device to a provisioning controller for storage in a log.

23. The method of claim 19, further comprising authenticating the computerized device prior to transmitting the request for an enrollment certificate to the registration authority application.

24. The method according to claim 19, wherein: An enrollment certificate is a public key certificate that identifies the holder of the public key certificate as an authorized participant in an ecosystem including a plurality of computerized devices, and wherein each authorized participant in the ecosystem is capable of receiving one or more pseudonymous certificates that enable communication with the plurality of computerized devices.

25. The method of claim 19, wherein: The certificate payload may be distributed by subscriber.

26. The method of claim 19, further comprising allocating a pseudonym certificate usage for each subscriber indicating a number of pseudonym certificates available over a period of time.

27. A non-transitory computer-readable medium for securely providing credentials, the non-transitory computer-readable medium comprising a plurality of instructions that, in response to being executed by a processor, cause the processor to perform operations comprising: Perform cryptographic calculations requested by the Registration Authority Application; performing cryptographic computations requested by an enrollment certificate authority application, wherein the enrollment certificate authority application generates an enrollment certificate and conditionally transmits the enrollment certificate to the registration approval authority application; performing cryptographic computations requested by a pseudonymous certificate authority application, wherein the pseudonymous certificate authority application generates a pseudonymous certificate and conditionally transmits the pseudonymous certificate to the registration approval authority application; performing a cryptographic calculation requested by the first link authority application; performing a cryptographic calculation requested by a second link authority application, said first link authority application and said second link authority application generating a link value and conditionally transmitting the link value to said registration approval authority application; and allocating one or more certificate payloads to each of a plurality of computerized devices, the one or more certificate payloads indicating a number of pseudonymous certificates to be stored within each computerized device over a period of time, wherein the one or more certificate payloads are allocable such that each computerized device may store a different number of pseudonymous certificates than the other computerized devices over the period of time, and Wherein one or more load balancers communicatively connected to one or more computing engines perform operations including distributing at least one request to the one or more computing engines based on health metrics of the one or more computing engines.

28. The non-transitory computer readable medium of claim 27, wherein: The normal condition metric includes one or more of the following: the operating temperature of the one or more computing engines, the humidity level inside the housing of the one or more computing engines, the CPU capacity, the storage capacity, the frequency of restarts or reboots of the one or more computing engines, the time since the most recent restart of the one or more computing engines, the number of disk failures or memory failures of the one or more computing engines over a period of time, the time until a scheduled maintenance event for the one or more computing engines, an indication that the one or more computing engines are running on a backup power source, or the duration since the last power outage or brownout of the one or more computing engines.

29. The non-transitory computer readable medium of claim 27, wherein: The operations also include: generating an enrollment certificate in response to receiving a request for an enrollment certificate from the registration authority application; generating the pseudonym certificate in response to receiving a request for a pseudonym certificate from the registration authority application; and The link value is generated in response to receiving a request for a link value from the registration authority application.

30. The non-transitory computer readable medium of claim 27, wherein the operations further comprise: Information about certificate activity associated with the computerized device is transmitted to a provisioning controller for storage in a log.

31. The non-transitory computer readable medium of claim 27, wherein the operations further comprise: The computerized device is authenticated prior to transmitting a request for an enrollment certificate to the registration authority application.

32. The non-transitory computer readable medium of claim 27, wherein the credential payload is allocable by subscriber.

33. The non-transitory computer readable medium of claim 27, wherein: The processor is caused to perform operations further comprising allocating pseudonym certificate usage for each subscriber, indicating a number of pseudonym certificates available for use over a period of time.

Images