Patent Description:
As computers have become ever more miniaturized and commoditized, manufacturers are producing more and more varied devices that include one or more embedded computer or processor. The computer in a computerized device can control the device's operation; collect, store, and share data; communicate with other computers and other computerized devices; and update its own software, among other things.

The Internet of things (IoT) is the network of computerized physical devices that have embedded processor(s), electronics, software, data, sensors, actuators, and/or network connectivity, which enable 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 able to inter-operate within the existing Internet infrastructure.

"Things", in the loT sense, can refer to a wide variety of computerized devices, such as consumer appliances, enterprise devices used in business and corporate settings, manufacturing machines, farming equipment, energy-consuming devices in homes and buildings (switches, power outlets, bulbs, televisions, etc.), medical and healthcare devices, infrastructure management devices, robots, drones, and transportation devices and vehicles, among many others.

For example, most, if not all, modern vehicles (e.g., cars, trucks, aircraft, trains, watercraft, and the like) contain several embedded processors or embedded computers in their subsystems, and are computer-controlled in at least some aspects. Similarly, a growing number of modern transportation infrastructure devices (e.g., traffic lights, traffic cameras, traffic sensors, bridge monitors, bridge control systems, and the like) contain at least one, and often many, embedded processors or embedded computer systems, and are computer-controlled in at least some aspects. These computer-controlled elements of the transportation network typically communicate with each other, passing various types of information back and forth, and they may react, respond, change their operation, or otherwise depend upon the information received/sent from/to other vehicles in Vehicle-to-Vehicle (V2V; also known as C2C, Car-to-Car) communications and/or from/to infrastructure elements in Vehicle-to-Infrastructure (V2I, also known as C2I, Car-to-Infrastructure) communications for safe, correct, efficient, and reliable operation.

The computers in computerized devices operate according to their software and/or firmware and data. In order to ensure safe and proper operation, the computerized devices must be properly initialized and updated with the proper software, firmware, executable instructions, digital certificates (e.g., public key certificates), cryptographic keys and the like (hereinafter collectively referred to as "digital assets" or "software") as intended by the manufacturer, so that the loT consists only of devices that are executing authorized, known-to-be-good software and data. Problems arise, however, when unauthorized persons or organizations (e.g., hackers) replace or change the software in computerized devices. Problems also arise when older software, untested software, unapproved software, and/or software with known bugs is installed in computerized devices.

Accordingly, it is desirable to provide improved systems, methods and techniques for securely provisioning the digital assets in computerized devices, so as to prevent the computerized devices from operating using error-ridden, incorrectly functioning, untested, maliciously altered, or otherwise undesirable software and data.

Patent literature <CIT>, <CIT>, <CIT> and <CIT> is considered relevant prior art.

Advantageous features are described in the dependent claims. Disclosed herein are systems, methods and devices system for securely provisioning one or more computerized devices In various implementations, the system includes a first distributor appliance that is communicatively connected to the computerized device, and that is operable to receive a digital asset and to load the digital asset into the computerized device; a digital asset management system that is connected via a first secure communication channel to the distributor appliance, and that is operable to generate and conditionally transmit the digital asset to the distributor appliance; and a provisioning controller that is connected via a second secure communication channel to the distributor appliance and is connected via a third secure communication channel to the digital asset management system, and that is operable to direct the digital asset management system to transmit the digital asset to the distributor appliance. The computerized device may be nonfunctional or only partially functional before the digital asset is loaded into the computerized device, due to the absence of the digital asset. The digital asset may be at least one of a digital certificate, a cryptographic key, and executable software.

In various implementations, the system may further include a second distributor appliance that is connected via a fourth secure communication channel to the digital asset management system and that is communicatively connected to the computerized device after the first distributor appliance is disconnected, and that is operable to receive a second digital asset and to 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 distributor appliance. The computerized device may be fully functional after the second digital asset is loaded into the computerized device.

In various implementations, the digital asset management system may further include one or more virtual machines that run a registration authority application and that are communicatively connected to one or more compute engines that perform cryptographic computations required by the registration authority application; one or more virtual machines that run an enrollment certificate authority application and that are communicatively connected to one or more compute engines that perform cryptographic computations required by the enrollment certificate authority application; one or more virtual machines that run a pseudonym certificate authority application and that are communicatively connected to one or more compute engines that perform cryptographic computations required by the pseudonym certificate authority application; one or more virtual machines that run a first linkage authority application and that are communicatively connected to one or more compute engines that perform cryptographic computations required by the first linkage authority application; and one or more virtual machines that run a second linkage authority application and that are communicatively connected to one or more compute engines that perform cryptographic computations required by the second linkage authority application.

In other implementations, the digital asset management system may further include a database that is operably connected to the one or more virtual machines that run the registration authority application, the one or more virtual machines that run the enrollment certificate authority, the one or more virtual machines that run the pseudonym certificate authority application, the one or more virtual machines that run the first linkage authority application, and the one or more virtual machines that run the second linkage authority application.

In still other implementations, the system may further include a portal that is operably connected to the provisioning controller and that authenticates a manufacturer of the computerized device and enables the manufacturer to manage provisioning of the computerized device, and/or a portal that is operably connected to the provisioning controller and that authenticates an installer of the computerized device and enables the installer to manage provisioning of the computerized device, and/or a portal that is operably connected to the provisioning controller and that authenticates a regulator of the computerized device and enables the regulator to regulate provisioning of the computerized device.

In yet other implementations, the provisioning controller may 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 yet other implementations, the provisioning controller may be further operable to create and maintain a log that is associated with the digital device and that stores information regarding the provisioning activities for the digital device, and the distributor appliance may be further operable to transmit information regarding provisioning activities related to the digital device to the provisioning controller for storing in the log.

In yet other implementations, the provisioning controller may be further operable to authenticate the digital device before directing the digital asset management system to transmit the digital asset.

The accompanying drawings, which are incorporated into and constitute a part of this specification, illustrate implementations of the invention and together with the description, serve to explain the principles of the invention. In the figures:.

Reference will now be made in detail to various implementations of the invention, examples of which are illustrated in the accompanying drawings. Wherever convenient, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

In order to ensure safe and proper operation in the field, embedded devices, for instance, the Electronic Control Unit (ECUs) used in vehicles, need to be properly initialized during manufacturing by provisioning digital assets, such as security assets. Digital assets could include various cryptographic keys, a unique identifier, digital certificates, and software. In most cases, the origin of these digital assets and manufacturing factories are located in different geographical locations, which 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, such that the digital assets cannot be accessed or modified by malicious parties or by accident.

There are drawbacks to traditional network security protocols for end-to-end protection, such as TLS/SSL, in that they require either pre-shared keys or certain secret security materials to pre-exist at both communicating parties. This creates a cyclic technical problem in that, in order to provision digital assets, some initial secret materials must pre-exist. This problem includes how to protect the initial secret materials. This problem is especially acute for computerized devices because, to simplify logistics, typically a single version of the initial software is loaded on the computerized device during manufacturing. If this initial software must contain initial security materials, this requires a global secret to exist. As a consequence, compromising the initial security materials will lead to compromise of all digital assets provisioned on all devices, as 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.

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

