Secure provisioning and management of devices

Abstract

A system for secure provisioning and management of computerized devices. The system can include a dispenser-type appliance communicatively connected to a computerized device and operable to receive a digital asset and load the digital asset into the computerized device. It can also include a digital asset management system connected to the dispenser-type appliance via a first secure communication channel and operable to generate a digital asset and conditionally transmit the digital asset to the dispenser-type appliance; and a provisioning controller connected to the dispenser-type appliance via a second secure communication channel and to the digital asset management system via a third secure communication channel and operable to direct the digital asset management system to transmit the digital asset to the dispenser-type appliance. The computerized device is not fully operational until the digital asset is loaded into the computerized device.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefits 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; all of which are hereby incorporated by reference in their entirety. Technical Field

[0003] This invention relates to systems, apparatus, and methods for the secure supply of computerized devices. Background Technology

[0004] As computers have become smaller and more commercialized than ever before, manufacturers are producing an increasing variety of devices, including one or more embedded computers or processors. In addition to other functions, the computer in a computerized device can control the operation of the device; collect, store, and share data; communicate with other computers and other computerized devices; and update its own software.

[0005] The Internet of Things (IoT) is a network of computerized physical devices having one or more embedded processors, electronics, software, data, sensors, actuators, and / or network connectivity, enabling these devices to connect and exchange data via digital networks, including the Internet, cellular networks, and other wireless networks. Typically, each "thing" is uniquely identifiable through its embedded computing system and is capable of interoperating within existing Internet infrastructure.

[0006] In the sense of IoT, "things" can refer to a wide variety of computerized devices, including consumer appliances, enterprise equipment used in business and corporate environments, manufacturing machines, farm equipment, energy-consuming devices in homes and buildings (switches, power outlets, light bulbs, televisions, etc.), medical and healthcare devices, infrastructure management equipment, robots, drones, and delivery equipment and vehicles.

[0007] For example, most, if not all, modern vehicles (e.g., cars, trucks, aircraft, trains, watercraft, etc.) include several embedded processors or embedded computers in their subsystems and 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.) include at least one, and often many, embedded processor or embedded computer system and are controlled by computers in at least some respects. These computer-controlled elements of the transportation network typically communicate with each other, passing various types of information back and forth, and they can react, respond, change their operation, or otherwise depend on information received from / to other vehicles and / or infrastructure elements in vehicle-to-vehicle (V2V; also known as C2C, car-to-car) communications and in vehicle-to-infrastructure (V2I, also known as C2I, car-to-infrastructure) communications for safe, correct, efficient, and reliable operation.

[0008] Computers in computerized devices operate according to their software and / or firmware and data. To ensure safe and proper operation, computerized devices must be properly initialized and updated with proper software, firmware, executable instructions, digital certificates (e.g., public key certificates), cryptographic keys, etc. (hereinafter collectively referred to as "digital assets" or "software") as intended by the manufacturer, such that the IoT includes only devices that execute authorized, known good software and data. However, problems arise when unauthorized personnel or organizations (e.g., hackers) replace or alter the software in computerized devices. Problems also arise when older software, untested software, unapproved software, and / or software with known vulnerabilities are installed in computerized devices.

[0009] Accordingly, it is desirable to provide improved systems, methods, and techniques for securely provisioning digital assets in computerized devices in order to prevent computerized devices from operating with software and data that is riddled with errors, does not operate correctly, is untested, is maliciously altered, or otherwise is not desirable. SUMMARY

[0010] Disclosed herein are systems, methods, and apparatus systems for securely provisioning one or more computerized devices. In various implementations, the system includes a first dispenser-type appliance communicatively connected to a computerized device and operable to receive a digital asset and load the digital asset into the computerized device, a digital asset management system connected to the dispenser-type appliance via a first secure communication channel and operable to generate a digital asset and conditionally transmit the digital asset to the dispenser-type appliance, and a provisioning controller connected to the dispenser-type appliance via a second secure communication channel and to the digital asset management system via a third secure communication channel and operable to direct the digital asset management system to transmit the digital asset to the dispenser-type appliance. The computerized device can be non-operational or only partially operational due to a lack of digital assets before the digital asset is loaded into the computerized device. The digital asset can be at least one of a digital certificate, a cryptographic key, and executable software.

[0011] In various implementations, the system can further include a second dispenser-type appliance connected to the digital asset management system via a fourth secure communication channel and communicatively connected to the computerized device after the first dispenser-type appliance is disconnected and operable to receive a second digital asset and load the second digital asset into the computerized device, and the provisioning controller is further operable to direct the digital asset management system to transmit the second digital asset to the dispenser-type appliance. The computerized device can be fully operational after the second digital asset is loaded into the computerized device.

[0012] In various implementations, the digital asset management system can further include one or more virtual machines running a registration authority application and communicatively connected to one or more computation engines that perform cryptographic computations required by the registration authority application, one or more virtual machines running an enrollment certificate authority application and communicatively connected to one or more computation engines that perform cryptographic computations required by the enrollment certificate authority application, one or more virtual machines running a pseudonym certificate authority application and communicatively connected to one or more computation engines that perform cryptographic computations required by the pseudonym certificate authority application, one or more virtual machines running a first linkage authority application and communicatively connected to one or more computation engines that perform cryptographic computations required by the first linkage authority application, and one or more virtual machines running a second linkage authority application and communicatively connected to one or more computation engines that perform cryptographic computations required by the second linkage authority application.

[0013] In other implementations, the digital asset management system can further include a database operatively connected to the one or more virtual machines running the registration entitlement application, the one or more virtual machines running the log-in certificate entitlement, the one or more virtual machines running the anonymous certificate entitlement application, the one or more virtual machines running the first link entitlement application, and the one or more virtual machines running the second link entitlement application.

[0014] In still other implementations, the system can further include a portal operatively connected to the 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 the 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 the provisioning controller and authenticating a regulator of the computerized device and enabling the regulator to regulate provisioning of the computerized device.

[0015] In still other implementations, the provisioning controller can be further operable to transmit a digital asset (e.g., an executable software image) to the distributor appliance for loading into the computerized device. In still other implementations, the provisioning controller can be further operable to create and maintain a log associated with the digital device and storing information related to provisioning activities for the digital device, and the distributor appliance can be further operable to transmit information related to provisioning activities for the digital device to the provisioning controller for storage in the log.

[0016] In still other implementations, the provisioning controller can be further operable to authenticate the digital device prior to directing the digital asset management system to transmit a digital asset. BRIEF DESCRIPTION OF DRAWINGS

[0017] The accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate implementations of the present application and, together with the description, serve to explain the principles of the present application. In the drawings:

[0018] Figure 1 is a block diagram illustrating an example of a system for secure provisioning, consistent with implementations of the present application;

[0019] Figure 2 is a swim lane diagram illustrating an example of a process for securely provisioning a computerized device, consistent with implementations of the present application;

[0020] Figure 3 is a swim lane diagram illustrating another example of a process for securely provisioning a computerized device, consistent with implementations of the present application;

[0021] Figure 4A FIG. 1 is a first portion of a block diagram of an example of a system for implementing a scalable and secure digital asset management system consistent with implementations of the present disclosure;

[0022] Figure 4B FIG. 2 is a second portion of a block diagram of an example of a system for implementing a scalable and secure digital asset management system consistent with implementations of the present disclosure; and

