Scalable certificate management systems, methods, and non-transitory computer-readable media

Abstract

The present invention relates to a scalable certificate management system, method, and non-transitory computer readable medium for securely providing certificates. The system can include one or more application platforms running a registration authority that are communicatively connected to one or more computing engines that perform cryptographic computations requested by the registration authority, one or more application platforms running an enrollment certificate authority that are communicatively connected to one or more computing engines that perform cryptographic computations requested by the enrollment certificate authority, one or more application platforms running a pseudonym certificate authority that are communicatively connected to one or more computing engines that perform cryptographic computations requested by the pseudonym certificate authority, and one or more application platforms running a first and second linking rights authority that are communicatively connected to one or more computing engines that perform cryptographic computations requested by the linking rights authority.

Description

[0001] This application is a divisional application of application number 201980045450.3, filed on July 1, 2019, entitled "Scalable Certificate Management System Architecture". The parent application is a Chinese national phase application filed on July 1, 2019, with international application number PCT / US2019 / 040064 filed with the International Patent Office, claiming priority to US Patent Application No. 16 / 029,559 filed on July 7, 2018. The above application is incorporated herein by reference in its entirety. The parent application relates to a continuation application of U.S. Application No. 15 / 812,510, filed November 14, 2017 (which claims the benefit of U.S. Provisional Application No. 62 / 421,878, filed November 14, 2016); U.S. Provisional Application No. 62 / 421,852, filed November 14, 2016; and U.S. Provisional Application No. 62 / 487,909, filed April 20, 2017, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This invention relates to systems, apparatus, and methods for computerized provisioning devices. Background Technology

[0003] As computers become increasingly miniaturized and commercialized, manufacturers are now producing a wider variety of devices that contain one or more embedded computers or processors. The computers within these computerized devices can control the operation of the device, collect, store, and share data, communicate with other computers and other computerized devices, and update their 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 a network of digital networks that enables these devices to connect and exchange data, including the Internet, cellular networks, and other wireless networks. Typically, each "thing"...

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

