Safe Provisioning and Management of Machines

Abstract

To provide a system for securely provisioning an a computerized apparatus.SOLUTION: A system 100 including a distribution apparatus communicatively connected to a computerized apparatus and operable to receive a digital asset to load it to the computerized apparatus, includes: a digital asset management system connected to the distribution apparatus through a first secure communication channel and operable to generate the digital asset to conditionally transmit it to the distribution apparatus; and a provisioning controller connected to the distribution apparatus through a second secure communication channel and connected to the digital asset management system through a third secure communication channel and operable to instruct the digital asset management system to transmit the digital asset to the distribution apparatus. The computerized apparatus does not fully function before the digital asset is loaded.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims the benefit of U.S. Provisional Patent Application No. 62 / 421,878, filed on November 14, 2016, U.S. Provisional Patent Application No. 62 / 421,852, filed on November 14, 2016, and U.S. Provisional Patent Application No. 62 / 487,909, filed on April 20, 2017, all of which are hereby incorporated by reference in their entirety.

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

Background Art

[0003] As computers become increasingly miniaturized and commoditized, manufacturers are producing an ever - more diverse range of devices that include one or more embedded computers or processors. The computers within computerized devices can, among other things, control the operation of the device, collect, store, and share data, communicate with other computers and other computerized devices, and update their own software.

[0004] The Internet of Things (IoT) is a network of computerized physical devices that incorporate processors, electronics, software, data, sensors, actuators, and / or network connectivity, enabling these devices to be connected and exchange data via digital networks including the Internet, cellular phone networks, and other wireless networks. Typically, each "thing" is uniquely identifiable through its embedded computing system and can interoperate within the existing Internet infrastructure.

[0005] In the context of IoT, "things" can refer to a variety of computerized devices, such as, among others, household appliances, enterprise devices used in business and corporate environments, manufacturing machinery, agricultural equipment, energy-consuming devices in homes and buildings (such as switches, sockets, light bulbs, TVs, etc.), medical and healthcare devices, infrastructure management devices, robots, drones, and transportation devices and vehicles.

[0006] For example, most modern vehicles (such as cars, trucks, airplanes, trains, ships, etc.), if not all, include some embedded processors or embedded computers within their subsystems and are computer-controlled in at least some aspects. Similarly, an increasing number of modern transportation infrastructure devices (such as traffic lights, traffic cameras, traffic sensors, bridge monitors, bridge control systems, etc.) include 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 to exchange various types of information, and in order to operate safely, correctly, efficiently, and reliably, they can react to, respond to, change their operations, or depend on the information received / sent between other vehicles in vehicle-to-vehicle (V2V, also called C2C, inter-vehicle) communication and / or between vehicles and infrastructure elements in vehicle-to-infrastructure (V2I, also called C2I, vehicle-infrastructure) communication.

[0007] Computers within 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 appropriate software, firmware, executable instructions, digital certificates (e.g., public key certificates), and cryptographic keys, etc. (hereinafter collectively referred to as "digital assets" or "software") as intended by the manufacturer, so IoT consists only of devices that are running authorized and verified software and data. However, problems occur when unauthorized persons or organizations (e.g., hackers) exchange or modify the software within computerized devices. Also, problems occur when old software, untested software, unauthorized software, and / or software with known bugs is installed in computerized devices.

[0008] Therefore, there is a desire to provide improved systems, methods, and technologies for securely provisioning digital assets within computerized devices to prevent computerized devices from operating with software and data that is error-sensitive, malfunctioning, untested, maliciously modified, or otherwise undesirable. SUMMARY OF THE INVENTION

[0009] Systems, methods, and apparatus systems for securely provisioning one or more computerized devices are disclosed herein. In various embodiments, the system includes a first delivery device communicatively coupled to a computerized device and operative to receive a digital asset and load the digital asset into the computerized device, a digital asset management system connected to the delivery device via a first secure communication channel and operative to generate a digital asset and conditionally transmit the digital asset to the delivery device, and a provisioning controller connected to the delivery device via a second secure communication channel and connected to the digital asset management system via a third secure communication channel and operative to instruct the digital asset management system to transmit the digital asset to the delivery device. Because there is no digital asset, the computerized device may not function or may only partially function until 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.

[0010] In various embodiments, the system further includes a second delivery device connected to the digital asset management system via a fourth secure communication channel and communicatively coupled to the computerized device after the first delivery device is disconnected, operative to receive a second digital asset and load the second digital asset into the computerized device, and the provisioning controller is further operative to instruct the digital asset management system to transmit the second digital asset to the delivery device. The computerized device can become fully functional after the second digital asset is loaded into the computerized device.

[0011] In various embodiments, the digital asset management system includes one or more virtual machines communicatively connected to one or more computing engines that execute a registration office application and perform cryptographic calculations required by the registration office application, one or more virtual machines communicatively connected to one or more computing engines that execute a registration certification authority application and perform cryptographic calculations required by the registration certification authority application, one or more virtual machines communicatively connected to one or more computing engines that execute an alias certification authority application and perform cryptographic calculations required by the alias certification authority application, one or more virtual machines communicatively connected to one or more computing engines that execute a first cooperation station application and perform cryptographic calculations required by the first cooperation station application, and the one or more virtual machines communicatively connected to one or more computing engines that execute a second cooperation station application and perform cryptographic calculations required by the second cooperation station application.

[0012] In other embodiments, the digital asset management system can further include a database operably connected to one or more virtual machines that execute a registration office application, one or more virtual machines that execute a registration certification authority, one or more virtual machines that execute an alias certification authority application, one or more virtual machines that execute a first cooperation station application, and one or more virtual machines that execute a second cooperation station application.

[0013] In yet other embodiments, the system further can include a portal operably connected to the provisioning controller that authenticates a manufacturer of a computerized device and enables the manufacturer to manage provisioning of the computerized device, and / or a portal operably connected to the provisioning controller that authenticates an installer of a computerized device and enables the installer to manage provisioning of the computerized device, and / or a portal operably connected to the provisioning controller that authenticates a regulator of a computerized device and enables the regulator to manage provisioning of the computerized device.

[0014] In yet other embodiments, the provisioning controller can be further operable to send a digital asset (e.g., an executable software image) to a delivery device for loading onto a computerized device. In yet other embodiments, the provisioning controller can be further operable to create and maintain a log associated with a digital device and storing information regarding provisioning activities of the digital device, and the delivery device can be further operable to send information regarding provisioning activities associated with the digital device to the provisioning controller for storage in the log.

[0015] In yet other embodiments, the provisioning controller can be further operable to authenticate a digital device before instructing the digital asset management system to send the digital asset.

Brief Description of the Drawings

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

[0017]

Figure 1

[0018]

Figure 2