[0023] Figure 5 FIG. 3 is a block diagram of an example of a computing system that can be used to host systems and methods consistent with implementations of the present disclosure. DETAILED DESCRIPTION

[0024] Reference will now be made in detail to various implementations of the present disclosure, examples of which are illustrated in the accompanying drawings. Whenever possible, the same reference numerals will be used throughout the drawings to refer to the same or like parts.

[0025] To ensure safe and proper operation in the field, it is necessary to properly initialize embedded devices used in vehicles, e.g., electronic control units (ECUs), during manufacturing with provisioned digital assets, such as secure assets. Digital assets can include various cryptographic keys, unique identifiers, digital certificates, and software. In most cases, the origin of these digital assets and the manufacturing plant are located in different geographic locations that are conventionally interconnected via insecure Internet communications. It is therefore desirable to create an end-to-end secure channel from the origin of these digital assets to the device so that the digital assets cannot be accessed or modified by a malicious party or accidentally.

[0026] There are deficiencies with traditional network security protocols for end-to-end protection, such as TLS / SSL, because they require pre-existing pre-shared keys or some secret security material at both communicating parties. This creates a circular technical problem because in order to provision digital assets, some initial secret material must pre-exist. This problem includes how to protect the initial secret material. This problem is especially severe for computerized devices because, to simplify logistics, typically a single version of initial software is loaded on computerized devices during manufacturing. If this initial software must contain the initial security material, then this requires the existence of a global secret. Thus, compromising the initial security material would result in compromising all digital assets provisioned on all devices because they all share the same global secret. Systems, methods, and devices consistent with the present disclosure address these and other problems of conventional provisioning systems.

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

[0028] The actions can also include properly installing the device into its operating environment, and testing it to verify that it is functioning properly. The ability to securely provision only devices known to be good is complicated by the fact that the device can be built by one manufacturer, and later installed into a larger system or device by another manufacturer, for example, an On Board Unit (OBU) built by a component manufacturer can be installed into a car built by a car manufacturer. Improperly installed devices can not function properly.

[0029] Various implementations consistent with the invention provide for secure provisioning of computerized devices, including IoT devices. Such implementations serve to prevent or inhibit malicious, negligent, or erroneous tampering, alteration, updating, or release of digital assets used by the computerized devices, and to prevent or inhibit improper installation of the computerized devices and their software.

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

[0031] Various implementations consistent with the invention can also provide a secure provisioning and management platform, which can be offered as a service to device and system manufacturers.

[0032] Figure 1 FIG. 1 is a block diagram illustrating an example of a system 100 for secure provisioning of computerized devices consistent with implementations of the invention. As shown in FIG. 1, the system 100 includes a secure provisioning platform 102, a device manufacturer 104, a device 106, and a system manufacturer 108. Figure 1As shown in the example of FIG. 1, the system 100 includes a provisioning controller 120. The provisioning controller 120 can be implemented as a server computer (e.g., having at least one processor and associated memory) having an embedded hardware security module (HSM) that securely generates and stores digital security assets and securely performs various cryptographic and sensitive computations. The HSM protects digital security assets, such as cryptographic keys and other sensitive data, from possible access by attackers. In various implementations, the provisioning controller 120 functions to authenticate users of the system 100 and securely communicate with users of the system 100; securely communicate with and manage one or more dispenser-type appliances 108, 131; securely communicate with and direct the operation of a digital asset management system (DAMS) 110; create and store provisioning records; create, store, and distribute provisioning records; create, store, and distribute audit logs; create and distribute certificates for cryptographically binding the DAMS 110 with dispenser-type appliance 108, 131 elements; revoke users and managed devices if they stop being trusted, when needed; and create and distribute secure encrypted backups of critical keys and data for offsite storage for business continuity and disaster recovery.

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

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

[0035] Similarly, the supply controller 120 is also communicatively connected to an installer user portal 116, which can be implemented, for example, as a server or as an interface to the supply controller 120. In various implementations, employees 132 of a device installer can use the installer user portal 116 to interface with the supply controller 120 (and thus the DAMS 110) and manage their device installation and supply activities. The supply controller 120 can authenticate the employees 132 before allowing them and assign them a role before allowing them to access the secure supply system 100 and perform authorized functions on the system.

[0036] Similarly, the supply controller 120 is also communicatively connected to the regulator portal 117, which may be implemented, for example, as a server or as an interface to the supply controller 120. In various implementations, the regulator 140, once authenticated by the supply controller 120, can use the regulator portal 117 to interface with the supply 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 supply controller 120 may authenticate the regulator 140 before granting it access to the secure supply system 100. In some implementations of system 100, the regulator 140 and regulator portal 117 are optional.

[0037] The supply controller 120 is also communicatively connected to the DAMS 110. In various implementations, the DAMS 110 can be implemented as a server, device, or security appliance and / or server system. The DAMS 110 securely retrieves public keys from the end-entity device to be supplied via distributor-type devices 108, 131, or other secure and authenticated connections, and securely supplies digital certificates and related data installed in device 106. Additionally, the DAMS 110 securely receives status information related to the supply, installation, functionality, etc., of the computerized device 106 from the manufacturer 105 and installer 130 via distributor-type devices 108, 131. Furthermore, the DAMS 110 can perform this supply at a single site or at multiple sites, such as... Figure 1 As shown. (Regarding...) Figure 4A , 4B In more detail, DAMS 110 may include the following main components: root certificate authority (CA), policy generator, CRL generator, misbehavior authority, intermediate CA, login CA, link authority, anonymous CA, and registration authority.

[0038] The DAMS 110 adds new functionality and improvements upon the components and functionality described in the paper "A Secure Credential Management System for V2V Communications" (William Whyte et al., 2013 IEEE Vehicular Networking Conference, December 2013). In various implementations, the DAMS 110 includes multi-level programming and flexible management (e.g., allowing for inclusion of regulators 140). Various implementations of the DAMS 110 also enable the ability to allow a single DAMS 110 to provide different levels of provisioning to different subscribers. Various implementations of the DAMS 110 also enable the ability to assign different digital certificate usage and different certificate loading during a time period (e.g., weekly, such as one week, rather than three years as in conventional systems). Various implementations of the DAMS 110 can also provide subscriber-specific URLs so that a particular manufacturer's computerized device 106 (e.g., a vehicle of an OEM) can stay within the manufacturer's realm (e.g., its URL shows its name).

[0039] As shown, the provisioning controller 120 is also communicatively connected to the distributor-type appliance 108, 131. In various implementations, the distributor-type appliance 108, 131 can be implemented, among other things, as a standalone secure appliance installed at a company's premises (as shown) or as a web (network) or cloud service. In various implementations, the distributor-type appliance 108, 131 is implemented as a trusted endpoint device that securely transmits and receives digital assets and other information to and from the DAMS 110 and the provisioning controller 120, preferably via a dedicated, non-internet communication channel. As shown, the distributor-type appliance 108, 131 is also connected directly or indirectly with the devices 106A, 106B to download digital assets to the devices 106A, 106B, and to receive data from the devices 106A, 106B. In various implementations, the distributor-type appliance 108, 131 can be implemented as a box that includes a server computer (e.g., having at least one processor and associated memory) with a hardware security module, a hardened operating system (OS), an internal firewall, and an internal host intrusion detection / prevention system. The distributor-type appliance can be specifically designed to operate in an untrusted environment, yet still provide trusted and reliable operation. The distributor-type appliance has a secure communication channel(s) between itself and the secure provisioning controller 120 and the DAMS 110. This channel is used to control the distributor-type appliance, and to send and retrieve provisioning-related data and log information. The distributor-type appliance can also have a secure communication channel to the tester 107, which is used to program or provision the devices 106. This channel protects the provisioning data and log data from being disclosed or modified on the manufacturing location's communication network. The distributor-type appliance 108 can also establish a secure communication channel directly with the device 106 to be programmed, so that the provisioning data cannot be compromised or modified by third parties, including the rogue tester 107. In various implementations, the distributor-type appliance can collect public keys and other data, such as microprocessor serial numbers, from the devices 106 that it provisions. It can send this information to the provisioning controller 120 and / or the DAMS 110. It can also accept data and commands and other information from the provisioning controller 120 and / or the DAMS 110 for programming into the devices 106. It can return its own log data, and it can return data from the tester 107 to the provisioning controller 120 and / or the DAMS 110.