[0006] In the context of the Internet of Things (IoT), "things" can refer to a variety of computerized devices, such as consumer appliances, commercial equipment used in enterprise and corporate environments, manufacturing machinery, agricultural facilities, energy-consuming devices in homes and buildings (switches, power outlets, 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 transport machinery (e.g., cars, trucks, airplanes, trains, ships, motorcycles, scooters, etc.) contain several embedded processors or embedded computers in their subsystems, which are controlled by computers in at least some respects. 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 (often many) embedded processor or embedded computer systems, which are controlled by computers in at least some respects. These computer-controlled elements in the transportation network typically communicate with each other, exchanging various types of information, and may react, respond to, and modify their operations, or operate safely, correctly, efficiently, and reliably based on information received / sent from / to other vehicles via vehicle-to-vehicle (V2V; also known as car-to-car) communication and / or information received / sent from / to infrastructure elements via vehicle-to-infrastructure (V2I; also known as car-to-infrastructure) communication.

[0008] Computers in computerized devices operate based on their software and / or firmware and data. To ensure secure and correct operation, computerized devices must be properly initialized and updated as required by the manufacturer using 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") so that the Internet of Things (IoT) consists only of devices executing authorized, known, and well-functioning software and data. However, problems arise when unauthorized individuals or organizations (such as hackers) replace or alter the software in computerized devices. Problems also arise when older versions of software, untested software, unapproved software, and / or software with known vulnerabilities are installed on computerized devices.

[0009] In view of this, it is desirable to provide improved systems, methods and techniques for securely storing digital assets in computerized devices to prevent the computerized devices from being operated using faulty, improperly functioning, untested, maliciously tampered or otherwise undesirable software and data. Summary of the Invention

[0010] This disclosure relates to systems, methods, and apparatuses for securely generating and providing certain types of digital assets, such as security credentials and digital certificates. In various embodiments, the systems, methods, and apparatuses 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 registration certificates and pseudonym certificates in response to requests for such certificates.

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

[0012] In some implementations, a scalable CMS for providing certificate security to a provisioning controller includes: one or more application platforms running a registry application, the application platforms being communicatively connected to one or more computing engines that perform cryptographic computations required by the registry application; one or more application platforms running a registry certificate authority application, the application platforms being communicatively connected to one or more computing engines that perform cryptographic computations required by the registry certificate authority application, the registry certificate authority application being operable to generate a registry certificate and conditionally transmit the registry certificate to the registry application; one or more application platforms running a pseudonym certificate authority application, the application platforms being communicatively connected to one or more computing engines that perform cryptographic computations 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 registry application; one or more application platforms running a first link authority application, the application platforms being communicatively connected to one or more computing engines that perform cryptographic computations required by the first link authority application; and one or more application platforms running a second link authority application, the application platforms being communicatively connected to one or more computing engines that perform cryptographic computations 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 registry application.

[0013] In other embodiments, the CMS may further include one or more databases operatively 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 pseudonymous certificate authority applications, one or more application platforms running first link authority applications, and one or more application platforms running second link authority applications.

[0014] In some other implementations, each of the registration approval authority application, registration certificate issuing authority application, pseudonym certificate issuing authority application, first link authority application, second link authority application, and one or more databases is operable to scale independently of each other.

[0015] In some other embodiments, the registration certificate authority application is operable to generate a registration certificate in response to receiving a request for a registration certificate from the registration authority application; the registration certificate authority application is operable to generate a pseudonym certificate in response to receiving a request for a pseudonym certificate from the registration 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 registration authority application.

[0016] In some implementations, each of the registration approval authority application, the registration certificate authority application, the pseudonym certificate authority application, the first link authority application, and the second link authority application communicates with each other through a message queuing service that includes multiple message queues.

[0017] In some implementations, one or more application platforms running a Registered Certificate Authority (RCA) application are connected via a first plurality of message queues to one or more virtual machines of a computing engine that performs cryptographic computations required by the Registered Certificate Authority (RCA) application; one or more application platforms running a first Linked Authority (LAA) application are connected via a second plurality of message queues to one or more virtual machines of a computing engine that performs cryptographic computations required by the first Linked Authority (LAA) application; and one or more application platforms running a second Linked Authority (LAA) application are connected via a third plurality of message queues to one or more virtual machines of a computing engine that performs cryptographic computations required by the second Linked Authority (LAA) 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 Registered Certification Authority (RCA) application; and a second message queue for queuing messages to be delivered to one or more computing engines performing cryptographic computations required by the RCA 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 (LAA) application; and a fourth message queue for queuing messages to be delivered to one or more computing engines performing cryptographic computations required by the first LAA 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 LAA application; and a sixth message queue for queuing messages to be delivered to one or more computing engines performing cryptographic computations required by the second LAA 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 Registered Certification Authority (RCA) application; and a second bidirectional message queue for queuing messages to be delivered to and sent from one or more computing engines performing cryptographic computations required by the RCA 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 (LAA) application; and a fourth bidirectional message queue for queuing messages to be delivered to and sent from one or more computing engines performing cryptographic computations required by the first LAA 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 LAA application; and a sixth bidirectional message queue for queuing messages to be delivered to and sent from one or more computing engines performing cryptographic computations required by the second LAA application.

[0020] In other embodiments of the CMS, one or more application platforms running a Registered Certificate Authority application communicate with one or more computing engines that perform cryptographic calculations required by the Registered Certificate Authority application via a first load balancer; one or more application platforms running a First Link Authority application communicate with one or more computing engines that perform cryptographic calculations required by the First Link Authority application via a second load balancer; and one or more application platforms running a Second Link Authority application communicate with one or more computing engines that perform cryptographic calculations required by the Second Link Authority application via a third load balancer.

[0021] In some embodiments of the CMS that include 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 both the load balancer virtual machine and the load balancer server are configured to distribute workloads across multiple application platforms and multiple computing engines.

[0022] In other implementations with load balancer virtual machines and load balancer servers, both the load balancer virtual machines and load balancer servers are configured to distribute workloads across multiple application platforms and multiple computing engines using round-robin scheduling techniques.

[0023] In some other implementations that include load balancer virtual machines and load balancer servers, both load balancer virtual machines and load balancer servers are configured to distribute workloads across multiple application platforms and multiple computing engines based on the respective workloads reported by each of the multiple application platforms and each of the multiple computing engines.

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

[0025] In some implementations where the provisioning controller is operable to create and retain logs, the provisioning controller is further operable to transmit information about certificate activities related to computerized devices to the provisioning controller for storage in the logs.

[0026] In some embodiments where the provisioning controller is operable to transmit a request for a registration certificate to a registration authority, the provisioning controller is further operable to authenticate the computerized device before transmitting the request for a registration certificate to the registration authority.

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

[0028] In some embodiments, a system for provisioning one or more computerized devices includes: a distributor communicatively connected to the computerized device and operable to receive digital assets and load the digital assets into the computerized device; a digital asset management system connected to the distributor via a first secure communication channel and operable to generate digital assets and conditionally transfer the digital assets to the distributor; and a provisioning controller connected to the distributor via a second secure communication channel and connected to the digital asset management system via a third secure communication channel, operable to instruct the digital asset management system to transfer the digital assets to the distributor. Because the digital assets are not present, the computerized device may not operate or may only partially operate before the digital assets are loaded into the computerized device. The digital assets may be at least one of digital certificates, encryption keys, and executable software. In some embodiments, the system may interact with 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 a computerized device after the distributor is disconnected. The second distributor is operable to receive and load the second digital asset into the computerized device, and the provisioning controller is further operable to instruct 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 can operate at full functionality.

[0030] In various embodiments, the digital asset management system may further include: one or more application platforms running registration and approval authority applications, the application platforms being communicatively connected to one or more computing engines that perform cryptographic calculations required by the registration and approval authority applications; one or more application platforms running registration and certification authority applications, the application platforms being communicatively connected to one or more computing engines that perform cryptographic calculations required by the registration and certification authority applications; one or more application platforms running pseudonymous certificate authority applications, the application platforms being communicatively connected to one or more computing engines that perform cryptographic calculations required by the pseudonymous certificate authority applications; one or more application platforms running first linking authority applications, the application platforms being communicatively connected to one or more computing engines that perform cryptographic calculations required by the first linking authority applications; and one or more application platforms running second linking authority applications, the application platforms being communicatively connected to one or more computing engines that perform cryptographic calculations required by the second linking authority applications.

[0031] In other embodiments, the digital asset management system may further include one or more databases operatively 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 pseudonymous certificate authority applications, one or more application platforms running first linking authority applications, and one or more application platforms running second linking authority applications.

[0032] In some other embodiments, the system may further include: a portal operatively connected to a provisioning controller and authenticating a manufacturer of the computerized device and enabling the manufacturer to manage provisioning of the computerized device; and / or a portal operatively connected to a provisioning controller and authenticating an installer of the computerized device and enabling the installer to manage provisioning of the computerized device; and / or a portal operatively connected to a provisioning controller and authenticating a supervisor of the computerized device and enabling the supervisor to supervise provisioning of the computerized device.

[0033] In some other embodiments, the provisioning controller is further operable to transfer digital assets (e.g., executable software images) to a distributor for loading into a computerized device. In still other embodiments, the provisioning controller is further operable to create and maintain a log associated with the digital device and storing information about provisioning activities of the digital device, and the distributor is further operable to transfer information about provisioning activities associated with the digital device to the provisioning controller for storage in the log.

[0034] In some other embodiments, the provisioning controller is further operable to authenticate the digital device before directing the digital asset management system to transfer the digital asset. Attached Figure Description

[0035] The accompanying drawings, which are included in and form part of this specification, illustrate embodiments of the invention and explain the principles of the invention in conjunction with the description of the invention. In the drawings:

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

[0037] Figure 2 This is a swimlane diagram illustrating a process example for a computerized device for security provision according to an embodiment of the present invention;

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

[0039] Figure 4AThis is a first part of a block diagram of a system example for implementing a scalable and secure digital asset management system via message queues according to an embodiment of the present invention;

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

[0041] Figure 5A This is a first-part swimlane 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 This is a second part of the swimlane diagram illustrating an example of a process for securely providing credentials such as certificates according to an embodiment of the present invention;

[0043] Figure 6A This is a first part of a block diagram of a system example for implementing a scalable and secure certificate management system via a bidirectional message queue according to an embodiment of the present invention;

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

[0045] Figure 7A This is a first part of a block diagram of a system example for implementing a scalable and secure certificate management system via a load balancer according to an embodiment of the present invention;

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

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

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

[0049] Figure 10A This is a first part of a block diagram of a system example for implementing a scalable and secure digital asset management system via message queues according to an embodiment of the present invention;

[0050] Figure 10B This is a second part of a block diagram of a system example for implementing a scalable and secure certificate management system via message queues according to an embodiment of the present invention; and

[0051] Figure 11 This is a block diagram of an example computing system that can be used to host systems and methods according to embodiments of the present invention. Detailed Implementation

[0052] Various embodiments of the present invention will now be described in detail with reference to the accompanying drawings. For the sake of brevity, the same reference numerals are used in the drawings to refer to the same or similar parts.

[0053] 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 can include various encryption keys, unique identifiers, digital certificates, and software. In most cases, these digital assets and the manufacturing facility are located in different geographical locations, typically interconnected via insecure internet communications. Therefore, it is desirable to create a secure end-to-end channel from the source of these digital assets to the device, preventing malicious parties or unauthorized access to or modification of these digital assets.

[0054] A drawback of traditional network security protocols used for end-to-end protection (such as TLS / SSL) is that they require pre-shared keys or some confidential security material to exist beforehand between the communicating parties. This creates a recurring technical problem: in order to provision digital assets, some initial confidential material must exist in advance. This problem includes how to protect the initial confidential material. This problem is particularly acute for computerized devices, as a single version of initial software is typically loaded onto computerized devices during manufacturing to streamline logistics. If this initial software must contain initial security material, this requires a global secret. Consequently, compromising the initial security material will result in the corruption of all digital assets provisioned on all devices, as they all share the same global secret. The systems, methods, and apparatus according to this disclosure address 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 can also include a set of actions taken to properly install the device in its operating environment to prepare it for operation. These actions include loading appropriate digital assets (such as operating systems, 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 (as needed), 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 can also include properly installing the equipment into its operating environment and testing the equipment to verify its proper functioning. Equipment may be built by one manufacturer and then installed into a larger system or device by another manufacturer; for example, an onboard unit (OBU) built by a component manufacturer may be installed in a car manufactured by an automaker. Therefore, the ability to safely position only known good equipment becomes complicated. Incorrectly installed equipment may not function properly.

[0057] Various embodiments of the present invention provide secure provisioning for computerized devices, including IoT devices. These embodiments are designed to prevent or prohibit malicious, negligent, or erroneous tampering, alteration, updating, or distribution of digital assets used by computerized devices, and to prevent or prohibit erroneous installation of computerized devices and their software.

[0058] According to various embodiments of the present invention, audit logs, records, reports, etc., can also be generated during the security provisioning process for analyzing and resolving problems discovered later.

[0059] According to various embodiments of the present invention, a secure provisioning and management platform can also be provided as a service to equipment and system manufacturers.

[0060] Figure 1 This is a block diagram illustrating an example of a system 100 for a computerized device for secure provisioning according to an embodiment of the present invention. Figure 1 As illustrated in the example, system 100 includes a provisioning controller 120. The provisioning controller 120 may be implemented as a server computer (e.g., having at least one processor and associated memory) 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 potential access by attackers. In various implementations, the provisioning controller 120 operates as follows: authenticating users of system 100 and securely communicating with them; securely communicating with and managing one or more distributors 108, 131; securely communicating with and instructing the operation of a digital asset management system (DAMS) 110; creating and storing provisioning records; creating, storing, and distributing provisioning records; creating, storing, and distributing audit logs; creating and distributing certificates to cryptographically bind DAMS 110 to elements of distributors 108, 131; revoking the trust of users and managed devices as needed; and creating and distributing secure encrypted backups of critical keys and data for off-site storage, thereby enabling business continuity and disaster recovery.

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

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

[0063] Similarly, the provisioning controller 120 also communicatively connects to the installer's user portal 116, which may be implemented, for example, as a server or an interface to the provisioning controller 120. In various implementations, the installer's employee 132 can use the installer's user portal 116 to interface with the provisioning controller 120 (and thus with DAMS 110) and manage their equipment installation and provisioning activities. The provisioning controller 120 can authenticate the employee 132 before allowing them access and assign roles to them before granting them access to the secure provisioning system 100 and performing authorization functions on the system.

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

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

[0066] The DAMS110 adds new features and improves upon the components and functions described in the paper "A Secure Credential Management System for V2V Communications" presented by William Whyte et al. at the 2013 IEEE Conference on Vehicle Networking (VNC) in December 2013. In various implementations, the DAMS110 includes multi-stage programming and flexible management (e.g., allowing the inclusion of a supervisor 140). Various implementations of the DAMS110 also enable the ability to provide different levels of provisioning to different subscribers using a single DAMS110. Various implementations of the DAMS110 also enable the ability to assign different digital certificate usages to subscribers over a period of time (e.g., weekly) and different certificate payloads (e.g., weekly, rather than three years in a conventional system). Various implementations of the DAMS110 can also provide subscriber-specific URLs so that computerized devices 106 of a particular manufacturer (e.g., vehicles of an OEM) can remain within the manufacturer's scope (e.g., their URLs display their names).

[0067] As shown, the provisioning controller 120 is also communicatively connected to distributors 108 and 131. In various embodiments, distributors 108 and 131 may be implemented as stand-alone security devices installed at a corporate location (as shown), or as web or cloud services, etc. In various embodiments, distributors 108 and 131 are implemented as trusted endpoint devices, which preferably securely transmit and receive digital assets and other information to and from DAMS 110 and provisioning controller 120 via a dedicated non-Internet communication channel. As shown, distributors 108 and 131 are also directly or indirectly connected to devices 106a and 106b to download digital assets to and receive data from devices 106a and 106b. In various embodiments, distributors 108 and 131 can be implemented as an electrical enclosure 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 untrusted environments while still providing trusted and reliable operation. The distributor has a secure communication channel between itself and the secure provisioning controller 120 and DAMS 110. This channel is used to control the distributor and to send and retrieve provisioning-related data and log information. The distributor may also have a secure communication channel to the tester 107 for programming or provisioning device 106. This channel prevents provisioning 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, ensuring that provisioning data is not corrupted or modified by third parties (including 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, as well as other information, from the provisioning controller 120 and / or DAMS 110 for programming into device 106. It can return its own log data, and it can return data from the tester 107 to the provisioning controller 120 and / or DAMS 110.

[0068] As shown with reference to device manufacturer 105, distributor 108 can communicatively connect to tester 107 (e.g., computerized manufacturing equipment, product testing equipment, etc.), which in turn connects to device 106a manufactured by manufacturer 105, such as an OBU device. Manufacturer 105 may include or may be a factory that manufactures and / or supplies computerized device 106a to the market. As one of many feasible examples, computerized device 106a may be an embedded universal integrated circuit card (eUICC) for telecommunications cellular modems, incorporated as part of an onboard unit (OBU), which is subsequently installed in a vehicle to enable communication between the vehicle and traffic infrastructure equipment. It may also be a V2V safety microprocessor installed in the OBU to enable communication with other vehicles and roadside units (RSUs). These newly manufactured devices 106a must be properly provisioned with digital assets, such as digital certificates from DAMS 110, for proper operation. Employees 109 of manufacturer 105 can interact with provisioning controller 120 using user portal 115 and manage product provisioning activities through DAMS 110.

[0069] As shown with reference to Installer 130, Distributor 131 may alternatively communicate directly with Device 106b when or after Device 106b is installed in its operating environment. 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 vehicle. During installation, digital assets, such as additional digital certificates from DAMS 110, must be properly provisioned for the computerized device 106b for proper operation. Employee 132 of Installer 130 may interact with Provisioning Controller 120 using Installer's User Portal 116 and manage product provisioning activities through DAMS 110.

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

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

[0072] After initial provisioning of device 106, manufacturer 105 transports device 106a to installer 130, who installs device 106b. In various embodiments, device 106a is not operational before initial provisioning; and after initial provisioning by manufacturer 105, device 106a is partially functional, but not fully functional. In such embodiments, initial provisioning enables the device to operate only to the extent necessary for installation and further final provisioning, which is essential for its full operation.

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

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

[0075] (PC)) and / or other information required to operatively prepare device 106b so that device 106b can function correctly when installed in its operating environment.

[0076] In various implementations, the supervisor 140 interacts with the provisioning controller 120 via the supervisor portal 117 to identify, verify, and manage installers 130 and / or manufacturers 105, preventing unauthorized installers (e.g., hackers) from obtaining tangible 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 associated with the system 100, enabling unique recording of their actions. In various implementations, 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 fully provisioned devices 106b installed, etc.

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

[0078] The described system 100 and its functional implementation ensure that only devices 106 manufactured by manufacturer 105 and correctly installed and tested by authorized installer 130 are adequately provisioned with the digital assets required to operate the devices 106. Provisioning controller 120 generates extensive logs and reports on who took what actions at each stage of the provisioning process, thus providing critical auditing 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 merely examples presented for clarity and explanation. Other components, processes, implementation details, and variations may be used without departing from the principles of the invention, as these examples are not intended to be limiting and many variations are possible. For example, although Figure 1 The illustration shows only one manufacturer 105, one installer 130, and one supervisor 140, but other implementations may have any number of each of these entities. For another example, although DAMS 110 and provisioning controller 120 are shown as separate devices, other implementations may combine their functionality into a single device (e.g., a single server). As yet another example, this also applies to portals 115-117. For yet another example, 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 an embodiment, the AMA may be communicatively connected to provisioning controller 120 and / or distributors 108, 131 and / or DAMS 110. In various embodiments, the AMA may include a user-friendly GUI and functionality that allows production coordinators to easily and efficiently manage the configuration and construction of products (e.g., device 106) and allows asset owners to easily and efficiently manage the inventory of digital assets.

[0081] Figure 2 This is a swimlane 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 200 or operations shown can be executed by executing code on a general-purpose computing system (which may include one or more processors or one or more computing subsystems) by a system consisting of pure hardware or both. Figure 2 As shown above, the entities involved in process 200 include the manufacturer 105 of the computerized device 106, the dispenser 108 located at the manufacturer 105, the provisioning controller 120, and the DAMS 110. In various embodiments, these entities may be as described in reference Figure 1 And entities that are present throughout this disclosure and can communicate with each other.

[0082] like Figure 2As illustrated in the example, process 200 begins at 205, where manufacturer 105 (e.g., employee 109) requests a digital asset provisioning service from provisioning controller 130. The digital asset will be provisioned to device 106a (e.g., for its use), and the request identifies device 106a as the destination of the digital asset. This request could be, for example, manufacturer 105 requesting provisioning services for a new product 106A, or issuing a new provisioning service request for an existing product 106B. In various implementations, this operation may involve, for example, an authorized user logged into provisioning controller 130 via user portal 115. In some cases, the requested digital asset could be: security credentials, such as a registration certificate; executable code to be run on device 106; digital operating parameters; and so on. 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). 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 (e.g., 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 manufacturer 109 is an authorized user. In some embodiments, at 210, the provisioning controller 120 may also determine whether the device 106a (e.g., a product) to be provisioned is authorized to use with system 100. In some cases, the list of authorized devices may be generated by... Figure 1 The regulator 140 provides this information and the provision controller 120 uses it to make such a determination.

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

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

[0086] At 222, DAMS110 generates, creates, calculates, and / or retrieves digital assets for device 106a in response to a request at 205. In various implementations, DAMS110 may create or generate the requested digital security assets, such as public and private key pairs, and registration and pseudonymous certificates for device 106a.

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

[0088] At 225, DAMS110 transmits the digital assets to the distributor 108 of the maker 105 who requested the digital asset service at 205. For example, DAMS110 can securely transmit the public key and private key pair, registration certificate, and pseudonym certificate to the distributor 108 of the maker 105.

[0089] At 226, DAMS 110 transmits log information about the digital asset to provisioning controller 120. In various embodiments, the log information may include information describing requests and transfers of the digital asset, such as requester ID, digital asset ID, distributor ID, timestamps of the request and transfer actions, received microprocessor serial numbers, etc. In some embodiments, the log information may include a copy of the digital asset. At 227, provisioning controller 120 receives the log information and stores it, for example, in database 125. Provisioning controller 120 effectively maintains an audit trail of all activities occurring in system 100, which allows the compilation of various types of data, such as data about how and when manufacturer 105 constructs and provisions device 106a. Such data and log information can be used for billing and auditing purposes.

[0090] At 230, distributor 108 receives and stores digital assets (such as public and private key pairs, registration certificates, and pseudonymous certificates) sent by DAMS 110.

[0091] At 235, distributor 108 requests and receives digital security assets, such as a public key, from device 106a, which can be used to securely transfer digital assets from distributor 108 to device 106a. Various types of device 106a can use a security processor built into device 106a to generate short key pairs, and the public key can be part of that short key pair. At 240, distributor 108 uses the digital security assets (e.g., the public key) to securely transfer digital assets (e.g., a registration certificate) to device 106a. In various implementations, distributor 108 can use the public key of device 106a to form, for example, a Virtual Private Network (VPN) with device 106a and securely transfer digital assets therein.

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

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

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

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

[0096] Device 106a receives and stores digital assets for use during operation. For example, if device 106a is an onboard unit (OBU) or electronic control unit (ECU) and the digital asset is a security asset (such as a public key certificate) required to join a wireless network, the digital security asset is stored by the OBU. Later, when the OBU is installed and activated in the vehicle, 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. The OBU can only be authenticated and join the network if it has the digital security asset provided by the distributor 108 at manufacturer 105.

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

[0098] At 250, the distributor 108 transmits status information to the provisioning controller 120. Furthermore, at 255, the provisioning controller 120 receives and stores the status information associated with the log information stored in operation 227. Therefore, the provisioning controller 120 continues with an audit trail or audit log for all system 100 activities associated with each specific device 106. In various implementations, the audit log may include: indication information for each device 106; 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 password type; and so on.

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

[0100] Figure 2The examples depicted are for illustrative purposes only and are not intended to be limiting. Furthermore, the examples of process 200 depicted are intended to concisely and clearly explain certain novel and inventive features conforming to certain embodiments of this disclosure, but these examples are not intended to be limiting, and many variations are possible. For example, although the illustrations show functions and operations performed in a specific order, the described order is merely illustrative, and various different sequences of operations conforming to certain embodiments of this disclosure can be performed. Moreover, operations are described as discrete steps for illustrative purposes only, while in some embodiments, multiple operations may be performed simultaneously and / or as part of a single computation or larger operation. The described operations are not intended to be exhaustive, limiting, or absolute, and various operations can be modified, inserted, or deleted. Examples of variations are given, although... Figure 2 The description is generally in the context of a single digital asset (e.g., a single digital certificate), but the system and process will similarly operate to handle multiple digital assets (e.g., two or more digital certificates). Alternatively, if device 106a lacks secure communication capabilities, operations 235 and 240 can be omitted, and distributor 108 can communicate with device 106b using unencrypted communication.

[0101] For example, in various implementations, provisioning controller 120 or an authorized agent (such as a dedicated signer) can similarly transmit to distributor 108, causing it to load another or additional digital asset into device 106b, including digital assets such as software, firmware, FUSE objects, manifest files, etc. In such implementations, provisioning controller 120 can 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 (Not shown), the provisioning controller 120 or its authorized agent can retrieve an executable software image (e.g., a compiled computer program stored in database 125) to be loaded into and run by device 106a, and send the executable software image to distributor 10 for programming into the device. In various embodiments, the digital assets accessed by the provisioning controller 120 may contain only software securely supplied, distributed, and / or authorized by the manufacturer 105 of device 106a, thus preventing any unauthorized software from being loaded into device 106a. In some embodiments, the digital assets retrieved by the provisioning controller 120 may be stored in a storage device or database associated with the provisioning controller 120, such as... Figure 1 In database 125.

[0102] Figure 3This is a swimlane diagram illustrating an example of 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 can be executed by executing code on a general-purpose computing system (which may include one or more processors or one or more computing subsystems) by a system consisting of pure hardware or both. Figure 3 As shown above, the entities involved in process 300 include the installer 130 of the computerized device 106, the distributor 131 located at the installer 130, the provisioning controller 120, and the DAMS 110. In various embodiments, these entities may be as described in reference Figure 1 And entities that are present throughout this disclosure and can communicate with each other.

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

[0104] In some implementations, device 106b may be provisioned only partially and not fully functional. For example, the manufacturer 105 of device 106b may only provide a registration certificate for device 106b, so that device 106b may need 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, installer 130 (e.g., employee 132) transmits installation status data to provisioning controller 120. In various implementations, installation status data includes immutable identifiers of the installed device, such as serial numbers or other fixed unique identification information, such as a public key in a key pair that is never erased once generated. Installation status data may also include other information, such as a unique identifier for installer 130, information indicating how and when device 106b was installed, information about the results of tests performed on the installed device 106b, information proving that installer 130 installed device 106b in accordance with applicable specifications, contractual requirements and / or instructions, and / or other similar information.

[0106] At 320, the provisioning controller 120 determines whether the user from installer 130 is an authorized user. If not, the provisioning controller 120 rejects 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 may determine that the device 106b is authorized by verifying against information previously stored in its database 125: 1) a record for the device 106b exists 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 (who has been verified as an authorized installer at 320).

[0107] If the device identified in the installation status data is not authorized, the provisioning controller 120 rejects installation status communication. Figure 3 (Not shown). On the other hand, if 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 device 106b. For example, as referenced Figure 2 As described in operation 227, the log information associated with device 106b may have been previously stored in database 125.

[0108] At 335, provisioning controller 120 directs, instructs, or otherwise controls DAMS 110 to fulfill a provisioning request, for example, by transmitting a request to device 106b at provisioning installer 130 to DAMS 110. At 340, in response to and based on the condition received from 335, DAMS 110 generates and / or retrieves the digital asset requested at 335. In various embodiments, see reference to... Figure 2 The DAMS 110 can create or generate the requested digital assets, such as pseudonymous certificates or other public key certificates. In various implementations, the DAMS 110 or provisioning controller 120, other than the DAMS 110, can additionally or alternatively retrieve, obtain, or otherwise access the requested digital assets, such as executable images previously stored in database 125, for use in a device of type device 106b.

[0109] At 345, DAMS110 transfers the digital assets to distributor 131 of installer 130, which has already been transferred to the installation state at 315. For example, DAMS110 can securely transfer pseudonymous certificates to distributor 131 of installer 130.

[0110] At 350, distributor 131 performs as referenced. Figure 2Operations 230-245 are the same or similar operations. At 355, the distributor 131 transmits status information to the provisioning controller 120. Furthermore, at 360, the provisioning controller 120 receives and stores status information associated with previously stored information about device 106b, such as the status information stored in operation 227. Therefore, the provisioning controller 120 continues with audit trails or audit logs for all system 100 activities associated with each specific device 106.

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

[0112] Figure 4A and Figure 4B This is an example architecture block diagram of 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 transaction and certificate generation processing on a very large number of devices. 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 implementations shown, the application platform may include one or more virtual machines.

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

[0114] In some implementations, the scalable CMS 400 may provide security certificates, such as registration certificates and pseudonym certificates, for use by the distributor 108 of manufacturer 105, as described in reference [reference needed]. Figure 1 It operates as described in other parts of this disclosure. In some embodiments, the scalable CMS 400 may be similar to that described above. Figure 1 The described Digital Asset Management System (DAMS) 110 interacts with the distributor 108 to provide certificates.

[0115] like Figure 4A As illustrated in the example, the architecture of CMS 400 may include two provisioning controllers 120, namely a primary provisioning controller and a standby provisioning controller, which are preferably implemented in separate servers. These two provisioning controllers 120 include functionality that allows objects, data, etc., contained in the primary provisioning controller to be replicated or otherwise included in the standby (secondary) provisioning controller. If the primary provisioning controller goes offline for any reason, the standby provisioning controller can come online to replace the primary provisioning controller. This provides continuous availability (or extremely high availability) of the provisioning controllers 120. In various implementations, the primary provisioning controller and the standby provisioning controller may be as described in reference... Figure 1 And as described in other parts of this disclosure. In various embodiments, the provisioning controller 120 may employ the same configuration as described herein. Figure 1 The connection and communication between the central provisioning controller 120 and the manufacturer's distributor 108 are connected to the scalable CMS 400 in the same or similar manner.

[0116] Generally, the provisioning controller 120 manages system elements, including infrastructure, ensuring that only explicitly authorized elements can participate in and interact with the scalable CMS 400. In various implementations, the provisioning controller 120 may integrate with an employee identification and authorization system for users (e.g., manufacturer 105 or installer 130), or it may provide its own identification and authorization capabilities, allowing only authorized users to use the scalable CMS 400. In some implementations, the provisioning controller 120 may be a device lifecycle management (DLM) controller, such as a primary DLM controller and a backup DLM controller. In various implementations, the provisioning controller 120 may be a controller present in the CMS 400 by component type. For example, in... Figure 4A and Figure 4B In this context, the provisioning controller 120 may be a set or a pair of controllers that exist for the registration approval authority 420, the registration 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 implementations of expressive state transitions.

[0118] The (REST) ​​Web service includes a registry authority 405, a registry authority 420, a registry authority computing engine 425, a registration certificate authority 430, a registration certificate authority computing engine 435, a pseudonym certificate authority 440, a pseudonym 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 scalable CMS 400's architecture effectively separates non-security-related applications from security functions. For example... Figure 4A and Figure 4BAs illustrated in the example, Registration Authority 420, Registration Certificate Authority 430, Pseudo-Certificate Authority 440, and Link Authority 450, 460 are implemented as applications on their own VMs, which run on their own dedicated compute engines 425, 435, 445, 455, and 465. All of these compute engines are decoupled from any non-security-related applications and functions. This provides significant technical and security advantages and improvements compared to conventional systems, where HSMs are slower, cloud service providers cannot provision HSMs, or cannot ensure proper management of HSMs by the system. In the Scalable CMS 400, all encryption operations requiring HSMs are performed within the compute engines (e.g., one or more of compute 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 assigning them to separate computing engines, for example, computationally intensive encryption and security functions (such as elliptic curve butterfly computation or elliptic curve digital signatures) performed by the Registration Authority 420, Registration Certificate Authority 430, Pseudo-Certificate Authority 440, and Linked Authority 450, 460 are performed much faster than in existing registration authority systems. This design significantly improves transaction processing by allowing "bottleneck" applications to be scaled individually as needed. Accordingly, embodiments of this disclosure provide a specific system architecture with technical advantages that reduces bottlenecks associated with existing registration authority systems. For example, if registration authority applications running on Registration Authorities 405 and 420 require scaling, additional VMs can be added without any changes to the secure computing capabilities of the registration authority computing engine 425. Alternatively, if secure computing is limiting performance, additional secure registration authority computing engines 425 can be added. The same multidimensional scaling also applies to other components of CMS 400. These capabilities offer 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 and approval authority 405 is connected to other components via a messaging subsystem or message queuing service, including input message queues 410, 411, 412, 413, 414, 415, 416, 417, 418, and 419, and these other components are interconnected. 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 messages in these queues flow in one direction (e.g., from client to server). Using a single input queue for each VM and compute engine provides a simplified technical advantage.

[0122] In some implementations, the messaging service may be a fast message queuing service, such as Amazon Simple Queuing Service (SQS) provided by Amazon Web Services. For example, according to such an implementation, message queues 410, 411, 412, 413, 414, 415, 416, 417, 418, and 419 may be SQS message queues. By using input message queues 410, 411, 412, 413, 414, 415, 416, 417, 418, and 419 to enable communication between the application VM and the computing engine, the application VM and the computing engine can be scaled independently as needed. In other words, since the application platforms for the registration authority 420, the registration certificate authority 430, the pseudonym certificate authority 440, and the link authority 450 and 460 are connected to the computing engines 425, 435, 445, 455, and 465 via the respective sets of input message queues, these components of CMS 400, as well as the database 470, can be scaled independently of each other.

[0123] As mentioned above and Figure 4A and Figure 4B As shown in the non-limiting examples, each of the registration authorities 405, 420, certificate authorities 430, 440, and linking authority 450, 460 can be implemented as an application on its own virtual machine (VM). In additional or alternative implementations, one or more of the registration authorities 405, 420, certificate authorities 430, 440, and linking authority 450, 460 can be executed on a hardware platform (e.g., a server or computing engine). The role and function of each application executed on the application platform (e.g., a VM or hardware platform) are described in the following paragraphs.

[0124] In various implementations, the registration authority 405 may be an authority within a provisioned network that verifies user requests for digital certificates or other types of digital security assets and enables certificate authorities (such as registration certificate authority 430 and pseudonymous certificate authority 440) to issue digital certificates. In various implementations, the registration authority 405 may resemble a registration authority known in a public key infrastructure (PKI) system. In various implementations, the registration authority 405 may be implemented as a Representational State Transfer (REST) ​​web service. Figure 4AThe three “stacked” rectangles shown represent the fact that, in various implementations, multiple registration approval agencies 405 may be executing simultaneously. Figure 4A and Figure 4B Other "stacked" elements are represented similarly. The registry authority function of CMS 400 is decentralized because its functionality can be performed by multiple registry authorities 405 and 420, implemented as REST web services. The primary role of registry authorities 405 and 420 is to grant and fulfill certificate provisioning requests while the pseudonymous certificate authority 440 is unaware of which certificates ultimately appear on a particular computerized device. Registry authorities 405 and 420 interact directly with the pseudonymous certificate authority 440 and link authority 450 and 460 via message queues 414, 416, and 418 to fulfill their roles within CMS 400.

[0125] As indicated by the "DB" arrow in the lower left corner of the rectangle, the registration approval agency is 405 (and... Figure 4A and Figure 4B Other components (indicated by the "DB" arrow) can connect to their respective databases 470. Although Figure 4A Only a single database 470 is shown, but it should be understood that CMS 400 can utilize data storage areas or collections of databases 470 for data storage and retrieval. For example, database 470 may consist of one or more logical or physical database units, each with one or more forms, thereby enabling data separation as needed. As used herein, the term "database" refers to one or more databases or data storage areas. In some embodiments, using multiple databases 470 allows the registration approval authority 405 to... Figure 4A and Figure 4B Data separation between other components indicated by the "DB" arrow. For example, using multiple databases 470 in this way allows for data separation between registration and approval authorities 405, 420, certificate authorities 430, 440, and linking authority 450, 460.

[0126] In a preferred embodiment, database 470 is a collection of one or more low-latency databases with fast access. 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 previously issued certificates, 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 in some combination thereof.

[0127] In various implementations, the scalable CMS 400 includes a registration certificate authority 430 and a pseudonym certificate authority 440, because the digital certificate generated by the registration authority 405 is divided into different segments, such as a registration digital certificate and a pseudonym digital certificate.

[0128] Registration Certificate Authority 430 is a non-centralized component of CMS 400 because multiple Registration Certificate Authority 430s may exist simultaneously. For example... Figure 4A As shown by the three "stacked" rectangles of the Registration Certificate Authority 430, in some embodiments, multiple Registration Certificate Authority 430s may be operating simultaneously. The Registration Certificate Authority 430 can receive requests for registration certificates from the Registration Authority 420. The primary function of the Registration Certificate Authority 430 is to fulfill requests from the Registration Authority 420 to provide certificates to end-user equipment.

[0129] (such as) Figure 1 The manufacturer 105 (distributor 108) issued the registration certificate. See below for reference. Figure 5A The registration certificate issuing authority 430 interacts directly with the registration approval authority 420 in order to fulfill its role within the CMS 400.

[0130] The pseudonym certificate authority 440 is a non-centralized component of CMS 400 because multiple pseudonym certificate authorities 440 may be running simultaneously. Furthermore, as... Figure 4A As shown by the three "stacked" rectangles of the pseudonym certificate authority 440, in various implementations, multiple pseudonym certificate authorities 440 may exist and execute in parallel. The pseudonym certificate authority 440 can receive requests for pseudonym certificates from the registration authority 420. The primary function of the pseudonym certificate authority 440 is to fulfill requests from the registration authority 420 to provide certificates to end-user devices (such as…) Figure 1 The distributor 108 of the manufacturer 105 (shown) issues pseudonym certificates. In some embodiments, the pseudonym certificate authority 440 fulfills requests for short-term pseudonym certificates for V2V functionality. See below for reference. Figure 5B The pseudonym certificate authority 440 interacts directly with the registration authority 420 to perform its functions within the CMS 400.

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

[0132] In various implementations, computing engines 425, 435, 445, 455, and 465, as well as provisioning controller 120, include an HSM that allows these components to perform secure computation without being subject to excessive threats from hackers. In some implementations, computing engines 425, 435, 445, 455, and 465 may be designed to perform secure computation independently without an embedded HSM; in such implementations, they are embodied as an HSM.

[0133] In various implementations, different versions of the HSM can be used in the CMS 400. For example, the HSM may include an embedded HSM installed as a plug-in card within one or more of the computing engines 425, 435, 445, 455, and 465. In such an example implementation, the embedded HSM may serve as an interconnect for peripheral components.

[0134] A (PCI) HSM or a PCI Express (PCIe) HSM is installed in one or more compute engines. Similarly, HSMs in, for example, the CMS400 can include external HSMs that are network-attached or network-connected, and are separate from the compute 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 merely examples presented for clarity and explanation. Other components, processes, implementation details, and variations may be used without departing from the principles of the invention, as these examples are not intended to be limiting and many variations are possible.

[0136] Figure 5A and Figure 5BThis is a swimlane 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 processes 500 or operations shown can be executed by executing code on a general-purpose computing system (which may include one or more processors or one or more computing subsystems) by a system consisting of pure hardware or both. Figure 5A and Figure 5B As shown above, the entities involved in process 500 include the distributor 108 located at the manufacturer 105, the CMS host's registration and approval authority 420, link authorization authorities 450 and 460, pseudonymous certificate authority 440, and registration certificate authority 430. In various embodiments, these entities may be as described in reference... Figure 4A and Figure 4B And entities that are present throughout this disclosure and can communicate with each other.

[0137] like Figure 5A As illustrated in the example, process 500 begins with registration-related operations 505-535. The primary function of the Registration Certificate Authority 430 is to fulfill requests from the Registration Authority 420 to issue registration certificates to end-user equipment (such as distributor 108). As described below with reference to registration-related operations 505-535, the Registration Certificate Authority 430 interacts directly with the Registration Authority 420 to issue the requested registration certificate to distributor 108.

[0138] At 505, the distributor 108 of manufacturer 105 requests a registration certificate from registration authority 420, which will be made available to device 106a (e.g., for its use), and the request can identify device 106a as the destination of the registration certificate. This request could be, for example, from distributor 108 at manufacturer 105 requesting a registration certificate for a new device 106A (e.g., a new product). See above. Figure 2 The 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 (e.g., in the example of USDOT's V2X ecosystem, enabling communication and operation between vehicles and roadside infrastructure).

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

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

[0141] Operations 540-599 relate to the provision of a pseudonym certificate. At 540, distributor 108 requests a pseudonym certificate from registration authority 420. The pseudonym certificate will be provisioned to device 106a (e.g., for its use), and a request is made to identify device 106a as the destination of the pseudonym certificate. This request could be, for example, distributor 108 of manufacturer 105 requesting a pseudonym certificate from a computerized device (e.g., registered device 106A) that previously received a registration certificate. The pseudonym certificate includes a public key certificate with a certain value (e.g., weekly value, monthly value, or annual value).

[0142] At 545, the registration authority 420 receives the request for a pseudonym certificate, and then the registration authority 420 initiates the preparation of the pseudonym certificate.

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

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

[0145] Next, as Figure 5B As shown, at 565, in response to receiving a request for a second set of link values, the second link authorization authority 460 generates a second set of link values ​​and transmits it to the registration and approval authority 420. At 570, the registration and approval authority 420 receives the second set of link values.

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

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

[0148]

[0149]

[0150]

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

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

[0153] At 595, distributor 108 may send multiple requests to registration authority 420 to query whether the requested pseudonym certificate is ready (i.e., generated and available). In some implementations, 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 the request for the pseudonym certificate is sent to registration authority 420 in operation 540, distributor 108 may periodically send queries to registration 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 generating the pseudonym certificate).

[0154] At 598, when the pseudonym certificate is ready, the registration authority 420 transmits the pseudonym certificate to the distributor 108. At 599, the distributor 108 receives the pseudonym certificate. At this point, the distributor 108 can provision the pseudonym certificate to a device (e.g., device 106a) so that the device can use the pseudonym certificate, thus completing the pseudonym certificate provisioning operation.

[0155] In some non-limiting example implementations, the request for a pseudonym certificate exchanged in operations 575-590 and the response to that request may include a message with a header and payload data items, as follows:

[0156]

[0157] Figure 6A and Figure 6B This is a block diagram 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, and 619 according to an embodiment of the present invention.

[0158] As mentioned above Figure 4A and Figure 4BThe various implementations of the described CMS 400 and Scalable CMS 600 can be used for processing extremely large volumes of device transactions and certificate generation. In some implementations, 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). Figure 6A and Figure 6B In the example implementations shown, the application platform may include one or more virtual machines (VMs). In additional or alternative implementations, the application platform may include one or more hardware platforms, such as servers, computers, or other computer hardware capable of executing software applications. Examples of the Scalable CMS 600 can be implemented in private data centers, cloud data centers such as Amazon Web Services (AWS) from Amazon, or hybrid data centers combining private and cloud data centers. For simplicity, only the following descriptions are provided. Figure 6A and Figure 6B Internal and Figure 4A and Figure 4B The differences that exist.

[0159] like Figure 6A As illustrated in the example, the architecture of CMS 600 may include two provisioning controllers 602, namely a primary provisioning controller and a standby provisioning controller, which are preferably implemented in separate servers. These two provisioning controllers 602 include... Figure 4A The provisioning controller 102 in the above reference has a similar function, so as to provide for the above reference. Figure 4A The aforementioned failover purpose involves copying or otherwise including objects, data, etc., contained in the primary provisioning controller in a standby (secondary) provisioning controller. In some embodiments, provisioning controller 602 may be a DLM controller, such as a primary DLM controller and a standby DLM controller. In various embodiments, provisioning controller 602 may be a controller present in CMS 600 according to component type. Figure 6A and Figure 6B In the example, provisioning controller 602 can be a pair of controllers (e.g., primary controller and backup controller) that exist for registration approval authority 620, registration certificate authority 430, pseudonym certificate authority 440 and linking authority 450, 460.

[0160] like Figure 6A and Figure 6BAs shown, the architecture of the Scalable CMS 600 includes a registry authority 605 implemented as a REST web service, a registry authority 620, a registry authority computing engine 625, a registration certificate authority 630, a registration certificate authority computing engine 635, a pseudonym certificate authority 640, a pseudonym 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's architecture effectively separates non-security-related applications from security functions. Figure 6A and Figure 6B In the non-restricted example, the Registration Authority 620, Registration Certificate Authority 630, Pseudo-Certificate Authority 640, and Link Authority 650 and 660 are implemented as applications on their own VMs, which run on their own dedicated compute engines 625, 635, 645, 655, and 665, all of which are decoupled from any non-security-related applications and functions. This offers significant technical and security advantages and improvements compared to conventional systems, where HSMs are slower, cloud service providers cannot provision HSMs, or cannot ensure proper management of HSMs by the system. In the Scalable CMS 600, all encryption operations requiring HSMs are performed within the compute engines (e.g., one or more of compute engines 625, 635, 645, 655, and 665). In other words, in CMS 600, all encryption operations requiring HSMs are performed within the compute engines.

[0162] like Figure 6A and Figure 6B As shown, by separating critical security functions and assigning them to separate computing engines, such as the execution of computationally intensive encryption and security functions by the Registration Authority 620, Registration Certificate Authority 630, Pseudo-Certificate Authority 640, and Linked Authority 650, 660, the system performs significantly faster than existing Registration Authority systems. This design significantly improves transaction processing by allowing bottleneck applications to be scaled individually as needed. For example, if Registration Authority applications running on Registration Authority 605 and 620 require scaling, additional application platforms (e.g., VMs or hardware platforms) can be added without altering the secure computing capabilities of Registration Authority computing engine 625. Similarly, for example, if secure computing is limiting performance, additional secure Registration Authority computing engines 625 can be added. The same multidimensional scaling also applies to other components of CMS 600.

[0163] exist Figure 6A and Figure 6B In the example shown, the registration and approval authority 605 is connected to other components via bidirectional message queues 610, 611, 612, 613, 614, 615, 616, 617, 618, and 619, and these other components are interconnected. Figure 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 flow bidirectionally within these queues.

[0164] (For example, between the client and server). This provides the performance advantage of separating new requests from pending responses in the message queue. By using bidirectional message queues 610, 611, 612, 613, 614, 615, 616, 617, 618, and 619 to enable communication between application platforms (e.g., VMs and / or hardware platforms) and computing engines, application platforms (e.g., VMs and / or hardware platforms) and computing engines can scale independently. In CMS 600, the application platforms (e.g., VMs and / or hardware platforms) used for registration approval authorities 620, registration certificate authorities 630, pseudonymous certificate authorities 640, and linking authority 650, 660 are connected to computing engines 625, 635, 645, 655, and 665 via their respective sets of bidirectional message queues.

[0165] In CMS 600, the registration approval body 605 (and...) Figure 6A and Figure 6B Other components (indicated by the "DB" arrow) can connect to database 670. In a preferred embodiment, database 670 is a low-latency database with fast access. In some embodiments, database 670 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 670 is application-related but may include previously issued certificates, various link authority values ​​(e.g., link values), data on devices to which certificates have been issued, operator actions, etc. This data may be stored unencrypted, encrypted, or in some combination thereof.

[0166] In various implementations, the Scalable CMS 600 includes a Registered Certificate Authority 630 and a Pseudo-Certificate Authority 640, because the digital certificate generated by the Registration Authority 605 is divided into different segments, such as a Registered Digital Certificate and a Pseudo-Certificate.

[0167] like Figure 6AAs shown by the three “stacked” rectangles of the Registration Certificate Authority 630, in some implementations, multiple Registration Certificate Authority 630s may be executing simultaneously. Figure 6A and Figure 6B Other “stacked” elements are represented similarly. The registration certificate issuing authority 630 may receive multiple requests for registration certificates from the registration approval authority 620.

[0168] In various implementations, computing engines 625, 635, 645, 655, and 665, as well as provisioning controller 602, include an HSM that allows these components to perform secure computation without being subject to excessive threats from hackers. In some implementations, computing engines 625, 635, 645, 655, and 665 may be designed to perform secure computation independently without an embedded HSM; in such implementations, they are embodied as HSMs.

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

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

[0171] As described above with reference to Figures 4 and 6 for CMS 400 and CMS 600, various implementations of the scalable CMS 700 can be used for processing extremely large volumes of device transactions and certificate generation. For simplicity, only the following descriptions are provided. Figure 7A and Figure 7B The differences between this and Figures 4 and 6 are as follows. Figure 7A and Figure 7B In the example implementation shown, the application platform is depicted as including one or more virtual machines (VMs). In additional or alternative implementations, the application platform may 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 Figure 7AAs shown in the example, the architecture of CMS 700 can include two provisioning controllers 702, namely a primary provisioning controller and a standby provisioning controller, which are preferably implemented in separate servers. These two provisioning controllers 702 respectively include... Figure 4A and Figure 6A The provisioning controllers 120 and 602 in the above configuration have similar functions. In other words, based on the above reference... Figure 4A The aforementioned failover purpose is to copy or otherwise include objects, data, etc. contained in the primary provisioning controller in the standby (secondary) provisioning controller.

[0173] like Figure 7A and Figure 7B As shown, the architecture of the scalable CMS 700 includes a registry authority 705, a registry authority 720, a registry authority computing engine 725, a registration certificate authority 730, a registration certificate authority computing engine 735, a pseudonym certificate authority 740, a pseudonym 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 shown in Figures 4 and 6 for CMS 400 and CMS 600, the architecture of the scalable CMS 700 advantageously separates non-security-related applications from security functions. Figure 7A and Figure 7B As shown in the non-restrictive example, the Registration Authority 720, Registration Certificate Authority 730, Pseudo-Certificate Authority 740, and Linked Authority 750, 760 are implemented as applications on their own VMs, which run on their own dedicated compute engines 725, 735, 745, 755, and 765, all of which are decoupled from any non-security-related applications and functions. In the Scalable CMS 700, all encryption operations requiring an HSM are performed within the compute engines (e.g., one or more of compute engines 725, 735, 745, 755, and 765). In the CMS 700, all encryption operations requiring an HSM are performed within the compute engines.

[0175] like Figure 7A and Figure 7BAs shown, by separating critical security functions from each other and assigning them to separate computing engines—for example, the execution of computationally intensive encryption and security functions by the Registration Authority 720, Registration Certificate Authority 730, Pseudo-Certificate Authority 740, and Linked Authority 750, 760—is significantly faster than known registration authority solutions. This design significantly improves transaction processing by allowing bottleneck applications to scale individually on demand, unconstrained by server processing or storage capacity. For instance, if a registration authority application running on Registration Authority 705 and 720 needs scaling, additional application platforms (e.g., VMs or hardware platforms) can be added without altering the secure computing capabilities of Registration Authority computing engine 725. Similarly, for example, if secure computing is limiting performance, additional secure Registration Authority computing engines 725 can be added. The same multidimensional scaling also applies to other components of CMS 700.

[0176] exist Figure 7A and Figure 7B In the example shown, the registration and approval authority 705 is connected to other components via load balancers 710, 711, 712, 713, 714, 715, 716, 717, 718, and 719, and these other components are interconnected. Figure 7A and Figure 7B In the example implementations, load balancers 710, 711, 712, 713, 714, 715, 716, 717, 718, and 719 can be implemented as virtual load balancers (e.g., virtual load balancers running on a VM) or via dedicated hardware. Figure 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 compute engines. This provides the benefit that one or more clients see only a single server endpoint, and the load balancer determines which server will handle a given request. In this way, load balancers 710, 711, 712, 713, 714, 715, 716, 717, 718, and 719 enable application platforms (e.g., VMs and / or hardware platforms) to communicate with each other's compute engines. In CMS 700, the application platforms used for the registration approval authority 720, registration certificate authority 730, pseudonymous certificate authority 740, and link authority 750 and 760 communicate with compute engines 725, 735, 745, 755, and 765 via their respective groups of load balancers.

[0177] In various implementations, the Scalable CMS 700 includes a Registered Certificate Authority 730 and a Pseudo-Certificate Authority 740, because the digital certificate generated by the Registration Authority 705 is divided into different segments, such as a Registered Digital Certificate and a Pseudo-Certificate.

[0178] like Figure 7A As shown by the three "stacked" rectangles of the pseudonym certificate authority 740, in various implementations, there may be multiple instances of pseudonym certificate authority 740 executing simultaneously. Figure 7A and Figure 7B Other “stacked” elements are represented similarly. The pseudonym certificate issuing authority 740 can receive multiple requests for multiple batches of pseudonym certificates (e.g., requests for pseudonym certificates with a weekly value, a monthly value, or a yearly value) from the registration and approval authority 720.

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

[0180] Figure 8 This is a block diagram of an example system 800 for implementing a scalable and secure CMS via polling scheduling requests according to an embodiment of the present invention. For simplicity, 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 can be any set of application platforms and computing engines as described above with reference to FIG7 for implementing any registration authority 720, registration certificate authority 730, pseudonym certificate authority 740, and link authority 750, 760. As shown in CMS 700 in FIG7, in system 800, all encryption operations requiring HSM are performed in the computing engine, and the application platforms and computing engines are scaled independently.

[0181] Continue to refer to Figure 8 Round-robin scheduling refers to using the knowledge of each available server (e.g., each compute engine). The round-robin scheduling request sent in system 800 uses the knowledge of available compute engines (e.g., compute engines 825, 835, 845, 855) to distribute requests and messages sent to that group of compute engines.

[0182] To clearly illustrate the order of polling scheduling requests in System 800, the diagram shows a set of scaled-up computing engines 865, 875, 885, and 895 that can be used with the VM 850. Figure 8 In the example, there are "n" application platforms (e.g., VMs and / or hardware platforms) and "m" available compute engines. A client (e.g., application VM 895) making a request to a compute engine follows... Figure 8 The operations proceed in the order shown. As illustrated, the first request from application VM 895 is to CE1 (Computing Engine 865), the second request is 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 the servers (e.g., a set of available compute engines) with which they need to communicate. Each client executes a round-robin scheduling request to each server, thus advantageously distributing the workload evenly across all servers. In some implementations, the load balancers 710, 711, 712, 713, 714, 715, 716, 717, 718, 719 of the CMS 700 shown in Figure 7 can send round-robin scheduling requests to the compute engines to distribute the workload evenly across the compute engines.

[0184] Figure 9 This is a block diagram of an example system 900 for implementing a scalable and secure CMS based on workload-based requests, according to an embodiment of the present invention. For simplicity, only the following description is provided. Figure 9 Inside and Figure 7 and Figure 8 The differences that exist.

[0185] As Figure 8 For the sake of brevity and clarity, Figure 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... Figure 9 The application platforms (e.g., VMs and / or hardware platforms) 920, 930, 940, 950 and computing engines 925, 935, 945, 955 can be any set of application platforms and computing engines as described above with reference to FIG7 for implementing any registration authority 720, registration certificate authority 730, pseudonym certificate authority 740 and link authority 750, 760. As shown in CMS 700 in FIG7, in system 900, all encryption operations requiring HSM are performed in the computing engines, and the application platforms (e.g., VMs and / or hardware platforms) and computing engines are scaled independently.

[0186] Continue to refer to Figure 9 The workload distribution technology is enabled by adding intelligence to first query the workload of each server used. The workload distribution technology is workload-based because it uses knowledge of the workload of each available server (e.g., each compute engine). Requests sent in System 900 are distributed to that group of compute engines using knowledge of the current workload of the available compute engines (e.g., compute engines 925, 935, 945, 955). 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, the diagram shows a magnified set of compute engines 965, 975, 985, and 995, each reporting its respective workload to the application VM 950. Figure 9 In the example, "m" represents the number of application platforms, and "n" represents the number of compute engines reporting their workload. Figure 9 In the example, workload is reported as a percentage, where a 30% workload for compute engine 975 indicates that compute engine 975 is currently operating at 30% of its total capacity. Similarly, an 80% workload reported by compute engines 965, 985, and 995 indicates that these compute engines are currently operating at 80% of their total capacity. In some implementations, the current workload reported by a given compute engine indicates the workload of the HSM embedded in that compute engine. For example, where the processing capacity of a compute engine is constrained or limited by the ability of its HSM to perform cryptographic operations, the percentage of workload reported by the compute engine can reflect the current workload of the HSM. For instance, if the HSM used by compute engine 975 is operating at 30% of its processing capacity, compute engine 975 can report that it is operating at 30% of its total capacity. In some implementations, the workload percentage can be a weighted measure of the server's (e.g., compute engine's) processing capacity, communication capacity (e.g., a measure of available bandwidth of a direct communication link or wireless module), and storage / memory capacity. In one example, processing capacity, communication capacity, and storage capacity can be assigned an equal weight of one-third. In this example, if the computing engine 975 uses 25% of its central processing unit (CPU) capacity, 35% of its communication capacity, and 30% of its available memory or storage area, the computing engine 975 will report its workload as 30%.

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