[0019]

Figure 3

[0020]

Figure 4A

[0021]

Figure 4B

[0022]

Figure 5

Embodiments for Carrying Out the Invention

[0023] Here, various embodiments of the present invention will be referred to in detail, and examples thereof are shown in the accompanying drawings. Whenever convenient, the same reference numerals are used throughout the drawings to refer to the same or similar parts.

[0024] To ensure safe and proper operation in the field, embedded devices (e.g., electronic control units (ECUs) used in vehicles) need to be properly initialized during manufacturing by provisioning digital assets such as security assets. Digital assets can include various encryption keys, unique identifiers, digital certificates, and software. In most cases, the origin of these digital assets and the manufacturing factory are in geographically different locations, and these locations have conventionally been interconnected via insecure Internet communications. Therefore, it is desirable to create an end-to-end secure channel from the origin of these digital assets to the device so that the digital assets are not accessed or modified by malicious actors or accidentally.

[0025] Conventional network security protocols for end-to-end protection such as TLS / SSL have the drawback that a pre-shared key or specific secret security material needs to exist in advance on both communication sides. This causes periodic technical problems in that some initial secret material must exist in advance for provisioning digital assets. This problem includes how to protect the initial secret material. To simplify logistics, usually a single version of the initial software is loaded onto computerized devices during manufacturing, so this problem is particularly acute for computerized devices. If the initial security material needs to be included in this initial software, a global secret must exist. As a result, exposing the initial security material would lead to the leakage of all digital assets provisioned on all devices since 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.

[0026] Provisioning generally refers to a series of actions taken to prepare a computerized device with appropriate data and software. It can also include a series of actions taken to properly install the device in its operating environment and prepare it for operation. The actions include loading appropriate digital assets (e.g., operating systems, device drivers, middleware, applications, digital certificates, etc.) into the digital storage (e.g., memory) of the device and, if necessary, appropriately customizing and configuring specific digital assets that may be unique to each particular device on the device. The actions can also include verifying that the computerized device is a legitimate device made by a legitimate device manufacturer and not a copied or counterfeited device.

[0027] The actions can also include properly installing the device in its operating environment and testing it to verify that the device is operating correctly. The fact that a device is built by one manufacturer and may later be installed in a larger system or device by another manufacturer (e.g., an on-board unit (OBU) made by a component manufacturer may be installed in a vehicle made by an automobile manufacturer) makes the function of securely provisioning only devices whose safety has been confirmed complex. An inappropriately installed device may not function correctly. The fact that a device is built by one manufacturer and may later be installed in a larger system or device by another manufacturer (e.g., an on-board unit (OBU) made by a component manufacturer may be installed in a vehicle made by an automobile manufacturer) makes the function of securely provisioning only devices whose safety has been confirmed complex. An inappropriately installed device may not function correctly.

[0028] Various embodiments consistent with the present invention provide for the secure provisioning of computerized devices, including IoT devices. Such embodiments help prevent or prohibit malicious, negligent, or accidental tampering, modification, updating, or release of digital assets used by computerized devices and prevent or prohibit inappropriate installation of computerized devices and their software.

[0029] Various embodiments consistent with the present invention can also generate audit logs, records, reports, etc. of the secure provisioning process, which can be used to analyze and solve problems discovered later.

[0030] Various embodiments consistent with the present invention can also provide a secure provisioning and management platform that can be provided as a service to equipment and system manufacturers.

[0031] FIG. 1 is a block diagram showing an example of a system 100 for secure provisioning of a computerized device in accordance with an embodiment of the present invention. As shown in the example of FIG. 1, system 100 includes a provisioning controller 120. The provisioning controller 120 can be implemented as a server computer having an embedded hardware security module (HSM) (e.g., having at least one processor and associated memory) that securely generates and stores digital security assets and securely performs various encryption and confidential computations. The HSM protects digital security assets such as cryptographic keys and other confidential data from access by potential attackers. In various embodiments, the provisioning controller 120 functions to authenticate the users of system 100 and communicate securely with them, communicate securely with and manage one or more delivery devices 108, 131, communicate securely with and direct the operation of a digital asset management system (DAMS) 110, function to create and store provisioning records, function to create, store, and distribute provisioning records, function to create, store, and distribute audit logs, function to create and distribute certificates to cryptographically bind the elements of DAMS 110 and delivery devices 108, 131, function to invalidate them if necessary when the users and managed devices become untrusted, and function to create and distribute secure encrypted backups of critical keys and data for off-site storage for business continuity and disaster recovery.

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

[0033] The provisioning 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 provisioning controller 120. In various embodiments, the staff 109 of the device manufacturer 105 can use the manufacturer's user portal 115 to interface with the provisioning controller 120 (and thus the DAMS 110) and manage their device provisioning activities. In various embodiments, the manufacturer's user portal 115 can collect identification information such as usernames, passwords, two-factor identification data, face recognition images, fingerprints, etc. from the staff user 109 and provide the identification information to the provisioning controller 120. It can. The provisioning controller 120 can authenticate the staff 109 before enabling the staff 109 to access the secure provisioning system 100. For example, the provisioning controller 120 can search for the identification information associated with the staff 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 provisioning controller 120 or the DAMS user portal 115 may be integrated with the user's corporate identification and authentication system to determine whether the staff 109 is authorized to use the system 100. In various embodiments, the provisioning controller 120 or the DAMS user portal 115 can assign roles to the staff 109 that have successfully authenticated and restrict their actions within the system 100. In some embodiments, the provisioning controller 120 can enable access only if the two sets of identification information match.

[0034] Similarly, the provisioning controller 120 is also communicatively connected to an installer user portal 116 that can be implemented, for example, as a server or as an interface to the provisioning controller 120. In various embodiments, the staff 132 of the equipment installer can use the installer user portal 116 to interface with the provisioning controller 120 (and thus the DAMS 110) and manage their equipment installation and provisioning activities. The provisioning controller 120 can authenticate the staff 132 before authorizing them and assign roles to them before enabling the staff 132 to access the secure provisioning system 100 and perform functions authorized on the system.

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

[0036] The provisioning controller 120 is further communicatively connected to the DAMS 110. In various embodiments, the DAMS 110 can be implemented as a server, a device, or a system of secure devices and / or servers. The DAMS 110 securely retrieves public keys from the end entity devices to be provisioned via the distribution devices 108, 131, or other secure and authenticated connections, and securely supplies the digital certificates and related data installed on the device 106. Also, the DAMS 110 securely receives status information regarding the provisioning, installation, functionality, etc. of the computerized device 106 from the manufacturer 105 and the installer 130 via the distribution devices 108, 131. Further, the DAMS 110 can perform this provisioning at a single site or multiple sites as shown in FIG. 1. As will be described in more detail with respect to FIG. 4, the DAMS 110 can include the following main elements: a root certification authority (CA), a policy generator, a CRL generator, a misbehavior bureau, an intermediate CA, a registration CA, a coordination bureau, a pseudonym CA, and a registration bureau.