[0040] As shown with respect to device manufacturer 105, distributor-type appliance 108 can be communicatively connected to tester 107 (e.g., computerized manufacturing equipment, product testing equipment, etc.), which in turn is connected to device 106A, which is produced by manufacturer 105, such as an OBU device. Manufacturer 105 can include or can be a factory that manufactures and / or supplies computerized device 106A to the market. As one of many possible examples, computerized device 106A can be an embedded Universal Integrated Circuit Card (eUICC) used in a telecommunication cellular modem, incorporated as part of an On-Board Unit (OBU) later installed in a car, for communication between the car and the transport infrastructure equipment. It can also be a V2V safety microprocessor installed in an OBU, for communication with other vehicles as well as Road Side Units (RSUs). These newly manufactured devices 106A must be properly provisioned with digital assets, such as digital certificate(s) from DAMS 110, in order to properly function. Employees 109 of manufacturer 105 can use user portal 115 to interact with provisioning controller 120 and manage product provisioning activities through DAMS 110.

[0041] As shown with respect to installer 130, distributor-type appliance 131 can alternatively be communicatively connected directly to device 106B as or after it is installed in its operating environment. Installer 130 can include or can be a factory or store that installs computerized device 106B into its operating environment, such as installing an OBU into a car. At installation, computerized device 106A must additionally be properly provisioned with digital assets, such as additional digital certificate(s) from DAMS 110, in order to properly function. Employees 132 of installer 130 can use installer user portal 116 to interact with provisioning controller 120 and manage product provisioning activities through DAMS 110.

[0042] In various implementations, provisioning controller 120, distributor-type appliances 108, 131, and DAMS 110 can have secure, non-publicly accessible communication links or channels between them, and in various embodiments, Figure 1All of the communication links shown in FIG. 1 can be secure, non-publicly accessible communication channels. In various implementations, these secure channels are encrypted and mutually authenticated to prevent unauthorized endpoints from communicating within this secure infrastructure. Multiple security mechanisms can be used to protect these communication channels so that if an outer layer is compromised in some way, the inner layer will remain secure. As an example, a mutually authenticated TLS tunnel can be used as an outer layer with an inner layer by using another protocol such as a proprietary secure communication protocol. These secure connections between the infrastructure components including system 100 are used to protect sensitive communications between the components and to ensure their proper operation. By using these secure paths, provisioning controller 120 and DAMS 110 can send digital data between components without the fear that it will be compromised or modified along the way. Command and control information can also be passed over these channels. For example, provisioning controller 120 can control which distributor appliance 108, 131 certain digital assets and data are sent to. It can also instruct distributor appliance 108, 131 how to meter out that data to devices 106 on the manufacturing line it is provisioning. In addition, distributor appliance 108, 131 can report information back to provisioning controller 120 without the fear that it will be compromised or modified along the way. For example, a secure provisioning controller 120 can program a distributor appliance 108, 131 to provision up to 10,000 devices with any type of digital assets - e.g., certificates, software, converged content, etc. The distributor appliance 108, 131 can count the devices it is provisioning and when it reaches its limit, it will report that to the provisioning controller 120. In various implementations, the devices (e.g., 108, 110, 131, 115, 116, 117) managed by provisioning controller 120 include functionality that causes them to stop operating if they do not communicate regularly with provisioning controller 120; thus, if they are stolen, they become useless. This functionality prevents lost / stolen devices from continuing to function as if they are still in the proper manufacturing environment and for provisioning devices 106.

[0043] With continued reference to Figure 1In operation, in the example shown in FIG. 1, a distributor-type appliance 108 at the manufacturer 105 securely receives digital assets from the DAMS 110 and supplies them to the tester 107 for the device 106A. Since each device 106A is manufactured by the manufacturer 105, the tester 107 communicates with the device 106A to get information from the device 106A, such as its unique identification number and status, and downloads or otherwise installs digital assets into the device, such as digital certificates. The tester 107 can also supply information from the device 106A to the distributor-type appliance 108, which securely communicates the information to the DAMS 110 and / or the provisioning controller 120. In some implementations, the tester 107 can include a software transport layer security (TLS) agent that securely transports data between the distributor-type appliance 108 and the device 106A, which in effect creates a secure, encrypted communication path between the DAMS 110 and the device 106A via the distributor-type appliance 108 and the tester 107, by using a transitory key associated with each device 106A.

[0044] After it is initially provisioned, the manufacturer 105 ships the device 106A to the installer 130, who installs the device 106B. In various implementations, the device 106A is non-operational prior to initial provisioning; and after initial provisioning by the manufacturer 105, the device 106B is not fully operational, although it can be partially operational. In such implementations, initial provisioning causes the device to operate only to the extent needed for installation and further final provisioning, which is needed to make it fully operational.

[0045] The installer 130 installs the device 106B into its operational environment, and a member of staff 132 of the installer 130 notifies the provisioning controller 120 of this fact via the installer portal 116. This notification proves that installation was properly completed, and preferably includes information that uniquely identifies the device 106B to the provisioning controller 120. In some implementations, a distributor-type appliance 131 can automatically notify the provisioning controller 120 after querying the device 106B for status and identification information. In various implementations where the installer 130 proves via the installer portal 116 that he has properly installed the device 106B, this proof can be logged / saved into the database 125 by the provisioning controller 120. The proof can include specific test data related to each particular installed device 106B, such as radio transmission power measurements or GPS antenna position verification.

[0046] In response to the installation notification, the provisioning controller 120 verifies that: (i) the device 106B is listed in its database 125 as a device that was legitimately manufactured by the manufacturer 105, (ii) the device 106B is listed in its database 125 as having been successfully initially provisioned by the manufacturer 105, and (iii) the installer 130 is listed in its database 125 as an authorized installer. If this verification is successful, the controller 120 directs the DAMS 110 to send the digital assets (e.g., a privacy certificate (PC)) and / or other information that are needed to operationally provision the device 106B so that it can properly function when installed in its operating environment.

[0047] In various implementations, the regulator 140, which interacts with the provisioning controller 120 via the regulator portal 117, is used to identify, verify, and manage installers 130 and / or manufacturers 105 so that unauthorized installers (e.g., hackers) cannot obtain trusted digital assets from the system 100. Employee members of the regulator 140 can be authenticated by the provisioning controller 120 and can have unique IDs with the system 100 so that their actions can be uniquely logged. In various implementations, the regulator 140 can use the regulator portal 117 to query the provisioning controller 120 for copies of information and reports that are logged by the controller 120, such as attestation reports, installer actions, numbers and identities of manufactured devices 106A, numbers and identities of installations, fully provisioned devices 106B, and so on.