The actions may also include correctly installing the device into its operational environment and testing it to verify that it is operating properly. The ability to securely provision only known-to-be-good devices is complicated by the fact that the devices may be built by one manufacturer and later installed by another into a larger system or device-for example an On Board Unit (OBU) built by a component manufacturer may be installed into a car built by the car manufacturer. An improperly installed device may function incorrectly.

Various implementations consistent with the present invention provide secure provisioning of computerized devices, including loT devices. Such implementations serve to prevent or inhibit the malicious, negligent, or mistaken tampering, altering, updating, or releasing of digital assets that are used by the computerized devices, and prevent or inhibit the improper installation of the computerized devices and their software.

Various implementations consistent with the present invention may also produce audit logs, records, reports, and the like, of the secure provisioning process, which may be used to analyze and resolve later-discovered problems.

Various implementations consistent with the present invention may also provide a secure provisioning and management platform, which may be provided as a service to device and system manufacturers.

<FIG> is a block diagram showing an example of a system <NUM> for secure provisioning of computerized devices, consistent with implementations of the invention. As shown in the example of <FIG>, the system <NUM> includes a provisioning controller <NUM>. The provisioning controller <NUM> may be implemented as a server computer (e.g., having at least one processor and associated memory) with an embedded hardware security module (HSM) that securely generates and stores digital security assets and that securely performs a variety of cryptographic and sensitive computations. The HSM protects digital security assets, such as cryptographic keys, and other sensitive data from possible access by an attacker. In various implementations, the provisioning controller <NUM> functions to authenticate and securely communicate with users of the system <NUM>; securely communicate with and manage one or more distributor appliances <NUM>, <NUM>; securely communicate with and direct the operations of a digital asset management system (DAMS) <NUM>; create and store provisioning records; create, store and distribute provisioning records; create, store and distribute audit logs; create and distribute certificates to cryptographically bind together the DAMS <NUM> and distributor appliance <NUM>, <NUM> elements; revoke users and managed devices as needed if they cease to be trusted; and create and distribute secure encrypted backups of critical keys and data for offsite storage for business continuity and disaster recovery.

As shown in the example of <FIG>, the provisioning controller <NUM> is communicatively connected to a database <NUM>, which may store data, information, and digital assets related to securely provisioning the devices 106a, 106b, (which may be collectively referred to as <NUM>).

The provisioning controller <NUM> is also securely communicatively connected to a manufacturer's user portal <NUM>, which may be implemented, e.g., as a server or as an interface to the provisioning controller <NUM>. In various implementations, the staff <NUM> of a device manufacturer <NUM> may use the manufacturer's user portal <NUM> to interface with the provisioning controller <NUM> (and thus the DAMS <NUM>) and manage their device provisioning activities. In various implementations, the manufacturer's user portal <NUM> may collect identifying information from a staff user <NUM>, such as username, password, two-factor identification data, a facial recognition image, a fingerprint, etc., and provide the identifying information to the provisioning controller <NUM>. The provisioning controller <NUM> may authenticate the staff <NUM> before allowing the staff <NUM> to access the secure provisioning system <NUM>. For example, the provisioning controller <NUM> may look up identifying information that is associated with the staff user <NUM> and that was previously verified and stored in its database <NUM>, and compare the stored identifying information to the identifying information collected by the manufacturer's user portal <NUM>. Alternatively, the provisioning controller <NUM> or the DAMS user portal <NUM> may be integrated with a user's enterprise identification and authentication system, which will determine if the staff <NUM> are authorized to use the system <NUM>. In various implementations, the provisioning controller <NUM> or the DAMS user portal <NUM> may apply roles to the successfully authenticated staff <NUM> to constrain their actions within the system <NUM>. In some implementations, the provisioning controller <NUM> may allow access only if the two sets of identifying information match.

Similarly, the provisioning controller <NUM> is also communicatively connected to an installer user portal <NUM>, which may be implemented, e.g., as a server or as an interface to the provisioning controller <NUM>. In various implementations, the staff <NUM> of a device installer may use the installer user portal <NUM> to interface with the provisioning controller <NUM> (and thus the DAMS <NUM>) and manage their device installation and provisioning activities. The provisioning controller <NUM> may authenticate the staff <NUM> before allowing the staff <NUM> and assign them roles before allowing the staff <NUM> to access the secure provisioning system <NUM> and perform authorized functions on the system.

Also similarly, the provisioning controller <NUM> is also communicatively connected to a regulator portal <NUM>, which may be implemented, e.g., as a server or as an interface to the provisioning controller <NUM>. In various implementations, a regulator <NUM>, once authenticated by the provisioning controller <NUM>, may use the regulator portal <NUM> to interface with the provisioning controller <NUM> and manage the review and approval of manufacturers <NUM>, installers <NUM>, devices <NUM>, and/or the software/digital assets that are installed in the devices <NUM>. The provisioning controller <NUM> may authenticate the regulator <NUM> before allowing the regulator <NUM> to access the secure provisioning system <NUM>. In some implementations of the system <NUM>, the regulator <NUM> and the regulator portal <NUM> are optional.

The provisioning controller <NUM> is further communicatively connected to the DAMS <NUM>. In various implementations, the DAMS <NUM> may be implemented as a server, a device, or a system of secure appliances and/or servers. The DAMS <NUM> securely retrieves the public keys from the end entity devices to be provisioned, via the distributer appliances <NUM>, <NUM>, or other secure and authenticated connection, and securely supplies the digital certificates and related data that are installed in the devices <NUM>. In addition, the DAMS <NUM> securely receives, via the distributor appliances <NUM>, <NUM>, status information about the provisioning, installation, functionality, etc. of the computerized devices <NUM> from the manufacturer <NUM> and the installer <NUM>. In addition, the DAMS <NUM> may perform this provisioning at a single site or at multiple sites as shown in <FIG>. As explained in more detail with respect to <FIG>, the DAMS <NUM> may include the following main elements: a root certificate authority (CA), a policy generator, a CRL generator, a misbehavior authority, an intermediate CA, an enrollment CA, a linkage authority, a pseudonym CA, and a registration authority.

The DAMS <NUM> adds new functionality and improves upon the components and functionality described in the paper "A Secure Credential Management System for V2V Communications" by William Whyte et al. , <NUM> IEEE Vehicular Networking Conference, December <NUM>. In various implementations, the DAMS <NUM> includes multi-stage programming and flexible management, (e.g., allowing the inclusion of regulators <NUM>). Various implementations of the DAMS <NUM> also enable the ability to allow a single DAMS <NUM> to provide different levels of provisioning to different subscribers. Various implementations of the DAMS <NUM> also enable the ability to allow subscribers to assign different digital certificate usages during a time period (e.g., per week) as well as different certificate loads (such as one week, instead of three years as in conventional systems). Various implementations of the DAMS <NUM> may also provide subscriber-specific URLs so that a specific manufacturer's computerized device <NUM> (e.g., an OEM's vehicles) can stay within the manufacturer's sphere (e.g., their URL shows their name).