[0189] The humidity level inside the computing engine casing; the frequency of restarts or reboots (e.g., thermal shutdown or thermal crash); the time since the most recent restart; the number of disk or memory failures in a recent period (e.g., the previous day, week, or month); the time until the scheduled maintenance event for the computing engine (e.g., software or firmware update, replacement of faulty hardware component); an indication that the computing engine is running on backup power; or the duration since the last power outage or voltage reduction of the computing engine.

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

[0191] In System 900, clients (such as application VM 995) that make requests to the compute engine operate based on the workload reported by the compute engine. Figure 9 In the example, the next request from application VM 995 will arrive at CE2 (Compute Engine 975) based on its relatively low 30% workload. In other words, because Compute Engine 975 has the lowest workload among a set of Compute Engines 965, 975, 985, and 995. When sending the next request from application VM 995 to a Compute Engine, any of CE1 (Compute Engine 965), CE3 (Compute Engine 985), or CEm (Compute Engine 995) can be used, as they are all currently reporting an equal 80% workload. In cases where each available Compute Engine reports the same or similar workload, sequential requests can be used to distribute the workload evenly across these equally loaded Compute Engines. In other words, if each available Compute Engine is reporting substantially equal or even workloads, the above reference can be used. Figure 8 The request is described. Over time, as the workload changes, the client (application VM 995) will send subsequent requests to the least loaded available compute engine.