[0048] In various implementations, the installers 130 must be certified as authorized by the provisioning controller 120 to interact with the system 100. To become authorized, the installers 130 can, for example, have to execute appropriate contractual documents, stating that they will properly install the devices 106B in the target environment (e.g., a target vehicle or site, etc.). The installers 130 can be required to attest to other contractual elements, for example, by the regulator 140. Preferably, each installer 130 has a unique ID within the system 100 so that their actions can be uniquely logged by the provisioning controller 120.

[0049] The described implementations of the system 100 and its functionality ensure that only devices 106 that have been manufactured by the manufacturer 105 and properly installed and tested by authorized installers 130 are fully provisioned with the digital assets that are needed to make the devices 106 function. The provisioning controller 120 produces extensive logs and reports for who took what action at each stage in the provisioning process, providing critical audit capabilities that do not exist in conventional systems.

[0050] Those of ordinary skill will recognize that, in Figure 1The component, process, data, operation, and implementation details shown in the figures are presented as examples for the sake of simplicity and clarity. Other components, processes, implementation details, and variations can be used without departing from the principles of the present invention, as the present examples are not intended to be limiting and many variations are possible. For example, although only one manufacturer 105, only one installer 130, and only one regulator 140 are shown in Figure 1 only one of these entities can have any number. For another example, although DAMS 110 and supply controller 120 are shown as separate devices, other implementations can combine their functionality into a single device, e.g., a single server. As yet another example, the same can be done for portals 115-117. For yet another example, system 100 can additionally include an asset manager appliance (AMA, not shown), as described in U.S. Provisional Application No. 62 / 421,852, filed November 14, 2016, which is incorporated by reference. In such implementations, the AMA can be communicatively connected to supply controller 120 and / or distributor-type appliance 108, 131 and / or DAMS 110. In various implementations, the AMA can include a user-friendly GUI and functionality that allows production coordinators to easily and efficiently manage product (e.g., device 106) configuration and build, and allows asset owners to easily and efficiently manage inventory of digital assets.

[0051] Figure 2 is a swim lane diagram that illustrates an example of a process 200 for securely provisioning computerized devices, consistent with implementations of the present invention. In various implementations, some or all or the operations shown can be performed by code executing on a general-purpose computing system (which can include one or more processors or one or more computing subsystems), by a hardware-only system, or by a system that is a mix of both. As shown across the top of Figure 2 As shown across the top of Figure 1 and throughout this disclosure.

[0052] As Figure 2As shown in the example, process 200 begins at 205, where manufacturer 105 (e.g., employee member 109) requests a digital asset provisioning service from supply controller 130, wherein the digital asset(s) will be supplied to device 106A (e.g., used by device 106A), and wherein the request can identify device 106A as the destination of the digital asset. The request can be, for example, manufacturer 105 requesting a provisioning service for a new product or making a new provisioning service request for an existing product. In various implementations, this operation can involve an authorized user logging into supply controller 130, for example, via user portal 115. In some cases, the requested digital asset can be a security credential, such as a login certificate; executable code that device 106 will run; digital operating parameters; and so on. The login certificate is a public key certificate that identifies its holder as an authorized participant in the ecosystem, where all participants must share a valid login certificate (such as in the USDOT V2X ecosystem), and where authorized participants can also receive anonymous certificates that enable device 106 to communicate and operate within the ecosystem (e.g., enabling communication and operation between vehicles and roadside infrastructure in the example of the USDOT V2X ecosystem).

[0053] At 210, the supply controller 120 determines whether the user from manufacturer 109 is an authorized user. In some implementations, the supply controller 120 may also determine at 210 whether the equipment 106A (e.g., a product) to be supplied is approved for use by system 100. In some instances, the list of approved equipment may be generated by... Figure 1 The regulator 140 provides the information, and the supply controller 120 uses it to make the determination.

[0054] If the user (and / or product) is unauthorized, the supply controller 120 rejects the request for a digital asset supply service (not in accordance with...). Figure 2 (as shown in the diagram). If, on the other hand, an authorized user is making a request (e.g., for an authorized product) (210, yes), then the supply controller 120 directs, instructs, or otherwise controls the DAMS 110 to fulfill the service request, for example by transmitting the service request instruction to the DAMS 110 (at 215).

[0055] At 220, in response to receiving a request from 215 and on the condition that the request was received from 215, DAMS 110 configures itself to begin servicing device 106A based on the request. In some implementations, DAMS 110 may also send (not shown) instructions to distributor-type appliance 108 for configuring distributor-type appliance 108 to serve device 106A.

[0056] At 222, the DAMS 110 generates, creates, computes, and / or retrieves the digital assets for the device 106A, as requested at 205. In various implementations, the DAMS 110 can create or generate the requested digital security asset(s), such as public and private key pairs, as well as login and anonymous certificate(s) for the device 106A.

[0057] In alternative implementations of operation 222 (not shown in FIG. 2), the DAMS 110 requests and receives digital asset generation information associated with the device 106A from the distributor-type appliance 108, such as login and anonymous public keys generated by and retrieved from the device 106A, as well as data uniquely identifying the device 106A (e.g., microprocessor serial number). In such implementations, the DAMS 110 then uses the login and anonymous public keys to generate the digital assets - e.g., a login certificate for the device 106A and an appropriate number of anonymous certificates. Figure 2

[0058] At 225, the DAMS 110 transmits the digital assets to the distributor-type appliance 108 of the manufacturer 105, which requested the digital asset service at 205. For example, the DAMS 110 can securely transmit the public and private key pairs, login certificate, and anonymous certificates to the distributor-type appliance 108 of the manufacturer 105.

[0059] At 226, the DAMS 110 transmits log information related to the digital assets to the provisioning controller 120. In various implementations, the log information can include information describing the request and delivery of the digital assets, such as the ID of the requester, the ID of the digital assets, the ID of the distributor-type appliance, a timestamp of the request and transmission action, the received microprocessor serial number, and the like. In some implementations, the log information can include a copy of the digital assets. At 227, the provisioning controller 120 receives the log information and stores it, for example, in the database 125. The provisioning controller 120 effectively maintains an audit trail of all activity occurring in the system 100, which allows for the compilation of many types of data, such as data related to how a device 106A can be constructed and how and when it can be provisioned by the manufacturer 105. Such data and log information can be used for accounting and auditing purposes.

[0060] At 230, the distributor-type appliance 108 receives and stores the digital assets (e.g., public and private key pairs, login certificate, and anonymous certificates) sent by the DAMS 110.

[0061] ​At 235, the dispenser-type appliance 108 requests and receives a digital security asset, such as a public key, from the device 106A that can be used to securely transfer digital assets from the dispenser-type appliance 108 to the device 106A. Various types of devices 106A have the ability to generate ephemeral key pairs, perhaps through the use of a secure processor built into the device 106, and the public key can be part of the ephemeral key pair. At 240, the dispenser-type appliance 108 uses the digital security asset (e.g., public key) to securely transfer digital assets (e.g., login credentials) to the device 106A. In various implementations, the dispenser-type appliance 108 can use the public key of the device 106A to form, for example, a virtual private network (VPN) with the device 106A, and securely transfer digital assets therein.