[0037] DAMS110 adds new functionality and improves the components and functionality described in the December 2013 paper "Secure Certificate Management System for V2V Communication" by William Whyte et al. in the 2013 IEEE Vehicular Networking Conference. In various embodiments, DAMS110 includes multi-stage programming and flexible management (e.g., enabling inclusion of regulator 140). Various embodiments of DAMS110 also enable a single DAMS110 to provide different levels of provisioning to different subscribers. Various embodiments of DAMS110 also enable subscribers to assign the use of different digital certificates as well as the loading of different certificates (such as one week instead of three years as in conventional systems) during a certain period (e.g., per week). Various embodiments of DAMS110 may also provide subscriber-specific URLs so that certain manufacturer-computerized devices 106 (e.g., OEM automobiles) can remain within the manufacturer's scope (e.g., their URLs indicate their names).

[0038] As shown, the provisioning controller 120 is also communicatively connected to the distribution devices 108, 131. In various embodiments, the distribution devices 108, 131 can be implemented, among other things (as shown), as stand-alone secure devices installed on a company's premises or as web services or cloud services. In various embodiments, the distribution devices 108, 131 are preferably implemented as reliable endpoint devices that securely transmit and receive digital assets and other information between the DAMS 110 and the provisioning controller 120 via a dedicated non-Internet communication channel. As shown, the distribution devices 108, 131 are also connected, either directly or indirectly, to the devices 106a, 106b to download digital assets to the devices 106a, 106b and receive data therefrom. In various embodiments, the distribution devices 108, 131 can be implemented as a box including a server computer having a hardware security module, a hardened operating system (OS), an internal firewall, and an internal host intrusion detection / defense system (e.g., having at least one processor and associated memory). The distribution devices may be specifically designed to operate in an untrusted environment and still provide trusted and reliable operation. The distribution devices have a secure communication channel between themselves and the secure provisioning controller 120 and DAMS 110. This channel is used to control the distribution devices and transmit and receive provisioning-related data and log information. The distribution devices can also have a secure communication channel to the tester 107 used to program or provision the devices 106. This channel protects against the leakage or alteration of provisioning data and log data on the communication network at the manufacturing site. The distribution device 108 can also establish a direct secure communication channel with the device 106 that is programmed so that the provisioning data cannot be endangered or altered by a third party (including an unauthorized tester 107).In various embodiments, the delivery device can collect from the device 106 it is attempting to provision, other data such as a public key and the serial number of the microprocessor. The delivery device can send this information to the provisioning controller 120 and / or the DAMS 110. The delivery device can also receive data, commands, and other information from the provisioning controller 120 and / or the DAMS 110 for programming within the device 106. The delivery device can return its own log data, and the delivery device can return data from the tester 107 to the provisioning controller 120 and / or the DAMS 110.

[0039] As shown with respect to the device manufacturer 105, the delivery device 108 can be communicatively connected to a tester 107 (e.g., a computerized manufacturing apparatus, product inspection equipment, etc.), which in turn is connected to a device 106a manufactured by the manufacturer 105, such as an OBU device. The manufacturer 105 can 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 can be an embedded universal integrated circuit card (eUICC) used in a cellular modem for electrical communication that is later incorporated as part of an on-board unit (OBU) installed in a vehicle for communication between the vehicle and traffic infrastructure devices. It can also be a V2V secure microprocessor mounted on the OBU for communicating with other vehicles and roadside units (RSUs). These newly manufactured devices 106a must be properly provisioned by digital assets (e.g., digital certificates from the DAMS 110) to operate properly. The staff 109 of the manufacturer 105 can use the user portal 115 to interact with the provisioning controller 120 and manage the product provisioning activities by the DAMS 110.

[0040] ​As shown with respect to installer 130, while or after device 106b is installed in its operating environment, distribution device 131 may alternatively be communicatively connected directly to device 106b. Installer 130 may include or be a factory or store that installs computerized devices 106b within their operating environments (e.g., installs an OBU within a motor vehicle). At installation, the computerized devices 106b must be further appropriately provisioned with digital assets (e.g., additional digital certificates from DAMS 110) in order to operate properly. The staff 132 of installer 130 can use the installer user portal 116 to interact with the provisioning controller 120 and manage product provisioning activities by DAMS 110.

[0041] In various embodiments, the provisioning controller 120, the distribution devices 108, 131, and the DAMS 110 can have a secure and non-publicly accessible communication link or channel between them, and in various embodiments, all of the communication links shown in FIG. 1 can be communication channels that are secure and non-publicly accessible. In various embodiments, 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 the inner layer remains secure even if the outer layer is exposed to danger in some way. As an example, a mutually authenticated TLS tunnel can be used as an outer layer along with an inner layer using another protocol such as its own secure communication protocol. These secure connections between the infrastructure components including the system 100 are used to protect the confidential communication between the components and ensure their correct operation. Using these secure paths, the provisioning controller 120 and the DAMS 110 can transmit digital data between components without worrying about it being leaked or modified during transfer. Commands and control information can also be passed through these channels. For example, the provisioning controller 120 can control which distribution devices 108, 131 to send specific digital assets and data to. It can also instruct the distribution devices 108, 131 on how to meter this data to the devices 106 on the manufacturing line it is being provisioned for. Further, the distribution devices 108, 131 can report information back to the provisioning controller 120 without worrying about the information being leaked or modified during transmission. For example, the secure provisioning controller 120 can program the distribution devices 108, 131 to provision up to 10,000 devices using any type of digital asset (e.g., certificates, software, fuse content, etc.).The delivery devices 108, 131 can count the devices they are provisioning and, when they reach their limit, report this to the provisioning controller 120. In various embodiments, the devices (e.g., 108, 110, 131, 115, 116, 117) managed by the provisioning controller 120 include a function to disable them if they do not communicate regularly with the provisioning controller 120 and thus if they are stolen and rendered inoperable. This function prevents devices that have been lost / stolen from continuing to operate and provisioning the device 106 as if they were still in a proper manufacturing environment. The devices (e.g., 108, 110, 131, 115, 116, 117) managed by the provisioning controller 120 include a function to disable them if they do not communicate regularly with the provisioning controller 120 and thus if they are stolen and rendered inoperable. This function prevents devices that have been lost / stolen from continuing to operate and provisioning the device 106 as if they were still in a proper manufacturing environment.

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