As shown, the provisioning controller <NUM> is also communicatively connected to the distributor appliances <NUM>, <NUM>. In various implementations, a distributor appliance <NUM>, <NUM> may be implemented as a standalone secure appliance installed at the company premises (as shown) or as a web or cloud service, among other things. In various implementations, the distributor appliance <NUM>, <NUM> is realized as a trusted endpoint device that securely transmits and receives digital assets and other information to and from the DAMS <NUM> and the provisioning controller <NUM>, preferably via dedicated, non-Internet communications channels. As shown, a distributor appliance <NUM>, <NUM> also connects, either directly or indirectly, with a device 106a, 106b, in order to download digital assets to, and receive data from, the device 106a, 106b. In various implementations, the distributor appliance <NUM>, <NUM> can be implemented as box including 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 appliance may be specifically designed to operate in untrusted environments yet still provide trusted and reliable operation. The distributor appliance has a secure communications channel(s) between itself and the secure provisioning controller <NUM> and the DAMS <NUM>. This channel is used to control the distributor appliance and to send and retrieve provisioning-related data and log information. The distributor appliance also may have a secure communications channel to the tester <NUM> used to program or provision the device <NUM>. This channel protects provisioning data and log data from being revealed or modified on the manufacturing location's communication network. The distributor appliance <NUM> may also establish a secure communications channel directly with the device <NUM> to be programmed so that the provisioning data cannot be compromised or modified by a third party (including a rogue tester <NUM>). In various implementations, the distributor appliance may collect public keys and other data, such as microprocessor serial numbers, from the devices <NUM> it is to provision. It may send this information to the provisioning controller <NUM> and/or the DAMS <NUM>. It may also accept data and commands and other information from the provisioning controller <NUM> and/or the DAMS <NUM> to program into the device <NUM>. It may return its own log data and it may return data from the tester <NUM> to the provisioning controller <NUM> and/or the DAMS <NUM>.

As shown with respect to the device manufacture <NUM>, the distributor appliance <NUM> may be communicatively connected to a tester <NUM>, (e.g., a computerized manufacturing apparatus, a product testing device, or the like), which is in turn connects to the device 106a that was produced by the manufacturer <NUM>, such as an OBU device. The manufacturer <NUM> may include or be a factory that manufactures and/or supplies computerized devices 106a to the market. As one of many possible examples, the computerized device 106a may be an embedded Universal Integrated Circuit Card (eUICC), which is used in cellular modems for telecommunications, incorporated as part of an On Board Unit (OBU) that is later installed in a car, for communications between cars and transportation infrastructure devices. It could also be the V2V secure microprocessor installed in an OBU for communications with other vehicles and Road Side Units (RSU). These newly manufactured devices 106a must be properly provisioned with digital assets, for example, digital certificate(s) from the DAMS <NUM>, in order to operate properly. The staff <NUM> of the manufacturer <NUM> may use the user portal <NUM> to interact with the provisioning controller <NUM> and manage the product provisioning activity by the DAMS <NUM>.

As shown with respect to the installer <NUM>, the distributor appliance <NUM> may alternatively be communicatively connected directly to the device 106b, while or after the device 106b is installed in its operating environment. The installer <NUM> may include or be a factory or shop that installs computerized devices 106b into their operating environment-for example, installs OBUs into cars. At installation, the computerized devices 106b must be further properly provisioned with digital assets, for example, additional digital certificate(s) from the DAMS <NUM>, in order to operate properly. The staff <NUM> of the installer <NUM> may use the installer user portal <NUM> to interact with the provisioning controller <NUM> and manage the product provisioning activity by the DAMS <NUM>.

In various implementations, the provisioning controller <NUM>, the distributor appliances <NUM>, <NUM>, and the DAMS <NUM> may have secure, non-publicly accessible communications links or channels between them, and in various embodiments, all of the communication links shown in <FIG> may be secure, non-publicly accessible communication channels. In various implementations, these secure channels are encrypted and mutually authenticated to prevent unauthorized end points from communicating within this secure infrastructure. Multiple security mechanisms may be used to protect these communications channels so that if the outer layer is somehow compromised, the inner layer will remain secure. As an example, a mutually authenticate TLS tunnel may be used as the outer layer with the inner layer using another protocol such as a proprietary secure communications protocol. These secure connections between the infrastructure components comprising system <NUM> are used for protecting the sensitive communications between the components and ensuring their correct operation. Using these secure paths, the provisioning controller <NUM> and the DAMS <NUM> can send digital data between components without concern that it will be compromised or modified in transit. Command and control information may be also passed over these channels. For instance, the provisioning controller <NUM> can control to which distributor appliance <NUM>, <NUM>, certain digital assets and data are sent. It can also instruct the distributor appliances <NUM>, <NUM> how to meter out this data to devices <NUM> on the manufacturing line that it is provisioning. Further, the distributor appliances <NUM>, <NUM> can report information back to the provisioning controller <NUM> without concern that it will be compromised or modified in transit. For example, the secure provisioning controller <NUM> can program the distributor appliance <NUM>, <NUM> to provision up to <NUM>,<NUM> devices with any type of digital asset - e.g., certificates, software, fuse contents, etc. The distributor appliance <NUM>, <NUM> can count the devices it is provisioning and when it reaches its limit, it will report that to the provisioning controller <NUM>. In various implementations, the devices (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) that are managed by the provisioning controller <NUM> include functionality that causes them to cease to operate if they do not regularly communicate with the provisioning controller <NUM>; thus if they are stolen then they become useless. This functionality prevents lost/stolen devices from continuing to operate and to provision devices <NUM> as if they were still located in the proper manufacturing environment.

Continuing to refer to the example shown in <FIG>, in operation the distributor appliance <NUM> located at the manufacturer <NUM> securely receives digital assets from the DAMS <NUM> and supplies them to the tester <NUM> for the device 106a. As each device 106a is manufactured by the manufacturer <NUM>, the tester <NUM> communicates with the device 106a to get information from the device 106a, such as its unique identification number and status, and to download or otherwise install the digital assets into the device, such as digital certificates. The tester <NUM> may also supply information (e.g., provisioning status) from the device 106a to the distributor appliance <NUM>, which securely communicates that information to the DAMS <NUM> and/or the provisioning controller <NUM>. In some implementations, the tester <NUM> may include a software transportation layer security (TLS) agent that securely transports data between the distributor appliance <NUM> and the device 106a, which in effect creates a secure encrypted communication path between the DAMS <NUM> and the device 106a via the distributor appliance <NUM> and the tester <NUM>, using an ephemeral key associated with each device 106a.