[0192] In system 900, all clients (e.g., application platforms 920, 930, 940, 950) are aware of the workloads of all servers (e.g., a set of available compute engines) with which they need to communicate. Each client can submit a workload query to each server and use the reported workload 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 Figure 7 can send workload-based requests to the compute engines to distribute the workload evenly across the compute engines.

[0193] Figure 10A and Figure 10B This is an example architecture block diagram of a scalable and secure certificate management system (CMS) 400 according to an embodiment of the present invention. For the sake of simplicity, only the following description is provided. Figure 10A and Figure 10B Internal and Figure 4A and Figure 4B The differences that exist.

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

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

[0196] Examples of CMS1000 can be implemented in private data centers, cloud data centers, or hybrid centers combining private and cloud data centers. Various implementations of CMS1000 can be used for transaction and certificate generation processing on a massive scale. In various implementations, CMS1000 can be implemented using multiple servers, HSMs, and multiple computers or computing engines used as application platforms. In other words, as... Figure 10A and 10BAs shown, the applications of the described registration and approval authorities, certificate authorities, and link authority all run one or more computing engines capable of hosting and executing software applications.

[0197] CMS1000 is similar to the reference above. Figure 4A and Figure 4B The CMS1000 architecture differs from the CMS 400 in that it uses compute engines 1025, 1035, 1045, 1050, and 1060 to host and run applications. In other words, the CMS1000 architecture is an alternative to the CMS 400 architecture, where applications from registration authorities, registration certificate authorities, pseudonymous certificate authorities, and linking authority agencies execute on their own dedicated compute engines 1025, 1035, 1045, 1050, and 1060. In CMS1000, all encryption 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 encryption operations on compute engines 1025, 1035, 1045, 1050, and 1060, the CMS1000 architecture reduces the required number of message queues.