[0043] After it is initially provisioned, the manufacturer 105 ships the device 106a to the installer 130, and the installer 130 installs the device 106b. In various embodiments, prior to the initial provisioning, the device 106a is non-functional, and after the initial provisioning by the manufacturer 105, the device 106a can function partially but is not yet fully functional. In such embodiments, the initial provisioning makes the device functional only to the extent necessary for installation and further final provisioning, which is necessary to make it fully operational.

[0044] The installer 130 installs the device 106b within its operating environment, and a staff member 132 of the installer 130 notifies the provisioning controller 120 of that fact via the installer portal 116. This notification serves to prove that the installation was completed correctly and preferably includes information that uniquely identifies the device 106b to the provisioning controller 120. In some embodiments, the distribution device 131 can automatically notify the provisioning controller 120 after querying the device 106b for status and identification information. In various embodiments where the installer 130 proves via the installer portal 116 that it has properly installed the device 106b, this proof may be recorded / saved in the database 125 by the provisioning controller 120. The proof may include specific test data associated with each particular installed device 106b, such as wireless transmission power measurements or verification of GPS antenna position.

[0045] In response to the setup notification, the provisioning controller 120 verifies that (i) the device 106b is listed in its database 125 as a device lawfully manufactured by the manufacturer 105, (ii) the device 106b is listed in its database 125 as having been first successfully provisioned by the manufacturer 105, and (iii) the installer 130 is listed in its database 125 as an approved installer. If this verification is successful, the controller 120 instructs the DAMS 110 to send digital assets (e.g., pseudonym certificates (PCs)) and / or other information necessary to operably provision the device 106b so that it can function properly when installed within its operating environment.

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

[0047] In various embodiments, installer 130 must be authenticated as being authorized by provisioning controller 120 in order to interact with system 100. To be authorized, installer 130 may, for example, have to enter into an appropriate contract document that describes the proper installation of device 106b in a target environment (e.g., a target vehicle or site). Installer 130 may, for example, be required to demonstrate other contractual elements by regulator 140. Preferably, each installer 130 has a unique ID within system 100 such that its actions can be uniquely recorded by provisioning controller 120.

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

[0049] One of ordinary skill in the art will understand that the details of the components, processes, data, operations, and embodiments shown in FIG. 1 are examples presented for the sake of brevity and clarity of explanation. This example is not intended to be limiting, and since many variations are possible, other components, processes, details of embodiments, and variations can be used without departing from the principles of the present invention. For example, FIG. 1 shows only one manufacturer 105, only one installer 130, and only one regulator 140, but other embodiments can have any number of each of these entities. In another example, DAMS 110 and the provisioning controller 120 are shown as separate devices, but other embodiments may combine their functions into a single device (e.g., a single server). As yet another example, the same can be done for portals 115 - 117. In yet another example, the system 100 can further include an asset management device (AMA, not shown) as described in U.S. Provisional Patent Application No. 62 / 421,852, which is incorporated by reference as of November 14, 2016. In such an embodiment, the AMA can be communicatively connected to the provisioning controller 120 and / or the distribution devices 108, 131 and / or DAMS 110. In various embodiments, the AMA can include a user - friendly GUI and functions that enable a production coordinator to easily and efficiently manage the configuration and construction of a product (e.g., device 106) and enable an asset owner to easily and efficiently manage the inventory of digital assets.

[0050] FIG. 2 is a swim - lane diagram showing an example of a process 200 for securely provisioning a computerized device in accordance with an embodiment of the present invention. In various embodiments The illustrated process 200, or a part or all of the operations, may be executed by code running 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 traversing up in FIG. 2, entities involved in process 200 include manufacturer 105 of computerized device 106, distribution device 108 located at manufacturer 105, provisioning controller 120, and DAMS 110. In various embodiments, these entities can be as described with respect to FIG. 1 and throughout the present disclosure and can communicate with one another as such.

[0051] As shown in the example of FIG. 2, process 200 begins at 205 where a manufacturer 105 (e.g., staff member 109) requests a digital asset provisioning service from provisioning controller 130, where the digital asset is provisioned to (e.g., used by) device 106a, and the request can identify device 106a which is the destination of the digital asset. The request can be, for example, whether manufacturer 105 is requesting a provisioning service for a new product 106 or may be making a new provisioning service request for an existing product 16. In various embodiments, this operation can include an authorized user logging on to provisioning controller 130, for example, via user portal 115. In some cases, the requested digital asset can be, for example, security credential information such as a registration certificate, executable code that device 106 executes, digital operation parameters, etc. The registration certificate is such that all participants need to share a valid registration certificate (e.g., in the USDOT's V2X ecosystem), and an authorized participant can also receive a pseudonym certificate that enables communication and operation of devices 106 within the ecosystem (e.g., in the example of the USDOT's V2X ecosystem, to enable communication and operation between vehicles and roadside infrastructure), and it is a public key certificate that identifies its owner as an authorized participant within the ecosystem.

[0052] At 210, provisioning controller 120 determines whether the user from manufacturer 109 is an authorized user. In some embodiments, provisioning controller 120 can also, at 210, determine whether the device 106a (e.g., product) to be provisioned is authorized to be used with system 100. In some cases, a list of authorized devices can be provided by regulator 140 of FIG. 1 and used by provisioning controller 120 to make this determination.

[0053] If the user (and / or product) is not authorized, the provisioning controller 120 rejects the request for the digital asset provisioning service (not shown in FIG. 2). On the other hand, if an authorized user is making a request (210, yes), for example, for an authorized product, the provisioning controller 120 instructs, commands, or otherwise controls the DAMS 110 to satisfy the service request, for example, by sending a service request command to the DAMS 110 at (215).

[0054] At 220, in response to and conditional on receiving the request from 215, the DAMS 110 configures itself to start the service to the device 106a based on that request. In some embodiments, the DAMS 110 can also send commands to the distribution device 108 (not shown) to configure the distribution device 108 to provide the service to the device 106a.

[0055] At 222, the DAMS 110 generates, creates, calculates, and / or searches for digital assets for the device 106a as requested at 205. In various embodiments the DAMS 110 can create or generate requested digital security assets such as a public and private key pair, as well as a registration certificate and pseudonym certificate for the device 106a.

[0056] In an alternative embodiment of operation 222 (not shown in FIG. 2), the DAMS 110 requests and receives from the distribution device 108 digital asset generation information related to the device 106a, for example, registration and pseudonym public keys generated by or retrieved from the device 106a, and data that uniquely identifies the device 106a (e.g., the serial number of the microprocessor). In such an embodiment, the DAMS 110 then uses the registration and pseudonym public keys to generate digital assets (e.g., a registration certificate and an appropriate number of pseudonym certificates for the device 106a).

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