After it is initially provisioned, the manufacturer <NUM> ships the device 106a to the installer <NUM>, which installs the device 106b. In various implementations, before initial provisioning, the device 106a is nonfunctional; and after initial provisioning by the manufacturer <NUM>, the device 106a is not yet fully functional although it can partially function. In such implementations, the initial provisioning makes the device functional only to the extent needed for installation and further final provisioning, which is required to make it fully operational.

The installer <NUM> installs the device 106b into its operational environment, and a staff member <NUM> of the installer <NUM> notifies the provisioning controller <NUM> of that fact via the installer portal <NUM>. This notification attests that the installation was properly completed and preferably includes information uniquely identifying the device 106b to the provisioning controller <NUM>. In some implementations, the distributor appliance <NUM> may automatically notify the provisioning controller <NUM> after querying the device 106b for status and identification information. In various implementations wherein the installer <NUM> attests via the Installer portal <NUM> that he has properly installed the device 106b, this attestation may be logged/saved into the database <NUM> by the provisioning controller <NUM>. The attestation may include specific test data related to each particular installed device 106b, such as a radio transmit power measurement or a verification of a GPS antenna location.

In response to the installation notification, the provisioning controller <NUM> verifies that (i) the device 106b is listed in its database <NUM> as a device that was legitimately manufactured by the manufacturer <NUM>, (ii) the device 106b is listed in its database <NUM> as having been successfully initially provisioned by the manufacturer <NUM>, and (iii) the installer <NUM> is listed in its database <NUM> as an authorized installer. If this verification is successful, the controller <NUM> directs the DAMS <NUM> to send the digital assets (e.g., Pseudonym Certificates (PCs)) and/or other information needed to operationally provision the device 106b, such that the device 106b can properly function as installed in its operating environment.

In various implementations, the regulator <NUM>, via the regulator portal <NUM>, interacts with the provisioning controller <NUM> to identify, verify, and manage installers <NUM> and/or manufacturers <NUM>, such that unauthorized installers (e.g., hackers) cannot obtain authentic digital assets from the system <NUM>. The staff members of the regulator <NUM> may be authenticated by the provisioning controller <NUM> and may have unique IDs with the system <NUM> so that their actions can be uniquely logged. In various implementations, the regulator <NUM> can use the regulator portal <NUM> to query the provisioning controller <NUM> to obtain copies and reports of information logged by the controller <NUM>, such as attestation reports, installer actions, number and identity of manufactured devices 106a, number and identity of installed, fully provisioned devices 106b, and the like.

In various implementations, the installer <NUM> must be authenticated as authorized by the provisioning controller <NUM> in order to interact with the system <NUM>. To become authorized, the installer <NUM> may, for example, have to execute the appropriate contractual documents stating they will properly install the devices 106b in the target environment (e.g., target vehicle or site or the like). The installer <NUM> may, for example, be required to attest to other contractual elements by the regulator <NUM>. Preferably, each installer <NUM> has a unique ID within the system <NUM> such that their actions can be uniquely logged by the provisioning controller <NUM>.

The described implementations of the system <NUM> and its functionality ensures that only devices <NUM> that have been manufactured by the manufacturer <NUM> and properly installed and tested by and authorized installers <NUM> are fully provisioned with the digital assets needed to make the devices <NUM> operational. The provisioning controller <NUM> produces extensive logs and reports for what actions are taken by whom at each stage in the provisioning process, providing a critical audit capability that has not existed with conventional systems.

One of ordinary skill will recognize that the components, processes, data, operations, and implementation details shown in <FIG> are examples presented for conciseness and clarity of explanation. Other components, processes, implementation details, and variations may be used without departing from the principles of the invention, as this example is not intended to be limiting and many variations are possible. For example, although only one manufacturer <NUM>, only one installer <NUM> and only one regulator <NUM> are shown in <FIG>, other implementations may have any number of each of these entities. For another example, although the DAMS <NUM> and provisioning controller <NUM> are shown as separate devices, other implementations may combine their functionality into a single device, e.g., a single server. As yet another example, the same may be done for the portals <NUM>-<NUM>. For yet another example, the system <NUM> could additionally include an asset management appliance (AMA, not shown), as described in the <CIT>. In such an implementation, the AMA may be communicatively connected to the provisioning controller <NUM> and/or the distributor appliances <NUM>, <NUM> and/or the DAMS <NUM>. In various implementations, the AMA may include a user-friendly GUI and functionality that allows production coordinators to easily and efficiently manage product (e.g. device <NUM>) configurations and builds, and that allows asset owners to easily and efficiently manage inventories of digital assets.

<FIG> a swim-lane diagram illustrating an example of process <NUM> for securely provisioning a computerized device, consistent with implementations of the invention. In various implementations, some or all of the process <NUM> or the operations shown may be performed by code executing on a general purpose computing system (which may include one or more processors or one or more computing subsystems), by a hardware-only system, or by a system that is a hybrid of the two. As shown across the top of <FIG>, the entities involved with the process <NUM> include the manufacturer <NUM> of the computerized devices <NUM>, the distributor appliance <NUM> that is located at the manufacturer <NUM>, the provisioning controller <NUM> and the DAMS <NUM>. In various implementations, these entities may be, and may communicate with each other, as described with respect to <FIG> and throughout this disclosure.

As shown in the example of <FIG>, the process <NUM> begins at <NUM> with the manufacturer <NUM> (e.g., a staff member <NUM>) requesting digital asset provisioning service(s) from the provisioning controller <NUM>, where the digital asset(s) will be provisioned to (e.g., used by) a device 106a and where the request may identify the device 106a that is the destination of the digital asset. The request may be, for example, a manufacturer <NUM> may be requesting provisioning service for a new product <NUM> or making a new provisioning service request for an existing product <NUM>. In various implementations, this operation may involve an authorized user logging onto the provisioning controller <NUM>, for example, via the user portal <NUM>. In some cases, the requested digital asset may be a secure credential such as an enrollment certificate; executable code that a device <NUM> will run; digital operating parameters; or the like. An enrollment certificate is a public key certificate that identifies its holder as an authorized participant in an ecosystem in which all participants must share valid enrollment certificates, (such as the USDOT's V2X ecosystem), and in which authorized participants are able to also receive pseudonym certificates that enable communication and operation of a device <NUM> within the ecosystem (e.g., to enable communications and operations between vehicles and roadside infrastructure in the example of the USDOT's V2X ecosystem).

At <NUM>, the provisioning controller <NUM> determines whether the user from the manufacturer <NUM> is an authorized user. In some implementations, the provisioning controller <NUM> may also determine at <NUM> whether the device 106a (e.g., the product) to be provisioned is approved for use with the system <NUM>. In some instances, a list of approved devices may be provided by the regulator <NUM> of <FIG> and used by the provisioning controller <NUM> to make this determination.