[0198] exist Figure 10A and 10B In the example, the computing engines include a registration authority computing engine 1025 that hosts and runs a registration authority application, a registration certificate authority computing engine 1035 that hosts and runs a registration certificate authority application, a pseudonym certificate authority computing engine 1045 that hosts and runs a pseudonym certificate authority application, a first link authority computing engine 1050 that hosts and runs a first link authority application, and a second link authority 1060 that hosts and runs a second link authority application.

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

[0200] 1012, 1014, 1016, and 1018 are unidirectional queues because messages in these queues flow in one direction (e.g., from client to server). By using a single input queue for each compute engine, and with each compute engine also hosting and running its own applications, a simplified technical advantage can be provided.

[0201] By using input message queues 1010, 1012, 1014, 1016, and 1018 to enable communication between the computing engines, these engines can scale independently as needed. In other words, because the computing engines used as application platforms for registration authorities, registration certificate authorities, pseudonymous certificate authorities, and link authority applications are connected via their respective input message queues, these components of CMS1000, as well as the database 1070, scale independently.

[0202] Figure 11 This 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 Figures 1 to 1 Various components in 0, such as the provisioning controller 120, DAMS 110, and computing engine of the CMS architecture in Figures 4 and 6 through 10, and the load balancers 710-719 in Figure 7, etc. In some embodiments, a series of computing systems similar to computing system 1100 may each be customized with dedicated hardware and / or programmed as dedicated servers to achieve this. Figures 1 to 1 One of the components in 0, which can communicate with each other via network 1135.