[0058] At 226, DAMS 110 transmits log information regarding the digital assets to the provisioning controller 120. In various embodiments, the log information can include information describing the request and transfer of digital assets such as, for example, the ID of the requester, the ID of the digital asset, the ID of the distribution device, the timestamps of the request and transmission actions, the serial number of the received microprocessor, etc. In some embodiments, the log information can include a copy of the digital asset. At 227, the provisioning controller 120 receives the log information and stores it, for example, in the database 125. In practice, the provisioning controller 120 maintains an audit trail of all activities occurring within the system 100, thereby enabling the assembly of many types of data, such as data regarding how and when the device 106a can be built and provisioned by the manufacturer 105. Such data and log information may be used for billing and auditing purposes.

[0059] At 230, the distribution device 108 receives and stores the digital assets (e.g., a public and private key pair, a registration certificate, and an alias certificate) transmitted by DAMS 110.

[0060] At 235, the distribution device 108 requests and receives from device 106a digital security assets such as public keys that can be used to securely transfer digital assets from the distribution device 108 to device 106a. Various types of device 106a may have the ability to generate an ephemeral key pair, perhaps using a secure processor built into device 106, and the public key can be part of the ephemeral key pair. At 240, the distribution device 108 uses the digital security asset (e.g., public key) to securely send a digital asset (e.g., certificate of registration) to device 106a. In various embodiments, the distribution device 108 can use the public key of device 106a to, for example, form a virtual private network (VPN) with device 106a and securely send digital assets therein.

[0061] In various embodiments, the distribution device 108 can use transport layer security (TLS) with the tester 107 to protect communication with the tester 107 that can be connected to device 106a. In an embodiment where it is desirable to directly perform secure communication with device 106a, the system can create an ephemeral public key pair on device 106a and use the public key thereof together with a certificate from the distribution device 108 that includes the public key of the distribution device 108 to create a secure tunnel to device 106a. In such an embodiment, device 106a executes special code using the root public key of the system 100 therein to verify the certificate sent thereto by the distribution device 108.

[0062] Once a secure path is established between device 106a or tester 107 and distribution device 108, device 106a creates a registration and pseudonym public key pair (for example, for the V2X ecosystem), exports the public key and other data to distribution device 108, and distribution device 108 can then send this data to DAMS 110 and provisioning controller 120. As described above with respect to the alternative embodiment of operation 222, DAMS 110 can create a registration certificate and a pseudonym certificate using the received public key, and in some embodiments, there can be a large number (for example, 3,000) of pseudonym certificates. In this alternative of one embodiment, DAMS 110 returns these certificates to distribution device 108 in operation 225 as described above. In some other embodiments, DAMS 110 can send these certificates to distribution device 131 instead of 108, depending on where the provisioning is being performed.

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

[0064] Device 106a receives a digital asset and stores it for use during operation. For example, if device 106a is an on-board unit (OBU) or an electronic control unit (ECU) in a vehicle and the digital asset is a security asset (for example, a public key certificate) required to participate in a wireless network, the digital security asset is stored by the OBU. When the OBU is later installed in the vehicle and activated, it attempts to connect to the wireless network. Before the OBU can connect to the network, the network attempts to authenticate the OBU. The OBU can authenticate and participate in the network only if it has the digital security asset provided by distribution device 108 at manufacturer 105.

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

[0066] At 250, the distribution device 108 transmits the status information to the provisioning controller 120. Then, at 255, the provisioning controller 120 receives and stores the status information in relation to the log information stored in operation 227. Thus, the provisioning controller 120 maintains an audit trail or audit log for all activities of the system 100 associated with each particular device 106. In various embodiments, the audit log can include, for each device 106, information indicating the success (e.g., operations 235 - 245) or failure of the manufacturer's provisioning, the identification information of the digital asset (and / or a copy of the digital asset itself), the type of encryption, etc.

[0067] 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 the company that installs the device in its operating environment (e.g., the installer company 130 of FIG. 1). In some embodiments, the device 106a may be fully programmed or provisioned at this point and may be capable of operating with full functionality. On the other hand, in other embodiments, the device 106a may be only partially programmed or provisioned at this point and may not be able to operate with full functionality or may not function at all.

[0068] The example shown in FIG. 2 is for illustrative purposes only and is not intended to be limiting. Further, the illustrated process 200 is an example that has been somewhat simplified to clarify the description of a particular novel and innovative configuration that corresponds to a particular disclosed embodiment, but this example is not intended to be limiting and many variations are possible. For example, the functions and operations are shown to be performed in a particular order, but the described order is merely an example and various different operation sequences can be performed that do not conflict with the particular disclosed embodiment. Further, the operations are described as separate steps for illustrative purposes only, and in some embodiments, multiple operations can be performed simultaneously and / or as part of a single calculation or larger operation. The described operations are not intended to be exhaustive, limiting, or absolute, and various operations can be modified, inserted, or deleted. As an example of a variation, FIG. 2 is generally described in the context of a single digital asset (e.g., a single digital certificate), but the system and process function similarly to process multiple digital assets (e.g., two or more digital certificates). As another example, if device 106a does not have a secure communication function, operations 235 and 240 can be deleted and distribution device 108 can communicate with device 106b using unencrypted communication.

[0069] As yet another example, in various embodiments, a provisioning controller 120, or a delegated authority such as a dedicated signing device, may similarly send to the distribution device 108 to cause the device 106b to load another or additional digital assets including digital assets such as software, firmware, fuse BLOBs, manifest files, etc. In such embodiments, the provisioning controller 120 can additionally or alternatively search, obtain, or otherwise access, or direct access to, the requested digital assets from storage. For example (not shown in FIG. 2), the provisioning controller 120 or its authorized delegate may search for an executable software image (e.g., a compiled computer program stored in the database 125) to be loaded and executed on the device 106a, and send the executable software image to the distribution device 10 to program it into the device. In various embodiments, the digital assets accessed by the provisioning controller 120 may consist only of software that has been securely supplied, released, and / or authorized by the manufacturer 105 of the device 106a so that unauthorized software cannot be loaded into the device 106a. In some embodiments, the digital assets retrieved by the provisioning controller 120 may be stored in a storage device or database associated with the provisioning controller 120, such as the database 125 of FIG. 1.

[0070] Figure 3 is a swimlane diagram showing an example of process 200 for securely provisioning a computerized device in accordance with an embodiment of the present invention. In various embodiments, process 300 or some or all of the illustrated operations can be performed by code running 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 shown across the top of Figure 3, the entities involved in process 300 include installer 130 of computerized device 106, distribution device 131 deployed by installer 130, provisioning controller 120, and DAMS 110. In various embodiments, these entities can be as described with respect to Figure 1 and throughout the present disclosure and can communicate with each other as such.

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

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

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