If the user (and/or the product) is not authorized, then the provisioning controller <NUM> rejects the request for the digital asset provisioning services (not shown in <FIG>). If, on the other hand, an authorized user is making the request (e.g., for an authorized product) (<NUM>, Yes), then the provisioning controller <NUM> directs, instructs, or otherwise controls the DAMS <NUM> to fulfill the service request, for instance by transmitting a service request instruction (at <NUM>) to the DAMS <NUM>.

At <NUM>, in response and upon condition of receiving the request from <NUM>, the DAMS <NUM> configures itself to begin service to the device 106a, based on the request. In some implementations, the DAMS <NUM> may also send (not shown) instructions to the distributor appliance <NUM> to configure the distributor appliance <NUM> to service the device 106a.

At <NUM>, the DAMS <NUM> generates, creates, calculates, and/or retrieves the digital asset for the device 106a, as requested at <NUM>. In various implementations, the DAMS <NUM> may create or generate requested digital security asset(s), such as public and private key pairs as well as an enrollment certificate(s) and a pseudonym certificate(s) for the device 106a.

In an alternative implementation (not shown in <FIG>) of operation <NUM>, the DAMS <NUM> requests and receives, from the distributor appliance <NUM>, digital-asset-generation information associated with the device 106a, such as enrollment and pseudonym public keys generated by and retrieved from the device 106a and data uniquely identifying the device 106a (e.g., a microprocessor serial number). In such implementations, the DAMS <NUM> then uses the enrollment and pseudonym public keys to generate the digital asset-e.g., the enrollment certificate and an appropriate number of pseudonym certificates for the device 106a.

At <NUM>, the DAMS <NUM> transmits the digital asset to the distributor appliance <NUM> of the manufacturer <NUM> that requested the digital asset service at <NUM>. For example, the DAMS <NUM> may securely transmit public and private key pairs, an enrollment certificate and pseudonym certificates to the distributor appliance <NUM> of the manufacturer <NUM>.

At <NUM>, the DAMS <NUM> transmits log information regarding the digital asset to the provisioning controller <NUM>. In various implementations, the log information may include information describing the request and transfer of the digital asset, such as the requestor's ID, the digital asset's ID, the distributor appliance's ID, timestamps of the request and transmission actions, the received microprocessor serial number, etc. In some implementations, the log information may include a copy of the digital asset. At <NUM>, the provisioning controller <NUM> receives and stores the log information, for example in the database <NUM>. The provisioning controller <NUM>, in effect, maintains an audit trail of all the activities that occur in the system <NUM>, which allows many types of data to be assembled, such as data regarding how may devices 106a were built and provisioned by a manufacturer <NUM> and when. Such data and log information may be used for billing, as well as auditing purposes.

At <NUM>, the distributor appliance <NUM> receives and stores the digital asset (e.g., public and private key pairs, an enrollment certificate and pseudonym certificates) that was sent by the DAMS <NUM>.

At <NUM>, the distributor appliance <NUM> requests and receives, from the device 106a, a digital security asset, such as a public key, that can be used to securely transfer the digital asset from the distributor appliance <NUM> to the device 106a. Various types of devices 106a have the ability to generate an ephemeral key pair, perhaps using a secure processor built into the devices <NUM>, and the public key may be part of the ephemeral key pair. At <NUM>, the distributor appliance <NUM> uses the digital security asset, (e.g., the public key), to securely transmit the digital asset (e.g., the enrollment certificate) to the device 106a. In various implementations, the distributor appliance <NUM> may use the device 106a's public key to form, for example, a virtual private network (VPN) with the device 106a and therein securely transmit the digital asset.

In various implementations, the distributor appliance <NUM> may employ transport layer security (TLS) between it and a tester <NUM> to secure communications with the tester <NUM>, which may be connected to the device 106a. In implementations where it is desirable to have secure communication directly to the device 106a, the system may create an ephemeral public key pair on the device 106a and, using the public key along with a certificate from the distributor appliance <NUM> containing the distributor appliance <NUM>'s public key, create a secure tunnel to the device106a. In such implementations, the device 106a would run special code with the system <NUM>'s root public key in it to validate the certificate that the distributor appliance <NUM> sends to it.

Once the secure path is established between the device 106a or the tester <NUM> and the distributor appliance <NUM>, the device 106a can then create the enrollment and pseudonym public key pairs (e.g., for the V2X ecosystem) and export the public keys and other data to the distributor appliance <NUM>, and the distributor appliance <NUM> can then send this data to the DAMS <NUM> and the provisioning controller <NUM>. As described above with respect to the alternative implementation of operation <NUM>, the DAMS <NUM> may use the received public keys to create the enrollment certificate and the pseudonym certificate(s)-in some implementations, there could be a large number (e.g., <NUM>,<NUM>) of the pseudonym certificates. In this alternative example of an implementation, the DAMS <NUM> will return these certificate(s) to the distributor appliance <NUM> at operation <NUM> as previously described. In some other implementations, the DAMS <NUM> may transmit these certificates to the distributor appliance <NUM> instead of <NUM>, depending on where the provisioning is being performed.

In some implementations, the distributor appliance <NUM> may communicate directly with the device <NUM>, for example, if the device <NUM> has its own wireless or wired communication functionality and is at least partially operational. In other implementations, the distributor appliance <NUM> may communicate indirectly with the device <NUM> via an intermediate device, such as a tester <NUM>.

The device 106a receives the digital asset and stores it for use during operation. For example, if the device 106a is an automobile on-board unit (OBU) or electronic control unit (ECU) and the digital asset is a security asset (e.g., a public key certificate) needed to join a wireless network, then the digital security asset is stored by the OBU. When the OBU is later installed and activated in a car, it will attempt to connect to a wireless network. The network will attempt to authenticate the OBU before allowing the OBU to connect to the network. The OBU will be able to authenticate and join the network only if it has the digital security asset provided by the distributor appliance <NUM> at the manufacturer <NUM>.

At <NUM>, the distributor appliance <NUM> receives or accesses, from the device 106a, status information that indicates whether or not the device 106a successfully received and installed (e.g., stored) the digital asset that was transmitted at <NUM>.

At <NUM>, the distributor appliance <NUM> transmits the status information to the provisioning controller <NUM>. And at <NUM>, the provisioning controller <NUM> receives and stores the status information in association with the log information stored in operation <NUM>. Thus, the provisioning controller <NUM> continues the audit trail or audit log for all of the system <NUM> activities associated with each particular device <NUM>. In various implementations, the audit log may contain, for each device <NUM>, information indicating; the success of failure of the manufacturer's provisioning (e.g., operations <NUM>-<NUM>); the identity of the digital asset (and/or a copy the digital asset itself); the type of cryptography; and the like.