[0062] In various implementations, the dispenser-type appliance 108 can employ transport layer security (TLS) between it and the tester 107 for secure communication with the tester 107, which can be connected to the device 106A. In implementations where it is desirable to have secure communication directly with the device 106A, the system can create an ephemeral public key pair on the device 106A and create a secure tunnel to the device 106A by using the public key along with a certificate from the dispenser-type appliance 108 containing the public key of the dispenser-type appliance 108. In such implementations, the device 106A will run special code - the special code having the root public key of the system 100 therein - for verifying the certificate sent to it by the dispenser-type appliance 108.

[0063] Once a secure path is established between the device 106A or tester 107 and the dispenser-type appliance 108, the device 106A can then create a login and anonymous public key pair (e.g., for a V2X ecosystem) and export the public keys and other data to the dispenser-type appliance 108, and the dispenser-type appliance 108 can then send this data to the DAMS 110 and provisioning controller 120. As described above with respect to the alternative implementation of operation 222, the DAMS 110 can use the received public keys to create a login credential and anonymous credential(s) - in some implementations, there can be a large number (e.g., 3000) of anonymous credentials. In this alternative example of an implementation, at operation 225, the DAMS 110 will return the credential(s) to the dispenser-type appliance 108, as previously described. In some other implementations, depending on where the provisioning is performed, the DAMS 110 can transfer the credentials to the dispenser-type appliance 131, instead of 108.

[0064] In some implementations, the distributor-type appliance 108 can communicate directly with the device 106, e.g., if the device 106 has its own wireless or wired communication functionality and is at least partially operational. In other implementations, the distributor-type appliance 108 can communicate indirectly with the device 106 via an intermediary device, such as the tester 107.

[0065] The device 106A receives the digital asset and stores it for use during operation. For example, if the device 106A is an on-board unit (OBU) or electronic control unit (ECU) for a car, and the digital asset is a security asset (e.g., a public key certificate) needed to join a wireless network, the digital security asset is stored by the OBU. When the OBU is later installed in the car and activated, 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 will only be able to authenticate and join the network if it has the digital security asset provided by the distributor-type appliance 108 at the manufacturer 105.

[0066] At 245, the distributor-type appliance 108 receives or accesses status information from the device 106A, indicating whether the device 106A successfully received and installed (e.g., stored) the digital asset transmitted at 240.

[0067] At 250, the distributor-type appliance 108 transmits the status information to the provisioning controller 120. And at 255, the provisioning controller 120 receives and stores the status information in association with the log information stored in operation 227. Thus, the provisioning controller 120 continues the audit trail or audit log for all system 100 activity associated with each particular device 106. In various implementations, the audit log can contain information for each device 106 indicating: success or failure of the manufacturer's provisioning (e.g., operations 235-245); identity of the digital asset (and / or copy of the digital asset itself); type of password; etc.

[0068] At 270, if the device 106A is successfully provisioned with the digital asset, the manufacturer 105 releases the device to the market. For example, the manufacturer 105 can physically ship the device 106A to a company that installs the device in its operating environment (e.g., the installer company 130). In some implementations, the device 106A can be fully programmed or provisioned at this point in time and be able to operate with full functionality; while in other implementations, the device 106A can be only partially programmed or provisioned at this point and not be able to operate with full functionality or be non-operational. Figure 1

[0069] Figure 2 ​The example depicted in FIG. 2 is merely for illustrative purposes and is not intended to be limiting. Moreover, the depicted process 200 is an example that has been slightly simplified for clarity of explanation of certain novel and inventive features consistent with certain disclosed implementations, but the example is not intended to be limiting and many variations are possible. For example, while functions and operations are shown as being performed in a particular order, the order described is merely an example and various different sequences of operations can be performed consistent with certain disclosed implementations. Moreover, the operations are described as discrete steps merely for illustrative purposes and in some implementations multiple operations can be performed simultaneously, and / or as part of a single computation or larger operation. The operations are not intended to be exhaustive, limiting or absolute, and various operations can be modified, inserted or removed. As an example, while generally described in the context of a single digital asset (e.g., a single digital certificate), the system and process would similarly function to handle multiple digital assets (e.g., two or more digital certificates). For another example, in the case where the device 106A does not have secure communication capabilities, operations 235 and 240 can be removed and the distributor-type appliance 108 can communicate with the device 106B by using unencrypted communications. Figure 2 However, the system and process would similarly function to handle multiple digital assets (e.g., two or more digital certificates). For another example, in the case where the device 106A does not have secure communication capabilities, operations 235 and 240 can be removed and the distributor-type appliance 108 can communicate with the device 106B by using unencrypted communications.

[0070] For yet another example, in various implementations, the provisioning controller 120 or an agent authority, such as a specialized signing appliance, can similarly transmit to the distributor-type appliance 108 and cause it to load another or additional digital assets into the device 106B, including digital assets such as software, firmware, fuse blobs, manifest files, and the like. In such implementations, the provisioning controller 120 can additionally or alternatively retrieve, obtain, or otherwise access, or directly access, the requested digital assets from a storage device. For example (not shown in FIG. 2), the provisioning controller 120 or its authorized agent can retrieve an executable software image (e.g., a compiled computer program stored in the database 125) to be loaded into and run by the device 106A, and send the executable software image to the distributor-type appliance 108 for programming into the device. In various implementations, the digital assets accessed by the provisioning controller 120 can include only software and the like that is securely supplied, released, and / or authorized by the manufacturer 105 of the device 106A, such that no unauthorized software can be loaded into the device 106A. In some implementations, the digital assets retrieved by the provisioning controller 120 can be stored in a storage device or database associated with the provisioning controller 120, such as the database 125 of FIG. 1. Figure 2 Figure 1

[0071] ​​Figure 3 is a swimlane diagram that illustrates an example of a process 200 for securely provisioning computerized devices, consistent with implementations of the present invention. In various implementations, some or all of the operations of the process 300, or those shown, can be performed by code executing on a general-purpose computing system (which can include one or more processors or one or more computing subsystems), by a hardware-only system, or by a system that is a hybrid of the two. As indicated across the top of the figure, the entities involved in the case of the process 300 include an installer 130 of a computerized device 106, a distributor-type appliance 131 located at the installer 130, a provisioning controller 120, and a DAMS 110. In various implementations, these entities can and do communicate with one another, as described with respect to Figure 3 and throughout this disclosure. Figure 1 and throughout this disclosure.

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

[0073] In some implementations, the device 106B can be only partially provisioned and not fully commissioned. For example, the manufacturer 105 of the device 106B can have provisioned the device 106B with only an enrollment certificate, such that the device 106B will need to be further provisioned with another digital certificate, such as an anonymous certificate, in order to obtain full functionality, e.g., functionality for communicating with another fully programmed device 106.

[0074] At 315, the installer 130 (e.g., employee member 132) transmits installation status data to the provisioning controller 120. In various implementations, the installation status data includes an immutable identifier of the device being installed, e.g., a serial number, or other fixed, uniquely identifying information such as a public key from a key pair that is generated once and never erased. The installation status data can also include other information such as a unique identifier of the installer 130, information indicating how and when the device 106B was installed, information related to the results of testing conducted on the installed device 106B, information attesting that the installer 130 installed the device 106B in accordance with applicable specifications, contractual requirements, and or instructions, and / or other similar information.