[0074] 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 FIG. 3). On the other hand, if an authorized user makes a request (320, yes), the provisioning controller 120 determines whether the device 106b identified by the installation status data is an authorized device (325). In some embodiments, the provisioning controller 120 can determine that the device 106b is authorized by verifying its database 125 against previously stored information that 1) a record for the device 106b exists within its database 125, 2) the record indicates that the device 106b was successfully provisioned by the manufacturer 105, and 3) the record indicates that the device 106b was sent to the installer 130 (verified as the installer authorized at 320).

[0075] If the device identified by the installation status data is not authorized, the provisioning controller 120 rejects the installation status communication (not shown in FIG. 3). On the other hand, if the device 106b identified by the installation status data is authorized (325, yes), the provisioning controller 120 stores the installation status data together with the log information associated with the device 106b at 330. For example, the log information associated with the device 106b may have been previously stored in the database 125 as described with respect to operation 227 of FIG. 2.

[0076] At 335, the provisioning controller 120 instructs, commands, or otherwise controls the DAMS 110 to satisfy the provisioning request (e.g., by sending a request to provision the device 106b at the installer 130 to the DAMS 110). At 340, in response to and conditional upon receiving the request from 335, the DAMS 110 generates and / or retrieves the digital asset requested at 335. In various embodiments, the DAMS 110 can create or generate the requested digital asset, such as a pseudonym certificate or other public key certificate, as described with respect to FIG. 2. In various embodiments, the DAMS 110, or the provisioning controller 120 instead of the DAM 110, can additionally or alternatively search, obtain, or otherwise access the requested digital asset from storage, such as an executable image previously stored in the database 125 for use on a device of the type of device 106b. As described with respect to FIG. 2, the DAMS 110 can create or generate the requested digital asset, such as a pseudonym certificate or other public key certificate. In various embodiments, the DAMS 110, or the provisioning controller 120 instead of the DAM 110, can additionally or alternatively search, obtain, or otherwise access the requested digital asset from storage, such as an executable image previously stored in the database 125 for use on a device of the type of device 106b.

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

[0078] At 350, the distribution device 131 performs the same or similar operations as operations 230 - 245, as described with respect to FIG. 2. At 355, the distribution device 131 sends status information to the provisioning controller 120. Then, at 360, the provisioning controller 120 receives and stores the status information related to the information previously stored related to the device 106b, such as the status information stored in operation 227. Thus, the provisioning controller 120 maintains an audit trail or audit log for all activities of the system 100 associated with each particular device 106.

[0079] The process 300 shown in FIG. 3 is an example for illustrative purposes and is not intended to be limiting. Further, the illustrated process 300 is a somewhat simplified example for clarifying the description of a particular novel and innovative configuration that conforms to the disclosed particular embodiments, but many variations are possible. For example, the functions and operations are shown to be performed in a particular order, but the described order is merely an example, and various different operation sequences can be executed that do not conflict with the disclosed particular embodiments. Further, the operations are described as separate steps merely for purposes of explanation, and in some embodiments, multiple operations can be performed simultaneously and / or as part of a single calculation or larger operation. The described operations are not intended to be exhaustive, limiting, or absolute, and various operations can be modified, inserted, or deleted.

[0080] Both FIGS. 4A and 4B are block diagrams of an example of a system 400 for implementing a scalable and secure digital asset management system according to an embodiment of the present invention. Various embodiments of the system 400 can be used for extremely large amounts of device transactions and certificate generation processing. In various embodiments, the system 400 can be implemented using a plurality of servers, hardware security modules, a plurality of computing engines or computing engines, and a plurality of virtual machines (VMs). Examples of the system 400 can be implemented in a private data center, a cloud data center (e.g., AWS), or a hybrid of a private data center and a cloud data center.

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

[0082] As shown in the example of FIG. 4, this architecture can include two provisioning controllers 120 (i.e., primary and standby, preferably implemented on separate servers). The two provisioning controllers 120 include functions such that objects, data, etc. included in the primary provisioning controller are copied or otherwise included in the standby (secondary) provisioning controller. If the primary provisioning controller goes offline for some reason then the standby provisioning controller can be brought online to replace the primary provisioning controller. This provides continuous (or very high) availability of the provisioning controller 120. In various embodiments, the primary provisioning controller and the standby provisioning controller can be as described with respect to FIG. 1 and other sections of this disclosure. In various embodiments, the provisioning controller 120 can be connected to the system 400 in the same or a similar manner as described herein with respect to the connection and communication between the provisioning controller 120 and the DAMS 110 of FIG. 1. Generally, the provisioning controller 120 manages the system elements that make up the infrastructure so that only explicitly authorized elements can participate in the interaction with the system 400. In various embodiments, the provisioning controller 120 can be integrated with an employee identification and authorization system for users (e.g., the manufacturer 105 or the installer 130), or can provide its own functions for identification and authorization so that only authorized users can use the system 400.

[0083] The architecture of system 400 separates non-security related applications from security functions. As shown in this example, the registration office 420, the certification authorities 430, 440, and the cooperation stations 450, 460 are implemented as applications on their own virtual machines running on their own dedicated computing engines 425, 435, 445, 555, 465, all of which are separated from applications and functions other than security related ones. This provides both technical and security advantages and improvements over conventional systems where the performance of the hardware security module is slow, or the cloud service provider cannot supply an HSM, or the proper management of the HSM is uncertain. As shown in FIG. 4, by separating important security functions from each other into separate computing engines, computationally intensive cryptographic and security functions (e.g., elliptic curve butterfly extension operations or elliptic curve digital signatures), such as those executed by the registration office 420, the certification authorities 430, 440, and the cooperation stations 450, 460, are executed much faster than in existing registration office systems. This design allows the "bottleneck" application to be extended as needed, thus significantly improving transaction processing. For example, if it is necessary to extend the registration office application running at 405 and 420, additional VMs can be added without changing the secure computing function at 425. Alternatively, if the security calculations are limiting performance, additional secure computing engines 425 can be added. The same multi-dimensional scaling applies to the other components of 400. This feature significantly improves performance over other existing SCMS systems.

[0084] In various embodiments, the registration authority 405 can be a station within a provisioning network that verifies user requests for digital certificates or other types of digital security assets, and can enable a certificate authority (e.g., certificate authorities 430, 440) to issue digital certificates. In various embodiments, the registration authority 405 can be similar to a registration authority known in a public key infrastructure (PKI) system. In various embodiments, the registration authority 405 can be implemented as a Representational State Transfer (REST) web service. As represented by the three "stacked" rectangles shown in FIG. 4 for the registration authority 405, in various embodiments, there may be multiple instances of the registration authority 405 running simultaneously. This is similarly represented for the other "stacked" elements in FIG. 4.