At <NUM>, if the device 106a was successfully provisioned with the digital asset, then the manufacturer <NUM> releases the device to the market. For example, the manufacturing company <NUM> may physically ship the device 106a to a company that installs the device in its operating environment (e.g., the installer company <NUM> of <FIG>). In some implementations, the device 106a may be fully programmed or provisioned at this point in time, and able to operate with full functionality; while in other implementations, the device 106a may be only partially programmed or provisioned at this point, and is either unable to operate with full functionality or is nonfunctional.

The example depicted in <FIG> is only for the purpose of illustration and is not intended to be limiting. Further, the depicted process <NUM> is an example that has been somewhat simplified for clarity of explanation of certain novel and innovative features consistent with certain disclosed implementations, but this example is not intended to be limiting and many variations are possible. For example, while the 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 the purpose of explanation, and, in some implementations, multiple operations may be performed simultaneously and/or as part of a single computation or larger operation. The operations described are not intended to be exhaustive, limiting, or absolute, and various operations can be modified, inserted, or removed. As an example of a variation, although <FIG> is generally described in the context of a single digital asset (e.g., a single digital certificate), the system and process will function similarly to handle multiple digital assets (e.g., two or more digital certificates). For another example, in a case where the device 106a does not have the secure communications ability, the operations <NUM> and <NUM> could be removed and the distributor appliance <NUM> could communicate with the device 106b using unencrypted communications.

For yet another example, in various implementations, the provisioning controller <NUM>, or a delegated authority, such as a specialized signing appliance, may similarly transmit to the distributor appliance <NUM> and have it load another or an additional digital asset into the device 106b, including digital assets such as software, firmware, fuse blobs, manifest files, etc. In such implementations, the provisioning controller <NUM> may additionally or alternatively retrieve, obtain, or otherwise access, or direct the accessing of, a requested digital asset from storage. For example (not shown in <FIG>), the provisioning controller <NUM>, or its authorized delegate, may retrieve an executable software image (e.g., a compiled computer program stored in the database <NUM>) that will be loaded into and run by a device 106a and send the executable software image to the distributor appliance <NUM> for programming into the device. In various implementations, the digital assets accessed by the provisioning controller <NUM> may consist only of software, etc., that was securely supplied, released, and/or authorized by the manufacturer <NUM> 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 <NUM> may be stored in a storage device or database that is associated with the provisioning controller <NUM>, such as the database <NUM> of <FIG>.

<FIG> a swim-lane diagram illustrating an example of process <NUM> for securely provisioning a computerized device, consistent with implementations of the invention. In various implementations, some or all of the process <NUM> or the operations shown may be performed by code executing on a general purpose computing system (which may include one or more processors or one or more computing subsystems), by a hardware-only system, or by a system that is a hybrid of the two. As shown across the top of <FIG>, the entities involved with the process <NUM> include an installer <NUM> of the computerized devices <NUM>, the distributor appliance <NUM> that is located at the installer <NUM>, the provisioning controller <NUM> and the DAMS <NUM>. In various implementations, these entities may be, and may communicate with each other, as described with respect to <FIG> and throughout this disclosure.

As shown in the example of <FIG>, the process <NUM> begins at <NUM> with the installer <NUM> receiving a device 106b, (for example, an OBU or an ECU), that was manufactured and released or shipped by the manufacturer <NUM> (see operation <NUM> of <FIG>). At <NUM>, the installer <NUM> may install the device 106b into its operating environment, such as into a larger system. For example, the installer <NUM> may be an automaker that purchases OBUs from the manufacturer <NUM>, and the installer <NUM> may install the OBU into a car. In various implementations, installing the device 106b may include testing the operation, functioning, etc. of the device 106b after installation, and collecting related status data.

In some implementations, the device 106b may be only partially provisioned and not fully functional. For example, the manufacturer <NUM> of the device 106b may have provisioned the device 106b with only the enrollment certificate, such that the device 106b would need to be further provisioned with another digital certification, such a pseudonym certificate in order to gain full functionality, for example, functionality to communicate with another fully programmed device <NUM>.

At <NUM>, the installer <NUM> (e.g., a staff member <NUM>) transmits installation status data to the provisioning controller <NUM>. In various implementations, the installation status data includes an immutable identifier of the device that was 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 may also include other information, such as a unique identifier of the installer <NUM>, information indicating how and when the device 106b was installed, information about the results of tests done on the installed device 106b, information attesting that the installer <NUM> installed the device 106b in accordance with applicable specifications, contractual requirements, and or instructions, and/or other similar information.

At <NUM>, the provisioning controller <NUM> determines whether the user from the installer <NUM> is an authorized user. If not, then the provisioning controller <NUM> rejects the installation status communication (not shown in <FIG>). If, on the other hand, an authorized user is making the request (<NUM>, Yes), then the provisioning controller <NUM> determines (<NUM>) whether the device 106b that is identified in the installation status data is an authorized device. In some implementations, the provisioning controller <NUM> may determine that the device 106b is authorized by verifying against previously stored information its database <NUM> that <NUM>) there is a record for the device 106b in its dbase <NUM>; <NUM>) the record indicates that the device 106b was successfully provisioned at the manufacturer <NUM>; <NUM>) that the record indicates that the device 106b was sent to the installer <NUM>, (which was verified in <NUM> as being an authorized installer).

If the device identified in the installation status data is not authorized, then the provisioning controller <NUM> rejects the installation status communication (not shown in <FIG>). If, on the other hand, the device 106b identified in the installation status data is authorized (<NUM>, Yes), then the provisioning controller <NUM> stores the installation status data with the log information associated with the device 106b, at <NUM>. For example, the log information associated with the device 106b may have been previously stored in the database <NUM> as described with respect to operation <NUM> of <FIG>.

At <NUM>, the provisioning controller <NUM> directs, instructs, or otherwise controls the DAMS <NUM> to fulfill the provisioning request, for instance by transmitting, to the DAMS <NUM>, a request to provision the device 106b, which is at the installer <NUM>. At <NUM>, in response and upon condition of receiving the request from <NUM>, the DAMS <NUM> generates and/or retrieves the digital asset that was requested at <NUM>. In various implementations, the DAMS <NUM> may create or generate the requested digital asset, such as a pseudonym certificate or other public key certificate, as described with respect to <FIG>. In various implementations, the DAMS <NUM>, or the provisioning controller <NUM> instead of the DAM <NUM>, may additionally or alternatively retrieve, obtain, or otherwise access a requested digital asset from storage, such as an executable image previously stored in the database <NUM> for use in devices of device 106b's type.

At <NUM>, the DAMS <NUM> transmits the digital asset to the distributor appliance <NUM> of the installer <NUM> that transmitted the installation status at <NUM>. For example, the DAMS <NUM> may securely transmit a pseudonym certificate to the distributor appliance <NUM> of the installer <NUM>.