[0075] At 320, the provisioning controller 120 determines whether the user from the installer 130 is an authorized user. If not, the provisioning controller 120 rejects the installation status communication (not shown in Figure 3 FIG. 3). If, on the other hand, an authorized user is making the 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 implementations, the provisioning controller 120 can determine that the device 106B is authorized by verifying that its database 125 has the following in its database 125 by comparing against previously stored information: 1) a record for the device 106B exists; 2) the record indicates that the device 106B was successfully provisioned at the manufacturer 105; 3) the record indicates that the device 106B was sent to the installer 130 (which was verified as an authorized installer in 320).

[0076] If the device identified in the installation status data is not authorized, the provisioning controller 120 rejects the installation status communication (not shown in Figure 3 FIG. 3). If, on the other hand, the device 106B identified in the installation status data is authorized (325, YES), the provisioning controller 120 stores the installation status data with the log information associated with the device 106B at 330. For example, the log information associated with the device 106B can have been previously stored in the database 125 as described with respect to operation 227 of Figure 2 FIG. 2.

[0077] At 335, provisioning controller 120 directs, instructs, or otherwise controls DAMS 110 to fulfill the provisioning request, e.g., by transmitting a request to DAMS 110 for a digital asset for provisioning device 106B, which is at installer 130. At 340, in response to receiving the request from 335 and on the condition that the request is received from 335, DAMS 110 generates and / or retrieves the digital asset requested at 335. In various implementations, DAMS 110 can create or generate the requested digital asset, such as an anonymous certificate or other public key certificate, as described with respect to Figure 2 DAMS 110 or provisioning controller 120, instead of DAMS 110, can additionally or alternatively retrieve, obtain, or otherwise access the requested digital asset from storage, such as an executable image previously stored in database 125 for use in devices of the type of device 106B.

[0078] At 345, DAMS 110 transmits the digital asset to distributor-type appliance 131 of installer 130, which transmitted the installation status at 315. For example, DAMS 110 can securely transmit the anonymous certificate to distributor-type appliance 131 of installer 130.

[0079] At 350, distributor-type appliance 131 performs the same or similar operations as operations 230-245, as explained with respect to Figure 2 At 355, distributor-type appliance 131 transmits status information to provisioning controller 120. And at 360, provisioning controller 120 receives and stores the status information in association with previously stored information about device 106B, such as the status information stored in operation 227. Thus, provisioning controller 120 continues the audit trail or audit log for all system 100 activity associated with each particular device 106.

[0080] Figure 3The process 300 depicted in the middle is an example for illustration purposes and is not intended to be limiting. Moreover, the depicted process 300 is an example that has been slightly simplified for clarity of explanation of certain novel and inventive features consistent with certain disclosed implementations, but numerous variations are possible. For example, while functions and operations are shown as being performed in a particular order, the order shown is merely an example and various different sequences of performing the operations can be performed consistent with certain disclosed implementations. Moreover, the operations are described as discrete steps for illustrative purposes only and in some implementations multiple operations can be performed simultaneously, and / or as part of a single computation or larger operation. The operations are not intended to be exhaustive, limiting, or absolute, and various operations can be modified, inserted, or removed.

[0081] Figure 4A and 4B together are a block diagram of an example of a system 400 for implementing a scalable and secure digital asset management system in accordance with implementations of the present application. Various implementations of the system 400 can be used for very high volume device transactions as well as certificate generation processing. In various implementations, the system 400 can be implemented using multiple servers, hardware security modules, multiple computing or computing engines, and multiple virtual machines (VMs). Examples of the system 400 can be implemented in a private data center, a cloud data center such as AWS, or a hybrid of private and cloud data centers.

[0082] In various implementations, the system 400 can be, can be part of, or can interact with a digital asset management system (DAMS) 110 that can operate as described with respect to Figure 1 and other sections of the present disclosure.

[0083] As shown in the example of Figure 4A The architecture can include two provisioning controllers 120 - primary and backup, which are preferably implemented in separate servers. The two provisioning controllers 120 include functionality such that objects, data, etc. contained in the primary provisioning controller are copied or otherwise contained in the backup (secondary) provisioning controller. If the primary provisioning controller becomes offline for any reason, the backup provisioning controller can be purchased online to replace the primary provisioning controller. This provides continuous (or very high) availability of the provisioning controller 120. In various implementations, the primary and backup provisioning controllers can operate as described with respect to Figure 1 and other sections of the present disclosure. In various implementations, the provisioning controller 120 can be used as described herein with respect to theFigure 1 The supply controller 120 is connected to the system 400 in the same or similar manner as the connection and communication between the DAMS 110 and the supply controller 120 described. Generally, the supply controller 120 manages the system elements, including the infrastructure, so that only explicitly authorized elements can participate and interact with the system 400. In various implementations, the supply controller 120 can integrate with a user's (e.g., the manufacturer 105 or the installer 130) employee identification and authorization system, or it can provide its own capability for identification and authorization so that only authorized users can use the system 400.

[0084] The architecture of the system 400 separates non-security related applications from security functions. As shown in this example, the enrollment authority 420, the certificate authority 430, 440, and the linking authority 450, 460 are implemented as applications on their own virtual machines, which execute on their own dedicated computing engines 425, 435, 445, 555, 465, all of which are separated from any non-security related applications and functions. This provides both technical and security advantages and improvements over conventional systems, where the performance of hardware security modules is slow, or where a cloud service provider cannot supply HSMs, or where their proper management of HSMs is uncertain. By separating key security functions from each other and onto separate computing engines, as shown in Figure 4A , 4B The computationally intensive cryptographic and security functions (e.g., elliptic curve butterfly expansion calculations or elliptic curve digital signatures) performed, for example, by the enrollment authority 420, the certificate authority 430, 440, and the linking authority 450, 460 are performed significantly faster than existing enrollment authority systems, as shown in the middle. This design enables significant improvements in transaction processing by enabling the "bottleneck" applications to be scaled as needed. For example, if the enrollment authority application running on 405 and 420 needs to be scaled, additional VMs can be added, without any changes needed in the secure computing capabilities at 425. Alternatively, if the secure computing is the limiting performance, additional secure computing engines 425 can be added. The same multi-dimensional scaling is true for the other components of 400. This capability provides significant performance improvements over other existing SCMS systems.

[0085] In various implementations, the registration authority 405 can be an authority in a provisioning network that validates user requests for digital certificates, or other types of digital security assets, and enables certificate authorities (e.g., certificate authorities 430, 440) to issue digital certificates. In various implementations, the registration authority 405 can be similar to a registration authority known in a public key infrastructure (PKI) system. In various implementations, the registration authority 405 can be implemented as a representative state transfer (REST) web service. As indicated by the three "stacked" rectangles shown for the registration authority 405 in Figure 4A In various implementations, there can be multiple instances of the registration authority 405 that are concurrently executing, as indicated by the three "stacked" rectangles shown for the registration authority 405 in Figure 4A , 4B Other "stacked" elements for the

[0086] As indicated by the "DB" arrow in the lower left of the rectangle, the registration authority 405 (and other components of the Figure 4A , 4B indicated by the "DB" arrow) can be connected to a database 470. In preferred implementations, the database 470 is a fast access, low latency database. In some implementations, the database 470 can be a NoSQL database or database service, such as the DynamoDB data service provided by Amazon web services. In various implementations, the data stored in the database 470 is application dependent, but can include past issued certificates, various linked authority values, data on devices to which certificates have been issued, operator actions, and so forth. Note that the data can be stored either unencrypted, encrypted, or some combination thereof.