[0203] exist Figure 11 In the example shown, computing system 1100 includes several components, such as CPU 1105, memory 1110, input / output (I / O) devices 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.) may include CPU 1105, memory 1110, non-volatile storage device 1120, and I / O devices 1125. In such a configuration, components 1105, 1110, 1120, and 1125 can be connected and communicate via a local data bus and can access a data repository 1130 (e.g., implemented as a separate database system) via external I / O connections. I / O component 1125 can communicate via direct communication links (e.g., hardwired or local WiFi connections), via, for example, a local area network.

[0204] System 1100 is connected to external devices via a network such as a LAN or WAN (e.g., a cellular telephone network or the Internet) and / or through other suitable connections. System 1100 may be a standalone system or a subsystem of a larger system.

[0205] CPU 1105 can be one or more known processors or processing devices, such as those from Intel in Santa Clara, California.TM The company produces Core TM Series microprocessors or AMD in Sunnyvale, California TM The company produces Athlon TM A series of microprocessors. Memory 1110 may be one or more flash storage devices configured to store instructions and information executed or used by CPU 1105 to perform certain functions, methods, and processes related to embodiments of the present invention. Storage device 1120 may be volatile or non-volatile, magnetic, semiconductor, magnetic tape, optical, or other types of storage devices or computer-readable media, including devices such as CDs and DVDs, and solid-state devices intended for long-term storage.

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