At <NUM>, the distributor appliance <NUM> performs operations the same as or similar to operations <NUM>-<NUM>, as explained about with respect to <FIG>. At <NUM>, the distributor appliance <NUM> transmits the status information to the provisioning controller <NUM>. And at <NUM>, the provisioning controller <NUM> receives and stores the status information in association with previously stored information related to the device 106b, such as status information stored in operation <NUM>. Thus, the provisioning controller <NUM> continues the audit trail or audit log for all of the system <NUM> activities associated with each particular device <NUM>.

The process <NUM> depicted in <FIG> is an example for the purpose of illustration and is not intended to be limiting. Further, the depicted process <NUM> is an example that has been somewhat simplified for clarity of explanation of certain novel and innovative features consistent with certain disclosed implementations, but many variations are possible. For example, while the 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 the purpose of explanation, and, in some implementations, multiple operations may be performed simultaneously and/or as part of a single computation or larger operation. The operations described are not intended to be exhaustive, limiting, or absolute, and various operations can be modified, inserted, or removed.

<FIG> and <FIG> are together a a block diagram of an example of a system <NUM> for implementing a scalable and secure digital asset management system, in accordance with implementations of the invention. Various implementations of the system <NUM> may be use for extremely high volume device transaction and certificate generation processing. In various implementations, the system <NUM> may be implemented using multiple servers, hardware security modules, multiple compute or computing engines, and multiple virtual machines (VM). Examples of the system <NUM> may be implemented in a private data center, a cloud data center such as AWS, or in a hybrid of private and cloud data centers.

In various implementations, the system <NUM> may be, may be part of, or may interact with, the digital asset management system (DAMS) <NUM>, which may function as described with respect to <FIG> and the other sections of this disclosure.

As shown in the example of <FIG>, the architecture may include two provisioning controllers <NUM>-a primary and a standby, which preferably are implemented in separate servers. The two provisioning controllers <NUM> include functionality such that objects, data, etc. contained in the primary provisioning controller are copied or otherwise contained in the standby (secondary) provisioning controller. The standby provisioning controller may be brought online to replace the primary provisioning controller if the primary provisioning controller goes offline for any reason. This provides continuous (or very high) availability of the provisioning controllers <NUM>. In various implementations, the primary and a standby provisioning controllers may be as described with respect to <FIG> and the other sections of this disclosure. In various implementations, the provisioning controllers <NUM> may connect to the system <NUM> in the same or similar manner as described herein with respect to the connections and communication between the provisioning controller <NUM> and the DAMS <NUM> of <FIG>. In general, the provisioning controller <NUM> manages the system elements comprising the infrastructure so that only explicitly authorized elements can participate and interact with the system <NUM>. In various implementations, the provisioning controller <NUM> may integrate with a user's (e.g., manufacturer <NUM> or installer <NUM>) employee identification and authorization system, or it may provide its own capabilities for identification and authorization so that only authorized users can use the system <NUM>.

The architecture of the system <NUM> separates the non-security-related applications from the security functions. As shown in this example, the registration authority <NUM>, the certificate authorities <NUM>, <NUM>, and the linkage authorities <NUM>, <NUM> are implemented as applications on their own virtual machines, which execute on their own dedicated compute engines <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, all of which is separate from any non-security-related applications and functions. This provides both a technical and security advantage and improvement over conventional systems, in which the performance of the hardware security modules is slow or in which the cloud service provider cannot supply HSMs or in which their proper management of the HSMs is uncertain. By separating the critical security functions from each other and onto separate compute engines, as shown in <FIG>, the computation-intensive crypto and security functions (e.g., an elliptic curve butterfly expansion computation or an elliptic curve digital signature), for instance, as performed by the registration authority <NUM>, the certificate authorities <NUM>, <NUM>, and the linkage authorities <NUM>, <NUM>, are performed significantly faster than existing registration authority systems. This design enables significant improvements in transaction processing by enabling the "bottleneck" applications to be scaled as needed. For instance, if the registration authority application running on <NUM> and <NUM> needs to scale, additional VMs can be added while no change may be required in the secure compute capability of <NUM>. Alternatively, if the security computations are limiting performance, additional secure compute engines <NUM> can be added. This same multi-dimensional scaling is true for the other components of <NUM>. This capability provides significant performance improvements over other existing SCMS systems.

In various implementations, the registration authority <NUM> may be the authority in a provisioning network that verifies user requests for a digital certificate, or other type of digital security asset, and enable a certificate authority, (e.g., the certificate authorities <NUM>, <NUM>) to issue the digital certificate. In various implementations, the registration authority <NUM> may be similar to the registration authorities known in the public key infrastructure (PKI) system. In various implementations, the registration authority <NUM> may be implemented as a representational state transfer (REST) web service. As represented by the three "stacked" rectangles shown in <FIG> for the registration authority <NUM>, in various implementations there may be multiple instances of the registration authority <NUM> executing at the same time. This is similarly represented for the other "stacked" elements of <FIG>.