[0085] As represented by the "DB" arrow that appears at the lower left of the rectangle, the registration authority 405 (and other components in FIG. 4 indicated by the "DB" arrow) can connect to the database 470. In a preferred embodiment, the database 470 is a high-speed access, low-latency database. In some embodiments, the database 470 can be a NoSQL database or a database service (e.g., the DynamoDB data service provided by Amazon Web Services). It should be noted that the data stored in the database 410 depends on the application, but can include previously issued certificates, various coordination station values, data regarding the device on which the certificate was issued, operator actions, and the like. The data may be stored unencrypted, encrypted, or some combination thereof.

[0086] In the example shown in FIG. 4, the registration office 405 is connected to other components, and the other components are connected to each other by a messaging subsystem or service represented by box 410. In some embodiments, the messaging service 410 can be a high-speed message queuing service such as Amazon Simple Queue Service (SQS) provided by Amazon Web Services.

[0087] In various embodiments, the system 400 includes a registration certification authority 430 and a pseudonym certification authority 440 because the digital certificates generated by the registration office 405 are split into different segments (e.g., a registration digital certificate and a pseudonym digital certificate).

[0088] In various embodiments, the coordination stations 450, 460 link the identification information of the certificate requester (i.e., the unique identifier of the certificate requester's device) to the issued pseudonym certificate for the purpose of revocation.

[0089] In various embodiments, the computing engines 425, 435, 445, 455, and 465 and the provisioning controller 120 include a Hardware Security Module (HSM) that enables these components to perform secure computations without being overly threatened by hackers. In some embodiments, the computing engines 425, 435, 445, 455, and 465 can be designed to perform secure computations themselves without the need for an embedded HSM, and in such embodiments, they embody the HSM.

[0090] Those skilled in the art will understand that the components, processes, data, operations, and implementation details shown in FIG. 4 are examples presented for the sake of brevity and clarity of the description. This example is not intended to be limiting, and since many variations are possible, other components, processes, implementation details, and variations can be used without departing from the principles of the present invention.

[0091] FIG. 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 a system and method consistent with an embodiment of the present invention. Other components and / or arrangements can also be used. In some embodiments, computing system 500 can be used to implement at least in part the various components of FIGS. 1-3 (e.g., provisioning controller 120 and DAMS 110, among others). In some embodiments, a series of computing systems similar to computing system 500 can each be customized with dedicated hardware and / or programmed as dedicated servers for implementing one of the components of FIGS. 1-3 and can communicate with each other via network 535.

[0092] In the example shown in FIG. 5, computing system 500 includes many components such as a central processing unit (CPU) 505, memory 510, input / output (I / O) devices 525, a hardware security module (HSM) 540, and a non-volatile storage device 520. System 500 can be implemented in various ways. For example, (server, Implementations as an integrated platform (such as workstations, personal computers, laptops, etc.) can include a CPU 505, a memory 510, a non-volatile storage 520, and I / O devices 525. In such a configuration, components 505, 510, 520, and 525 can be connected and communicate via a local data bus and access a data repository 530 (implemented, for example, as a separate database system) via an external I / O connection. The I / O component 525 can be connected to external devices via a network such as a local area network (LAN) or a wide area network (WAN, such as a cellular phone network or the Internet), and / or via other suitable connections, and / or via a direct communication link (such as a wired or local WiFi connection). System 500 can be stand-alone or a subsystem of a larger system.

[0093] The CPU 505 can be one or more known processors or processing devices such as a Core (registered trademark) family microprocessor manufactured by Intel (registered trademark) Corporation of Santa Clara, California, or an Athlon (registered trademark) family microprocessor manufactured by AMD (registered trademark) Corporation of Sunnyvale, California. The memory 510 can be one or more high-speed storage devices configured to store instructions and information executed or used by the CPU 505 to execute the specific functions, methods, and processes related to embodiments of the present invention. The storage 520 can be a volatile or non-volatile, magnetic, semiconductor, tape, optical, or other type of storage device, or a computer-readable medium including devices such as CDs and DVDs, and a solid-state device intended for long-term storage.

[0094] In the illustrated embodiment, when executed by the CPU 505, the memory 510 includes one or more programs or applications 515 loaded from the storage 520 or a remote system (not shown) that execute various operations, procedures, processes, or methods consistent with the present invention. Alternatively, the CPU 505 can execute one or more programs located remotely from the system 500. For example, the system 500 can access one or more remote programs via the network 535 that execute functions and processes related to embodiments of the present invention at runtime.

[0095] In one embodiment, the memory 510 can include a program 515 for performing the special functions and operations described herein for the provisioning controller 120, DAMS 110, and / or the distribution devices 108, 131. In some embodiments, the memory 510 can also include other programs or applications that implement other methods and processes that provide auxiliary functions to the present invention.

[0096] The memory 510 can also be composed of other programs (not shown) unrelated to the present invention and / or an operating system (not shown) that performs some functions well-known in the art when executed by the CPU 505. By way of example, the operating system can be Microsoft Windows®, Unix®, Linux®, an Apple Computers® operating system, or other operating systems. The choice of operating system, and indeed the use of an operating system, is not important to the present invention.

[0097] The HSM 540 can be a device having its own processor that securely generates and stores digital security assets and / or securely performs various cryptographic and confidential calculations. The HSM 540 can be used for digital security assets such as cryptographic keys and other machines Protect the secret data from access by potential attackers. In some embodiments, the HSM can be a plug-in card or board directly attached to the computing system 500.

[0098] The I / O device 525 can include one or more input / output devices that enable the system 500 to receive and / or transmit data. For example, the I / O device 525 can include one or more input devices that enable data to be input from a user (such as a keyboard, touch screen, mouse, etc.). Further, the I / O device 525 can include one or more output devices that enable data to be output or presented to the user (such as a display screen, CRT monitor, LCD monitor, plasma display, printer, speaker device, etc.). The I / O device 525 can also include one or more digital and / or analog communication input / output devices that enable the computing system 500 to communicate (digitally, for example) with other machines and devices. Other configurations and / or some input devices and / or output devices can be incorporated into the I / O device 525.

[0099] In the illustrated embodiment, the system 500 is connected to a network 535 (such as the Internet, a private network, a virtual private network, a cellular phone network, or other network, or a combination thereof), and the network 535 can then be connected to various systems and computing machines (such as servers, personal computers, laptop computers, client devices, etc.). Generally, the system 500 can input data from external machines and devices via the network 535 and output data to external machines and devices.

[0100] In the exemplary embodiment shown in FIG. 5, data source 530 is a stand-alone database (e.g., database 125) external to system 500. In other embodiments, data source 530 can be hosted by system 500. In various embodiments, 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 a data structure including, for example, the status and log information of each device 106 provisioned by system 100.

[0101] Data source 530 can include one or more databases that store information and are accessed and / or managed through system 500. By way of example, database 530 can be an Oracle® database, a Sybase® database, or other relational database. However, the systems and methods according to the present invention are not limited to separate data structures or databases, or even to the use of databases or data structures.

[0102] Those skilled in the art will understand that the components and details of the embodiment of the system in FIG. 5 are examples presented for the sake of brevity and clarity of the description. Details of other components and embodiments may be used.

[0103] The foregoing examples use specific examples of computerized devices such as OBU, ECU, and RSU for the sake of clarity of the description, but the present invention is not limited to those specific examples. Various embodiments consistent with the present invention can be used with and for a wide variety of computerized devices, such as, among others, medical devices (e.g., dialysis machines, infusion pumps, etc.), robots, drones, autonomous vehicles, wireless communication modules (e.g., embedded universal integrated circuit cards (eUICC)).

[0104] Other embodiments of the present invention will be apparent to those of ordinary skill in the art from a consideration of the specification and the practice of the invention disclosed herein. The specification and examples are intended to be considered as exemplary only, with the true scope of the invention being indicated by the following claims.

Claims

1. A system for securely provisioning a computerized device, comprising: A secure delivery computer communicatively connected to the computerized device, receiving a first digital asset, and transmitting the first digital asset to the computerized device; A digital asset management server connected to the secure delivery computer and transmitting the first digital asset to the secure delivery computer when a first authorization condition is met, wherein the first digital asset is configured to partially provision the computerized device; A provisioning controller connected to the secure delivery computer and the digital asset management server, for determining whether the first authorization condition is met; Wherein The digital asset management server transmits a second digital asset to the computerized device; The system wherein the computerized device functions after the second digital asset is transmitted to the computerized device.

2. The system according to claim 1, wherein the first authorization condition is that the computerized device is authorized for use in the system.

3. The system according to claim 2, wherein the provisioning controller determines whether the computerized device is authorized for use in the system by referring to a stored list of authorized computerized devices.

4. The system according to claim 1, wherein the first authorization condition is that the user of the secure delivery computer is an authorized user.

5. The system according to claim 1, wherein the digital asset management server transmits log information regarding the first digital asset to the provisioning controller, and the provisioning controller stores the log information.

6. The system according to claim 5, wherein the log information includes at least one of identification of the user of the secure delivery computer, identification of the first digital asset, and a timestamp of the request for the first digital asset.

7. The system according to claim 1, wherein the digital asset management server transmits the second digital asset to the computerized device when a second authorization condition is met.

8. The system according to claim 7, wherein the second authorization condition is a determination that the computerized device is an authorized computerized device.

9. The system according to claim 1, wherein the provisioning controller stores log information regarding the second digital asset.

10. A method for provisioning a computerized device, comprising: when it is determined by a provisioning controller that a first authorization condition is satisfied, transmitting, by a digital asset management server, a first digital asset to a secure delivery computer; transmitting, by the secure delivery computer, the first digital asset to the computerized device, wherein the first digital asset is configured to partially provision the computerized device; receiving, by the digital asset management server, an instruction to transmit a second digital asset to the computerized device; in response to the instruction, transmitting, by the digital asset management server, the second digital asset to the computerized device; wherein the second digital asset is configured to enable the computerized device to function, the secure delivery computer is connected to the computerized device, and the digital asset management server is connected to the secure delivery computer.

11. The method according to claim 10, wherein the first authorization condition is that use of the computerized device is authorized by the digital asset management server.

12. The method according to claim 11, wherein the computerized device is authorized for use when it is determined that the computerized device is listed in a stored list of authorized computerized devices.

13. The method according to claim 10, wherein the first authorization condition is satisfied when it is determined that the user of the secure delivery computer is an authorized user.

14. transmitting, by the digital asset management server, log information regarding the first digital asset to the provisioning controller; storing, by the provisioning controller, the log information; The method according to claim 10, further comprising.

15. The method according to claim 14, wherein the log information includes at least one of identification of a user of the secure distribution computer, identification of the first digital asset, and a timestamp of a request for the first digital asset.

16. The method according to claim 10, wherein transmitting the second digital asset to the computerized device includes transmitting the second digital asset to the computerized device when a second authorization condition is met.

17. The method according to claim 16, wherein the second authorization condition is a determination that the computerized device is an authorized computerized device.

18. The method according to claim 10, further comprising storing, by the provisioning controller, log information regarding the second digital asset.

19. A system for securely provisioning a computerized device, a distribution computer communicatively connected to the computerized device, receiving a first digital asset, and transmitting the first digital asset to the computerized device; a server connected to the distribution computer and transmitting the first digital asset to the distribution computer when a first authorization condition is met, wherein the first digital asset is configured to partially provision the computerized device; a provisioning controller connected to the distribution computer and the server, for determining whether the first authorization condition is met; comprising wherein the server transmits a second digital asset to the computerized device, and the computerized device functions after the second digital asset is transmitted to the computerized device.

20. The system according to claim 19, wherein the first authorization condition is that use of the computerized device in the system is authorized.

21. The system according to claim 20, wherein the provisioning controller determines whether use of the computerized device in the system is authorized by referring to a stored list of authorized computerized devices.

22. 20. The system of claim 19, wherein the first authorization condition is that the user of the distribution computer is an authorized user.

23. 20. The system of claim 19, wherein the server sends log information about the first digital asset to the provisioning controller, and the provisioning controller stores the log information.

24. 24. The system of claim 23, wherein the log information includes at least one of an identification of a user of the distribution computer, an identification of the first digital asset, and a timestamp of a request for the first digital asset.

25. 20. The system of claim 19, wherein the server transmits the second digital asset to the computerized device when a second authorization condition is met.

26. 26. The system of claim 25, wherein the second authorization condition is a determination that the computerized device is an authorized computerized device.

27. 20. The system of claim 19, wherein the provisioning controller stores log information regarding the second digital asset.

28. 1. A method of provisioning a computerized device, comprising: transmitting, by the server, the first digital asset to the distribution computer when the provisioning controller determines that the first authorization condition is satisfied; transmitting, by the distribution computer, the first digital asset to the computerized device, the first digital asset configured to partially provision the computerized device; receiving, by the server, instructions to transmit a second digital asset to the computerized device; transmitting, by the server in response to the instruction, the second digital asset to the computerized device; Including, The method, wherein the second digital asset is configured to be functional on the computerized device, the distribution computer is connected to the computerized device, and the server is connected to the distribution computer.

29. 30. The method of claim 28, wherein the first authorization condition is that the computerized device be authorized for use.

30. 30. The method of claim 29, wherein the computerized device is authorized for use when it is determined that the computerized device is on a stored list of authorized computerized devices.

Images