[0207] In one embodiment, memory 1110 may include program 1115 for performing the specific functions and operations described herein with respect to 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) unrelated to this 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. Choosing or using an operating system is not an essential technical feature of this invention.

[0209] 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. HSM 1140 protects digital security assets (such as encryption keys) and other sensitive data from potential access by attackers. In some implementations, HSM may be a card or board directly attached to computing system 1100.

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

[0211] In the illustrated embodiment, system 1100 is connected to network 1135 (such as the Internet, a private network, a virtual private network, a cellular network, or other networks, or combinations thereof), which in turn can be connected to various systems and computing machines, such as servers, personal computers, laptops, client devices, etc. Generally, system 1100 can input data from and output data to external machines and devices via network 1135.

[0212] exist Figure 11 In the example implementation shown, data source 1130 is a separate database outside of system 1100, such as database 125. In other implementations, data source 1130 may be hosted by system 1100. In various implementations, data source 1130 may manage and store data for implementing the systems and methods according to the present invention. For example, data source 1130 may manage and store data structures containing status and log information of each device 116 provisioned by 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 database. 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 limited to the use of a database or data structure.

[0214] Those skilled in the art should recognize that, Figure 11 The components and implementation details of the system are presented as clear and concise examples. Other components and implementation details may be used.

[0215] Although the examples above use specific examples of computerized devices such as OBU, ECU, and RSU, for clarity, the invention is not limited to those specific examples. Various embodiments of the invention can be used with a wide range 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 (eUICC)), etc.

[0216] The various operations of the applications described herein can be performed at least in part by one or more VMs. In additional or alternative implementations, the various operations of the applications described herein can 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 can constitute processor-implemented modules that operate to perform the operations, functions, and roles of one or more applications described herein. As used herein, the term "processor-implemented module" refers to a hardware module implemented using one or more processors.

[0217] Similarly, the methods described herein can be implemented at least in part by a processor, where one or more specific processors are examples of hardware. For example, at least some operations of a method can be performed by one or more processors or modules implemented by processors. One or more processors can also operate in "cloud computing".

[0218] The environment supports the execution of related operations or is operable as SaaS. For example, at least some operations can be performed by a set of computers (as an example of a machine including a processor), and these operations can be accessed via a network (such as the Internet) and via one or more appropriate interfaces (such as APIs).

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

[0220] Other embodiments of the invention will become apparent to those skilled in the art upon consideration of the description herein and upon practice of the inventive content. The description and embodiments are to be considered exemplary only, and the true scope of protection of the invention is defined by the appended claims.

Claims

1. A scalable certificate management system for securely providing certificates, wherein, The scalable certificate management system includes: One or more application platforms running registration and approval agency applications, whose communication connections are made to one or more computing engines that perform encrypted computations to execute registration and approval agency application requests; One or more application platforms running a Registration Certificate Authority (RCA) application are communicatively connected to one or more computing engines that perform cryptographic computations on requests from the CCA application, wherein the CCA application is operable to generate a registration certificate and conditionally transmit the registration certificate to the CCA application in response to receiving a request for a registration certificate from the Registration Authority application. One or more application platforms running pseudonymous certificate authority applications are communicatively connected to one or more computing engines that perform cryptographic computations requested by the pseudonymous certificate authority applications, wherein the pseudonymous certificate authority applications are operable to generate pseudonymous certificates and conditionally transmit the pseudonymous certificates to the registration and approval authority applications in response to receiving a request for a pseudonymous certificate from the registration and approval authority applications. One or more application platforms running the first link authority application, whose communication is connected to one or more computing engines that perform encrypted computations to execute requests from the first link authority application; One or more application platforms running a second link authority application are communicatively connected to one or more computing 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 a link value in response to receiving a request for a link value from the registration and approval authority application and conditionally transmit the link value to the registration and approval authority application; and One or more load balancers communicatively connected to one or more computing engines, the load balancers performing operations including distributing at least one request to the one or more computing engines based on a normality metric of the one or more computing engines; and The scalable certificate management system distributes one or more certificate payloads to each of a plurality of computerized devices, wherein the one or more certificate payloads indicate the number of pseudonymous certificates to be stored in each computerized device over a period of time, and wherein the one or more certificate payloads are allocable such that each computerized device can store multiple pseudonymous certificates that are different from those of other computerized devices over the period of time.