[0087] In the example shown in Figure 4A , the registration authority 405 is connected to other components, and the other components are connected to each other, through a messaging subsystem or service, which is represented by block 410. In some implementations, the messaging service 410 can be a fast message queuing service, such as the Amazon Simple Queue Service (SQS) provided by Amazon web services.

[0088] In various implementations, the system 400 includes a logged-in certificate authority 430 and an anonymous certificate authority 440, as the digital certificates produced by the registration authority 405 are split into different segments - e.g., logged-in digital certificates and anonymous digital certificates.

[0089] In various implementations, the linking authorities 450, 460 link the identity of the certificate requestor (i.e., the unique identifier of the certificate requestor's device) to the issued anonymous certificate for revocation purposes.

[0090] In various implementations, the computing engines 425, 435, 445, 455, and 465 and the provisioning controller 120 include HSMs that allow these components to perform secure computations without being unduly threatened by hackers. In some implementations, the computing engines 425, 435, 445, 455, and 465 can be designed to perform secure computations themselves, and in such implementations, no embedded HSM is needed, they embody the HSM.

[0091] Those of ordinary skill will recognize that the component, process, data, operation, and implementation details set forth in the Figure 4A , 4B illustrated in FIGS. 1-4 are examples for the sake of simplification and clarity. Other components, processes, implementation details, and variations can be used without departing on the principles of the disclosure, as the examples are not intended to be limiting and many variations are possible.

[0092] Figure 5 is a block diagram of an example of a computing environment 501 that includes a computing system 500 that can be used to implement systems and methods consistent with implementations of the present disclosure. Other components and / or arrangements can also be used. In some implementations, the computing system 500 can be used to implement, at least in part, various components of Figures 1-3 , among others, such as the provisioning controller 120 and the DAMS 110. In some implementations, a series of computing systems similar to the computing system 500 can each be customized with specialized hardware and / or programmed as specialized servers to implement one of the components of Figures 1-3 , which can communicate with each other via the network 535.

[0093] In Figure 5In the example shown, computing system 500 includes multiple components such as a central processing unit (CPU) 505, memory 510, one or more input / output (I / O) devices 525, a hardware security module (HSM) 540, and non-volatile storage device 520. System 500 can be implemented in various ways. For example, an implementation as an integrated platform (such as a server, workstation, personal computer, laptop, etc.) may include CPU 505, memory 510, non-volatile storage device 520, and I / O devices 525. In this configuration, components 505, 510, 520, and 525 can be connected and communicate via a local data bus and can access a data repository 530 (which is, for example, implemented as a separate database system) via external I / O connections. One or more I / O components 525 can be connected to external devices via a direct communication link (e.g., hardwired or local Wi-Fi connection), via a network, such as a local area network (LAN) or a wide area network (WAN, such as a cellular telephone network or the Internet), and / or via other suitable connections. System 500 can be standalone, or it can be a subsystem of a larger system.

[0094] CPU 505 can be one or more known processors or processing devices, such as those manufactured by Intel in Santa Clara, CA. TM The company manufactures products from Core TM The family of microprocessors, or those manufactured by AMD in Sunnyvale, CA. TM The company manufactures products from Athlon. TM The microprocessor 510 may be one or more fast storage devices configured to store instructions and information executed or used by the CPU 505 to perform certain functions, methods, and processes related to the implementation of the present invention. Storage device 520 may be a volatile or non-volatile magnetic, semiconductor, tape, optical, or other type of storage device or computer-readable medium, including devices intended for long-term storage, such as CDs and DVDs, and solid-state devices.

[0095] In the illustrated implementation, memory 510 contains one or more programs or applications 515 loaded from storage device 520 or from a remote system (not shown), which, when executed by CPU 505, perform various operations, processes, procedures, or methods consistent with the present invention. Alternatively, CPU 505 may execute one or more programs located remotely from system 500. For example, system 500 may access one or more remote programs via network 535, which, when executed, perform functions and procedures related to the implementation of the present invention.

[0096] In one implementation, the memory 510 can include program(s) 515 for executing specialized functions and operations described herein for the provisioning controller 120, the DAMS 110, and / or the dispenser-type appliance 108, 131. In some implementations, the memory 510 can also include other programs or applications that implement other methods and processes that provide ancillary functionality to the present application.

[0097] The memory 510 can also be configured with other programs (not shown) unrelated to the present application and / or an operating system (not shown) that performs several functions well known in the art when executed by the CPU 505. By way of example, the operating system can be the Microsoft Windows TM , Unix TM , Linux TM , Apple Computers TM OS or other operating system. The selection of the operating system, and even the selection of the operating system used, is not critical to the present application.

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

[0099] The I / O device(s) 525 can include one or more input / output devices that allow data to be received and / or transmitted through the system 500. For example, the I / O devices 525 can include one or more input devices, such as a keyboard, a touchscreen, a mouse, etc., that enable data to be input from a user. In addition, the I / O devices 525 can include one or more output devices, such as a display screen, a CRT monitor, an LCD monitor, a plasma display, a printer, a speaker device, etc., that enable data to be output or presented to a user. The I / O devices 525 can also include one or more digital and / or analog communication input / output devices that allow the computing system 500 to communicate, for example, digitally, with other machines and devices. Other configurations and / or numbers of input and / or output devices can be incorporated in the I / O devices 525.

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

[0101] In Figure 5 the illustrated example implementation, data source 530 is a separate database external to system 500, such as database 125. In other implementations, data source 530 can be hosted by system 500. In various implementations, data source 530 can manage and store data used to implement systems and methods consistent with the present invention. For example, data source 530 can manage and store data structures containing state and log information for each device 106 provisioned by system 100, among other things.

[0102] Data source 530 can include one or more databases that store information and are accessed and / or managed by system 500. As an example, database 530 can be an Oracle TM database, a Sybase TM database, or other relational database. However, systems and methods consistent with the present invention are not limited to separate data structures or databases, or even the use of databases or data structures.

[0103] Those of ordinary skill will recognize that the components and implementation details of the systems in Figure 5 are presented as examples for the sake of simplicity and clarity of explanation. Other components and implementation details can be used.

[0104] While the foregoing examples use, for the sake of clarity of explanation, specific examples of computerized devices, such as OBUs, ECUs, and RSUs, the present invention is not limited to those specific examples. Various implementations consistent with the present invention can be used with and for a wide variety of computerized devices, such as medical devices (e.g., dialysis machines, infusion pumps, and the like); robots; drones; autonomous vehicles; and wireless communication modules (e.g., embedded Universal Integrated Circuit Card (eUICC)), among others.

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

Claims

1. A system for securely provisioning a computerized device, the system comprising: a first secure-distributor-type computer communicatively connected to the computerized device and receiving and transmitting a first digital asset to the computerized device, wherein the first digital asset is configured to enable the computerized device to become partially operational; a digital asset management server connected to the first secure-distributor-type computer via a first secure communication channel and transmitting the first digital asset to the first secure-distributor-type computer; a provisioning controller connected to the first secure-distributor-type computer via a second secure communication channel and connected to the digital asset management server via a third secure communication channel and directing the digital asset management server to transmit the first digital asset to the first secure-distributor-type computer; and a second secure-distributor-type computer connected to the digital asset management server via a fourth secure communication channel and communicatively connected to the computerized device after the first secure-distributor-type computer is disconnected from the computerized device and receiving and transmitting a second digital asset to the computerized device, wherein the second digital asset is configured to enable the computerized device to become fully operational; wherein the provisioning controller further directs the digital asset management server to transmit the second digital asset to the second secure-distributor-type computer; wherein the computerized device becomes fully operational after the second digital asset is transmitted to the computerized device.

2. The system of claim 1, further comprising: a first portal for the provisioning controller to authenticate a manufacturer of the computerized device and enable the manufacturer to manage provisioning of the computerized device.

3. The system of claim 1, further comprising: a second portal for the provisioning controller to authenticate an installer of the computerized device.

4. The system of claim 1, further comprising: a third portal for the provisioning controller to authenticate a regulator of the computerized device and enable the regulator to regulate provisioning of the computerized device.

5. The system of claim 1, wherein the provisioning controller transmits a third digital asset to the first secure-distributor-type computer or the second secure-distributor-type computer for transmission to the computerized device.

6. The system of claim 5, wherein the third digital asset is executable code to be run by the computerized device.

7. The system of claim 1, wherein the second digital asset is at least one of: a digital certificate, a cryptographic key, and executable software.

8. The system of claim 1, wherein the provisioning controller creates and maintains a log associated with the computerized device and stores information related to provisioning activities for the computerized device.

9. The system of claim 8, wherein the first secure-distributor-type computer transmits information related to provisioning activities for the computerized device to the provisioning controller for storage in the log. ​ 10. The system of claim 1, wherein the provisioning controller authenticates the computerized device prior to the digital asset being transmitted to the computerized device.

11. The system of claim 1, wherein the computerized device is an embedded universal integrated circuit card.

12. The system of claim 1, wherein the computerized device is an in-vehicle unit.

13. The system of claim 1, wherein the digital asset management server comprises a plurality of servers.

14. The system of claim 1, wherein the digital asset management server is a secure credential management system.

15. A method for securely provisioning a computerized device, the method comprising: generating, by a provisioning controller, a first instruction to instruct a digital asset management server to transmit a first digital asset to a first secure-distributor-type computer; transmitting, from the digital asset management server to the first secure-distributor-type computer, the first digital asset in response to the first instruction; transmitting, from the first secure-distributor-type computer to the computerized device, the first digital asset, wherein the first digital asset is configured to cause the computerized device to become partially operational; generating, by the provisioning controller, a second instruction to instruct the digital asset management server to transmit a second digital asset to a second secure-distributor-type computer after the second secure-distributor-type computer is connected to the computerized device; transmitting, from the digital asset management server to the second secure-distributor-type computer, the second digital asset in response to the second instruction; and transmitting, from the second secure-distributor-type computer to the computerized device, the second digital asset, wherein the second digital asset is configured to cause the computerized device to become fully operational; wherein the computerized device is fully operational after the second digital asset is transmitted to the computerized device; wherein: the first secure-distributor-type computer is communicatively connected to the computerized device; the digital asset management server is connected to the first secure-distributor-type computer via a first secure communication channel; the provisioning controller is connected to the first secure-distributor-type computer via a second secure communication channel and to the digital asset management server via a third secure communication channel, and the second secure-distributor-type computer is connected to the digital asset management server via a fourth secure communication channel and is communicatively connected to the computerized device after the first secure-distributor-type computer is disconnected from the computerized device.

16. The method of claim 15, wherein transmitting, from the digital asset management server to the first secure-distributor-type computer, the first digital asset comprises transmitting at least one of: a digital certificate, a cryptographic key, and an executable code to be run by the computerized device.

17. The method of claim 15, wherein transmitting, from the digital asset management server to the second secure-distributor-type computer, the second digital asset comprises transmitting at least one of: a digital certificate, a cryptographic key, and an executable code to be run by the computerized device.

18. A system for securely provisioning a computerized device, the system comprising: a first secure distributor-type computer communicatively connected to the computerized device and receiving and transmitting a first digital asset to the computerized device, wherein the first digital asset is configured to cause the computerized device to become partially operational; a provisioning controller connected to the first secure distributor-type computer via a second secure communication channel and transmitting the first digital asset to the first secure distributor-type computer; and a second secure distributor-type computer connected to the provisioning controller via the second secure communication channel and communicatively connected to the computerized device after the first secure distributor-type computer is disconnected from the computerized device, and receiving and transmitting a second digital asset to the computerized device, wherein the second digital asset is configured to cause the computerized device to become fully operational; wherein the provisioning controller transmits the second digital asset to the second secure distributor-type computer; and wherein the computerized device becomes fully operational after the second digital asset is transmitted to the computerized device.

19. The system of claim 18, wherein the first digital asset is at least one of: an executable code to be run by the computerized device and a digital certificate.

20. The system of claim 18, wherein the second digital asset is at least one of: a digital certificate, a cryptographic key, and an executable code.

21. The system of claim 18, wherein the provisioning controller creates and maintains a log associated with the computerized device and stores information related to provisioning activities for the computerized device.

22. The system of claim 21, wherein the first secure distributor-type computer transmits information related to provisioning activities for the computerized device to the provisioning controller for storage in the log.

23. The system of claim 18, wherein the provisioning controller authenticates the computerized device prior to the digital asset being transmitted to the computerized device.

24. The system of claim 18, wherein the computerized device is an embedded universal integrated circuit card.

25. The system of claim 18, wherein the computerized device is an in-vehicle unit.

26. The system of claim 18, further comprising: a digital asset management server connected to the first secure distributor-type computer via a third secure communication channel, to the provisioning controller via a fourth secure communication channel, and to the second secure distributor-type computer via a fifth secure communication channel; wherein the digital asset management server transmits a third digital asset to the first secure distributor-type computer or the second secure distributor-type computer for transmission to the computerized device.

27. The system of claim 26, wherein the digital asset management server is a secure credential management system.

28. A method for provisioning a computerized device, the method comprising: transmitting, by a provisioning controller, a first digital asset to a first secure distributor-type computer; transmitting a first digital asset from the first secure-distributor-type computer to the computerized device, wherein the first digital asset is configured to cause the computerized device to become partially operational; transmitting a second digital asset to the second secure-distributor-type computer after the second secure-distributor-type computer connects to the computerized device by the provisioning controller; and transmitting a second digital asset from the second secure-distributor-type computer to the computerized device, wherein the second digital asset is configured to cause the computerized device to become fully operational; wherein the computerized device is fully operational after the second digital asset is transmitted to the computerized device; wherein: the first secure-distributor-type computer is communicatively connected to the computerized device; the provisioning controller is connected to the first secure-distributor-type computer via a first secure communication channel, and the second secure-distributor-type computer is connected to the provisioning controller via a second secure communication channel and is communicatively connected to the computerized device after the first secure-distributor-type computer is disconnected from the computerized device.

29. The method of claim 28, wherein transmitting the first digital asset to the first secure-distributor-type computer by the provisioning controller comprises transmitting at least one of: a digital certificate, a cryptographic key, and an executable code to be executed by the computerized device.

30. The method of claim 28, wherein transmitting the second digital asset to the second secure-distributor-type computer after the second secure-distributor-type computer connects to the computerized device by the provisioning controller comprises transmitting at least one of: a digital certificate, a cryptographic key, and an executable code to be executed by the computerized device.

Images