As represented by the "DB" arrow emerging at the lower left of the rectangles, the registration authority <NUM> (and the other components of <FIG> shown with DB" arrows) may be connected to a database <NUM>. In preferred implementations, the database <NUM> is a fast access, low-latency database. In some implementations, the database <NUM> may be a NoSQL database or database service, such as DynamoDB data service offered by Amazon web services. In various implementations, the data stored in the database <NUM> is application dependent, but may include past issued certificates, various linkage authority values, data on devices to whom certificates have been issued, operator actions, etc. Note that the data may be stored either unencrypted, encrypted or some combination thereof.

In the example shown in <FIG>, the registration authority <NUM> is connected to the other components, and the other components are connected to each other, by a messaging subsystem or service, which is represented by the boxes <NUM>. In some implementations, the messaging service <NUM> may be a fast message queuing service, such as the Amazon simple queue service (SQS) offered by Amazon web services.

In various implementations, the system <NUM> includes an enrollment certificate authority <NUM> and a pseudonym certificate authority <NUM>, as the digital certificates produced by the registration authority <NUM> are split into different segments-e.g., an enrollment digital certificate and pseudonym digital certificate.

In various implementations, the linkage authorities <NUM>, <NUM> link the identity of the certificate requestor (i.e., a unique identifier of the certificate requestor's device), to the issued pseudonym certificate for revocation purposes.

In various implementations, the compute engines <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> and the provisioning controller <NUM> include HSMs, which allow these components to perform secure computations without being unduly threatened from hackers. In some implementations, the compute engines <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> may be designed to perform secure computations themselves without requiring an embedded HSM-in such implementations, they embody the HSM.

One of ordinary skill will recognize that the components, processes, data, operations, and implementation details shown in <FIG> are examples presented for conciseness and clarity of explanation. Other components, processes, implementation details, and variations may be used without departing from the principles of the invention, as this example is not intended to be limiting and many variations are possible.

<FIG> is a block diagram of an example of a computing environment <NUM>, which includes a computing system <NUM> that may be used for implementing systems and methods consistent with implementations of the invention. Other components and/or arrangements may also be used. In some implementations, computing system <NUM> may be used to implement, at least partially, various components of <FIG>, such as the provisioning controller <NUM> and the DAMS <NUM>, among other things. In some implementations, a series of computing systems similar to computing system <NUM> may be each customized with specialized hardware and/or programmed as a specialized server to implement one of the components of <FIG>, which may communicate with each other via a network <NUM>.

In the example shown in <FIG>, the computing system <NUM> includes a number of components, such as a central processing unit (CPU) <NUM>, a memory <NUM>, an input/output (I/O) device(s) <NUM>, a hardware security module (HSM) <NUM>, and a nonvolatile storage device <NUM>. System <NUM> can be implemented in various ways. For example, an implementation as an integrated platform (such as a server, workstation, personal computer, laptop, etc.) may comprise a CPU <NUM>, a memory <NUM>, a nonvolatile storage <NUM>, and I/O devices <NUM>. In such a configuration, the components <NUM>, <NUM>, <NUM>, and <NUM> may connect and communicate through a local data bus and may access a data repository <NUM> (implemented, for example, as a separate database system) via an external I/O connection. The I/O component(s) <NUM> may connect to external devices through a direct communication link (e.g., a hardwired or local wifi connection), through 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 through other suitable connections. System <NUM> may be standalone or it may be a subsystem of a larger system.

The CPU <NUM> may be one or more known processor or processing devices, such as a microprocessor from the Core™ family manufactured by the Intel ™ Corporation of Santa Clara, CA or a microprocessor from the Athlon™ family manufactured by the AMD ™ Corporation of Sunnyvale, CA. The memory <NUM> may be one or more fast storage devices configured to store instructions and information executed or used by the CPU <NUM> to perform certain functions, methods, and processes related to implementations of the present invention. The storage <NUM> may be a volatile or non-volatile, magnetic, semiconductor, tape, optical, or other type of storage device or computer-readable medium, including devices such as CDs and DVDs and solid state devices, meant for long-term storage.

In the illustrated implementation, the memory <NUM> contains one or more programs or applications <NUM> loaded from the storage <NUM> or from a remote system (not shown) that, when executed by the CPU <NUM>, perform various operations, procedures, processes, or methods consistent with the present invention. Alternatively, the CPU <NUM> may execute one or more programs located remotely from the system <NUM>. For example, the system <NUM> may access one or more remote programs via the network <NUM> that, when executed, perform functions and processes related to implementations of the present invention.

In one implementation, the memory <NUM> may include a program(s) <NUM> for performing the specialized functions and operations described herein for the provisioning controller <NUM>, the DAMS <NUM>, and/or the distributor appliance <NUM>, <NUM>. In some implementations, the memory <NUM> may also include other programs or applications that implement other methods and processes that provide ancillary functionality to the invention.

The memory <NUM> may be also be configured with other programs (not shown) unrelated to the invention and/or an operating system (not shown) that performs several functions well known in the art when executed by the CPU <NUM>. By way of example, the operating system may be Microsoft Windows™, Unix™, Linux™, an Apple Computers™ operating system, or other operating system. The choice of operating system, and even to the use of an operating system, is not critical to the invention.

The HSM <NUM> may be a device with its own processor that securely generates and stores digital security assets and/or securely performs a variety of cryptographic and sensitive computations. The HSM <NUM> protects digital security assets, such as cryptographic keys, and other sensitive data from possible access by an attacker. In some implementations, the HSM may be a plug-in card or board that attaches directly to the computing system <NUM>.

The I/O device(s) <NUM> may comprise one or more input/output devices that allow data to be received and/or transmitted by the system <NUM>. For example, the I/O device <NUM> may include one or more input devices, such as a keyboard, touch screen, mouse, and the like, that enable data to be input from a user. Further, the I/O device <NUM> may include one or more output devices, such as a display screen, a CRT monitor, an LCD monitor, a plasma display, a printer, speaker devices, and the like, that enable data to be output or presented to a user. The I/O device <NUM> may also include one or more digital and/or analog communication input/output devices that allow the computing system <NUM> to communicate, for example, digitally, with other machines and devices. Other configurations and/or numbers of input and/or output devices may be incorporated in the I/O device <NUM>.

In the implementation shown, the system <NUM> is connected to a network <NUM> (such as the Internet, a private network, a virtual private network, a cellular network or other network or combination of these), which may in turn be connected to various systems and computing machines, such as servers, personal computers, laptop computers, client devices, etc. In general, the system <NUM> may input data from external machines and devices and output data to external machines and devices via the network <NUM>.

In the exemplary implementation shown in <FIG>, the data source <NUM> is a standalone database external to system <NUM>, such as the database <NUM>. In other implementations, the data source <NUM> may be hosted by the system <NUM>. In various implementations, the data source <NUM> may manage and store data used to implement systems and methods consistent with the invention. For example, the data source <NUM> may manage and store data structures that contain the status and log information for each device <NUM> provisioned by the system <NUM>, and the like.

The data source <NUM> may comprise one or more databases that store information and are accessed and/or managed through the system <NUM>. By way of example, the database <NUM> may be an Oracle™ database, a Sybase™ database, or other relational database. Systems and methods consistent with the invention, however, are not limited to separate data structures or databases, or even to the use of a database or data structure.

One of ordinary skill will recognize that the components and implementation details of the system in <FIG> are examples presented for conciseness and clarity of explanation. Other components and implementation details may be used.

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

Claim 1:
A system for securely provisioning a computerized device (<NUM>) for a set of communication and operation functions in an operational environment, the system comprising:
a distributor appliance (<NUM>) that is connected directly or indirectly to the computerized device (<NUM>) via a non-publicly accessible connection in order to download digital assets to and receive data from the computerized device (<NUM>), and that is configured to receive a first digital asset and to transmit the first digital asset to the computerized device (<NUM>);
a provisioning controller (<NUM>) that is connected to the distributor appliance (<NUM>), and that determines whether a first user that is requesting a first digital asset is authorized;
a digital asset management server (<NUM>) that is connected to the distributor appliance (<NUM>) and to the provisioning controller (<NUM>), and that is configured to transmit the first digital asset to the distributor appliance (<NUM>) when the first user is authorized as determined by the provisioning controller (<NUM>), wherein the first digital asset is configured to cause the computerized device (<NUM>) to be provisioned for at least some of, but less than all of, the set of communication and operation functions in the operational environment, enabling receipt of a second digital asset; and
wherein the digital asset management server (<NUM>) is configured to securely transmit the second digital asset to the computerized device (<NUM>) via a web or cloud service distributor (<NUM>) when the provisioning controller (<NUM>) determines that a second user that is requesting the second digital asset is authorized and that the computerized device (<NUM>) is authorized; and
wherein the computerized device (<NUM>) is provisioned for all of the set of communication and operation functions in the operational environment after the second digital asset is transmitted to the computerized device (<NUM>), and wherein each of the first and second digital asset comprises one or more of a digital certificate, a cryptographic key, and executable software.