2. The certificate management system according to claim 1, wherein, The normal condition measurement includes one or more of the following: the operating temperature of the one or more computing engines, the humidity level inside the chassis 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 the scheduled maintenance event of the one or more computing engines, an indication that the one or more computing engines are running on backup power, or the duration since the last power outage or voltage reduction 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 operatively connected to the application platforms of the one or more registration and approval authority applications, the one or more application platforms of the registration certificate authority applications, the one or more application platforms of the pseudonym certificate authority applications, the one or more application platforms of the first link authority applications, and the one or more application platforms of the second link authority applications.

4. The certificate management system according to claim 2, wherein, The registration approval agency application, the registration certificate issuing agency application, the pseudonym certificate issuing agency application, the first linking authority application, the second linking authority application, and each of the one or more databases are operable to scale independently of each other.

5. The certificate management system according to claim 1, wherein, Each of the registration approval agency application, the registration certificate issuing agency application, the pseudonym certificate issuing agency application, the first linking authority application, and the second linking authority application communicates with each other through a message queuing service that includes multiple message queues.

6. The certificate management system according to claim 1, wherein, The application platform running the one or more Registry Certificate Authority applications is connected via a first plurality of message queues to one or more virtual machines of the computing engine that performs the encrypted computation requests of the one or more Registry Certificate Authority applications. The application platform running the first link authority application is connected to one or more virtual machines of the computing engine that performs encrypted computations for the first link authority application through a second or more message queue communication. as well as The application platform running the second link authority application is connected to one or more virtual machines of the computing engine that performs encrypted computations for the second link authority application requests via a third message queue communication.

7. The certificate management system according to claim 6, wherein, The first plurality of message queues include: The first message queue is used to queue messages to be delivered to one or more virtual machines running Registry of Certificate Authorities applications; and The second message queue is used to queue messages to be delivered to the computing engine that performs the cryptographic computation request for the one or more Certificate Authority applications; The second plurality of message queues include: A third message queue is used to queue messages to be delivered to one or more virtual machines running applications of the first link authority; and A fourth message queue is used to queue messages to be delivered to the computing engine that performs the encrypted computation request for the first linking authority application; and The third plurality of message queues includes: The fifth message queue is used to queue messages to be delivered to one or more virtual machines running applications with second-level link authority permissions; and The sixth message queue is used to queue messages to be delivered to the computing engine that performs the encrypted computation request for the second linking authority application.

8. The certificate management system according to claim 6, wherein, The first plurality of message queues include: A first bidirectional message queue is used to queue messages to be delivered to and sent from the one or more virtual machines running the Registry of Certificate Authorities application; and A second bidirectional message queue is used to queue messages to be delivered to and sent from the computing engines that perform cryptographic computing requests for the one or more Certificate Authority of Registered Services (CAs). The second plurality of message queues include: A third bidirectional message queue is used to queue 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 is used to queue messages to be delivered to and sent from the computing engines performing cryptographic computations that request the first linking authority application; and The third plurality of message queues includes: A fifth bidirectional message queue is used to queue messages to be delivered to and sent from one or more virtual machines running the second link authority application; and The sixth bidirectional message queue is used to queue messages to be delivered to and sent from the computing engines that perform cryptographic computations for the one or more second-link authorization authority application requests.

9. The certificate management system according to claim 1, wherein, The application platform of the one or more running Registry of Certificate Authorities applications is communicatively connected to the computing engine of the one or more executing Registry of Certificate Authorities applications' encrypted computing requests through the first load balancer of the one or more load balancers; The application platforms running the first link permission authority application are connected to the computing engines that perform encrypted computations for the first link permission authority application through the second load balancer of the one or more load balancers. as well as The application platforms running the second link authority application communicate with one or more computing engines that perform encrypted computations for the second link authority application requests through a third load balancer of the one or more load balancers.

10. The certificate management system according to claim 9, 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 Both the load balancer virtual machine and the load balancer server are configured to distribute workloads across multiple application platforms and multiple computing engines.

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

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

13. The certificate management system according to claim 1, wherein, The certificate management system is further operable to transmit information about certificate activities related to computerized devices to the provisioning controller for storage in a log.

14. The certificate management system of claim 1 further includes a provisioning controller operable to authenticate the computerized device before transmitting a request for a registration certificate to the registration authority.

15. The certificate management system according to claim 1, wherein, A registration certificate is a public key certificate that identifies the holder of a public key certificate as an authorized participant in an ecosystem comprising multiple computerized devices, wherein each authorized participant in the ecosystem is able to receive one or more pseudonymous certificates that enable communication with multiple computerized devices.

16. The certificate management system according to claim 1, wherein, The certificate payload can be allocated by the subscriber.

17. The certificate management system according to claim 1, wherein, The scalable certificate management system assigns pseudonym certificates to each subscriber and indicates the number of pseudonym certificates available over a period of time.

18. A method for securely providing certificates, wherein, The method includes: Perform cryptographic computation requested by a registration authority application, which is communicatively connected to one or more computation engines that perform the cryptographic computation requested by the registration authority application; Perform cryptographic computation requested by a Registration Certificate Authority (RCA) application, the RCA application being communicatively connected to one or more computation engines that perform the cryptographic computation requested by the RCA application, wherein the RCA application generates a registration certificate in response to receiving a request for a registration certificate from the Registration Authority (RA) application and conditionally transmits the registration certificate to the RA. Perform cryptographic computation requested by a pseudonym certificate authority application, the pseudonym certificate authority application being communicatively connected to one or more computation engines that perform the cryptographic computation requested by the pseudonym certificate authority application, wherein the pseudonym certificate authority application generates a pseudonym certificate in response to receiving a request for a pseudonym certificate from the registration authority application and conditionally transmits the pseudonym certificate to the registration authority application; Perform cryptographic computation requested by a first link authority application, which is communicatively connected to one or more computation engines that perform the cryptographic computation requested by the first link authority application. Performing cryptographic computation requested by a second linking authority application, the second linking authority application being communicatively connected to one or more computation engines that perform the cryptographic computation requested by the second linking authority application, wherein the first linking authority application and the second linking authority application generate a link value in response to receiving a request for a link value from the registration and approval authority application and conditionally transmit the link value to the registration and approval authority application; and One or more certificate payloads are distributed to each of a plurality of computerized devices, the one or more certificate payloads indicating the number of pseudonymous certificates to be stored in each computerized device over a period of time, wherein the certificate payloads are allocable such that each computerized device can store multiple pseudonymous certificates different from those of other computerized devices over the period of time. The operation involves one or more load balancers communicatively connected to one or more computing engines, the operation including distributing at least one request to one or more computing engines based on the normality metric of the one or more computing engines.

19. The method according to claim 18, wherein, The normal condition measurement includes one or more of the following: the operating temperature of the one or more computing engines, the humidity level inside the chassis 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 the scheduled maintenance event of the one or more computing engines, an indication that the one or more computing engines are running on backup power, or the duration since the last power outage or voltage reduction of the one or more computing engines.

20. The method of claim 18 further includes transmitting information about certificate activities related to the computerized device to the provisioning controller for storage in a log.

21. The method of claim 18, further comprising authenticating the computerized device before sending a request for registration certificate to the registration authority.

22. The method according to claim 18, wherein, A registration certificate is a public key certificate that identifies the holder of a public key certificate as an authorized participant in an ecosystem comprising multiple computerized devices, wherein each authorized participant in the ecosystem is able to receive one or more pseudonymous certificates that enable communication with multiple computerized devices.

23. The method according to claim 18, wherein, The certificate payload can be allocated by the subscriber.

24. The method of claim 18, further comprising assigning pseudonym certificates to each subscriber for use, indicating the number of pseudonym certificates available over a period of time.

25. A non-transitory computer-readable medium for securely providing certificates, the non-transitory computer-readable medium comprising a plurality of instructions, the plurality of instructions being responsive to execution by a processor to cause the processor to perform an operation, the operation comprising: Perform encrypted calculations requested by the registration and approval authority; Perform cryptographic computation requested by a registration certificate authority application, wherein the registration certificate authority application generates a registration certificate in response to receiving a request for a registration certificate from the registration authority application and conditionally transmits the registration certificate to the registration authority application; Perform cryptographic computation requested by a pseudonym certificate authority application, wherein the pseudonym certificate authority application generates a pseudonym certificate in response to receiving a request for a pseudonym certificate from the registration authority application and conditionally transmits the pseudonym certificate to the registration authority application; Perform cryptographic calculations requested by the first linking authority; Performing an encrypted computation requested by a second linking authority application, wherein the first and second linking authority applications generate a link value in response to receiving a request for a link value from the registration and approval authority application and conditionally transmit the link value to the registration and approval authority application; and One or more certificate payloads are distributed to each of a plurality of computerized devices, wherein the one or more certificate payloads indicate the number of pseudonymous certificates to be stored in each computerized device over a period of time, wherein the one or more certificate payloads are allocable such that each computerized device can store multiple pseudonymous certificates different from those of other computerized devices over the period of time. The operation involves one or more load balancers communicatively connected to one or more computing engines, the operation including distributing at least one request to one or more computing engines based on the normality metric of the one or more computing engines.

26. The non-transitory computer-readable medium according to claim 25, wherein, The normal condition measurement includes one or more of the following: the operating temperature of the one or more computing engines, the humidity level inside the chassis 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 the scheduled maintenance event of the one or more computing engines, an indication that the one or more computing engines are running on backup power, or the duration since the last power outage or voltage reduction of the one or more computing engines.

27. The non-transitory computer-readable medium of claim 25, wherein the operation further comprises: Information about certificate activities related to computerized equipment is transmitted to the provisioning controller for storage in a log.

28. The non-transitory computer-readable medium of claim 25, wherein the operation further comprises: The computerized device is authenticated before the application for a registration certificate is transmitted to the registration and approval authority.

29. The non-transitory computer-readable medium of claim 25, wherein the certificate payload may be distributed by the subscriber.

30. The non-transitory computer-readable medium according to claim 25, wherein, The processor is instructed to perform operations, which further include allocating pseudonym certificates for each subscriber and indicating the number of pseudonym certificates available over a period of time.

Images