CN109997333B

CN109997333B - Embedding a foundational root of trust using a security algorithm

Info

Publication number: CN109997333B
Application number: CN201780053561.XA
Authority: CN
Inventors: R·古拉第
Original assignee: Data IO Corp
Current assignee: Data IO Corp
Priority date: 2016-08-08
Filing date: 2017-08-07
Publication date: 2022-12-23
Anticipated expiration: 2037-08-07
Also published as: TWI744373B; CN109997333A; US20180039795A1; EP3497880A1; TW201810111A; EP3497880A4; WO2018031496A1; US10268844B2

Abstract

Methods, techniques, and mechanisms for providing programmable devices in a secure manner are disclosed. The security programming system may individually encrypt a target payload of data and code, and then program the information into each of the programmable devices for a particular operation. The secure programming system may create a customized payload packet that can only be decrypted by a particular system or device having the correct security key.

Description

Embedding a foundational root of trust using a security algorithm

Technical Field

The present application claims priority from U.S. patent non-provisional application serial No. 15/669,873 (entitled "ROOT OF TRUST embedded USING SECURITY algorithm basis (embodding foundation ROOT OF true use SECURITY algorithm)") filed on 8/4/2017 and U.S. patent provisional application serial No. 62/372,242 (entitled "ROOT OF TRUST embedded USING SECURITY algorithm OF true use SECURITY algorithm basis ROOT OF true use SECURITY algorithm)", filed on 8/2016); in accordance with 35USC 120, the entire contents of these applications are incorporated herein by reference as if set forth in part herein.

This application is related to U.S. provisional application Ser. No. 62/371,184 (entitled "COUNTERFEIT PREVENTION") filed on 8/4/2016, U.S. provisional application Ser. No. 62/401,953 (entitled "UNIFIED PROGRAMMING ENVIRONMENT FOR PROGRAMMABLE DEVICES") filed on 9/30/2006, and U.S. non-provisional application Ser. No. 15/640,438 (entitled "DEVICE PROGRAMMING SYSTEM GENERATION") filed on 6/30/2017; each application is owned by the applicant and is incorporated herein by reference in its entirety.

Embodiments generally relate to device programming systems; and more particularly to a secure programming and verification system.

Background

The approaches described in this section are approaches that could be pursued, not necessarily approaches that have been previously conceived or pursued. Thus, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.

The contracting electronic component assembly may reveal valuable intellectual property for piracy. Exposure of intellectual property can cost developers millions of dollars in development. While various feeder and robotic handling systems fill electronic circuit boards with integrated circuits, operations related to handling integrated circuits (e.g., programming, testing, calibration, and metrology) are typically performed in different areas on separate equipment (rather than integrated into a main production assembly line).

Programmable devices such as Flash memory (Flash), electrically erasable programmable read-only memory (EEPROM), programmable Logic Devices (PLD), field Programmable Gate Arrays (FPGA), and microcontrollers incorporating non-volatile memory components can be configured with stand-alone programming equipment, often in a separate area from the circuit board assembly line. In addition, system-level components such as smart phones, circuit boards, internet of things (IoT) devices, and media players may also require specific security configuration support.

Disclosure of Invention

An apparatus, comprising: an identification module, the identification module implemented at least in part by hardware, the identification module generating an identification token for use by the manufacturing execution system based on a root of trust data register of the programmable device and a root of trust code register of the programmable device; an encryption module, implemented at least in part by hardware, that computes an encryption token and a key token for authenticating the trust data cache and the trust root code cache; an authentication module implemented at least in part by hardware, the authentication module to verify a trusted hardware platform based on the encryption token and the key token; and a code signing module, the code signing module implemented at least in part by hardware, the code signing module verifying the firmware integrity of the trusted hardware platform prior to programming the programmable device.

A method comprising the steps of: generating an identifier for use by the manufacturing execution system based on the root of trust data cache of the programmable device and the root of trust code cache of the programmable device; calculating an encryption identifier and a key identifier for authenticating the trust data buffer and the trust root code buffer; verifying the trusted hardware platform based on the encryption token and the key token; and verifying the firmware integrity of the trusted hardware platform prior to programming the programmable device.

One or more non-transitory computer-readable media storing instructions that, when executed by one or more computing devices, perform the steps of: generating an identifier for use by the manufacturing execution system based on the root of trust data cache of the programmable device and the root of trust code cache of the programmable device; calculating an encryption token and a key token for authenticating the trust data buffer and the trust root code buffer; verifying the trusted hardware platform based on the encryption token and the key token; and verifying the firmware integrity of the trusted hardware platform prior to programming the programmable device.

Drawings

The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

FIG. 1 depicts an illustrative diagram of a security programming system according to an embodiment;

FIG. 2 depicts an example of a programmer;

figure 3 depicts an example of one of the trusted devices;

FIG. 4 depicts an example of one of the data devices;

FIG. 5 depicts an example of device identification;

FIG. 6 depicts an exemplary block diagram of a secure programming system;

FIG. 7 depicts a second exemplary block diagram of a security programming system;

FIG. 8 is a block diagram of a trusted device according to an embodiment;

FIG. 9 is an example of a management and security processing system;

FIG. 10 is a detailed example of a security component use case;

FIG. 11 is an example of an on-device seed and voucher generation use case;

figure 12 is a first example of a flow diagram for an embedded trust root system, according to an embodiment;

fig. 13 is a second example of a flow diagram of an embedded trust root system in accordance with one or more embodiments; and

FIG. 14 is a block diagram of a computer system upon which embodiments of the present invention may be implemented.

Detailed Description

In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

Embodiments are described herein according to the following outline, which outline is:

1.0 general overview

2.0 structural overview

3.0 functional overview

4.0 exemplary embodiment

5.0 implementation mechanisms-hardware overview

6.0 extensions and substitutions

1.0 general overview

Methods, techniques, and mechanisms for providing programmable devices in a secure manner are disclosed. The security programming system may individually encrypt a target payload of data and code, and then program the information into each of the programmable devices for a particular operation. The secure programming system can create a customized payload packet that can only be decrypted by a particular system or device having the correct security key.

Programmable devices can include memory chips, circuit boards, etc., as well as complete electronic devices such as smart phones, media players, and other consumer and industrial electronic devices. The configuration of the security key may control the programmed operation of the programmable device.

According to embodiments, encryption of program data validly carried by a respective target on one of the programmable devices (e.g., circuit boards) may enable the circuit boards to be configured to operate only with components having registered security code. This can be used to ensure that the circuit board can only be manufactured with certified part classes.

According to an embodiment, when the security code is identified as invalid, the programmable device will not be authorized to function (e.g., receive programming data or code or send any user data back to the host system or server, etc.). Detecting such unauthorized operation eliminates counterfeit and secure devices that may be tampered with or damaged.

According to embodiments, the identification of unauthorized devices (e.g., serial numbers, etc.) may be reported and stored for subsequent authentication processes. The stored identification may be used as a priori information for subsequent authentications to reduce the overall verification time of the selected identification.

According to embodiments, the programmable device may verify the serial number or other parameters that are a prerequisite for device operation. In another embodiment, the programmable device may provide a code signing facility to authenticate code prior to execution.

In other aspects, the invention includes computer apparatus and computer-readable media configured to perform the foregoing techniques.

2.0 structural overview

Referring now to FIG. 1, an illustrative diagram of aspects of a security programming system 100 in which the techniques described herein may be implemented is shown, according to an embodiment. The secure programming system 100 may separately configure the data device and use the encrypted information to enable trusted devices to provide a secure programming and operating environment.

The security programming system 100 includes a programming unit 110, the programming unit 110 having a programmer 112, a security controller 114, a security key 106, an adapter for coupling to a programmable device 128, a first security module 116, a second security module 118, and an nth security module 120. The secure programming system 100 may be coupled to a secure host system 104 having a secure host storage system 102. The secure host system 104 and the secure host storage system 102 may generate and securely store a secure key 106 for use in encrypting and decrypting information. The security key 106 may implement various security paradigms. The secure key 106 may include a key pair 150 having a private key 152 and a public key 154. The key pair 150 may be used to implement a public key encryption system in which material encrypted by a private key 152 may be decrypted by a public key 154. The secure programmatic system 100 may contain a plurality of different key pairs 150 as desired. The key pair 150, private key 152, and public key 154 may be implemented for different devices or system components, including the secure programming system 100, programming unit 110, programmer 112, secure controller 114, security module, programmable device 128, data device 132, trusted device 130, or any other system component.

System 100 includes one or more computing devices. The one or more computing devices include any combination of hardware and software configured to implement the various logic components described herein, including the components of the programming unit 110 having the programmer 112, the security controller 114, the adapter, the first security module 116, the second security module 118, and the nth security module 120. For example, one or more computing devices may include one or more memories storing instructions for implementing the various components described herein, one or more hardware processors configured to execute the instructions stored in the one or more memories, and one or more data repositories in the one or more memories for storing data structures used and manipulated by the various components.

The programming unit 110 may be a security system for programming data, intermediate data and code onto the programmable device 128. The programming unit 110 may receive security information from the secure host system 104, process the information, and transmit a properly configured version of the security information to the programmable device 128.

The programming unit 110 may include a programmer 112. The programmer 112 may be an electromechanical system for physically programming the programmable device 128. For example, the programmer 112 may receive a cartridge (tray) containing the programmable device 128, electrically couple the programmable device 128 to an adapter unit, and transmit security information into the programmable device 128. The programming unit 110 may receive individual status information from each programmable device 128 and customize the security information sent to each programmable device 128 on an individual device basis. For example, each of the programmable devices 128 may receive a separate block of information (which is different from the information sent to the other devices in the programmable device).

The programmer 112 may be coupled to one or more adapters that may be used to access the programmable device 128. The adapters may include a first adapter 122, a second adapter 124, and an nth adapter 126.

In an illustrative example, the first adapter 122 may be a hardware device that may be used to electrically connect one or more programmable devices to the programmer 112. The programmer 112 may then transmit the version of the security information to one of the programmable devices 128. The first adapter 122 may include one or more receptacles for mounting the programmable device 128. The first adapter 122 may include a socket, connector, zero Insertion Force (ZIF) socket, or similar device to mount the integrated circuit.

Although the adapter is described as an electromechanical unit for mounting the programmable device 128, it should be understood that the adapter may have other implementations. For example, if the programmable device 128 is a stand-alone electronic device (e.g., a mobile phone, a consumer electronic device, a circuit board, or the like having active components), the adapter may include a mechanism for communicating with the programmable device 128. The adapter may include a cable link, a wireless communication link, an electronic data bus interface, or similar data communication mechanism.

The programmable device 128 is a device that can provide security information from the programming unit 110. For example, the programmable device 128 may include data devices such as flash memory cells, programmable read only memory, secure data storage, or the like.

Configuration may include communicating data and code information to the device. For example, the flash memory cell may be provided by data programming the flash memory cell.

The programmable device 128 may also include a trusted device 130, the trusted device 130 including secure data and secure program information. For example, the programmable device 128 may include a trusted device 130 (e.g., a mobile phone, a hardware security module, a trusted programming module, a circuit board, or the like).

The data device 132 may include any number of devices; such as a first data device 134, a second data device 136, and an nth data device 138. Trusted devices 130 may include any number of trusted devices; such as a first trusted device 140, a second trusted device 142, and at most an nth trusted device 144.

Individually customized security information may be provided to each of the programmable devices 128. Thus, each of the programmable devices 128 may include a separate set of security keys 106, the set of security keys 106 being used to individually encrypt data stored in the programmable devices 128. This provides the ability to encrypt the security information 148 differently on each of the programmable devices 128 to maximize security. Each of the programmable devices 128 may be personalized by a separate security key 106.

The programmable device 128 may be configured to include a pair of devices 146. The paired devices 146 are two or more of the programmable devices 128 that can share one or more security keys 106. This may allow each of the paired devices 146 to detect and authenticate the other of the paired devices 146 in the same group. Thus, data from one of the paired devices 146 may be shared with the other of the paired devices 146. This may allow functions such as sharing information, authenticating a bi-directional secure channel between two or more paired devices 146, identifying other related devices, or a combination thereof.

In an illustrative example, the secure programming system 100 may be used to establish one of the paired devices 146 having the first data device 134, such as a System Information Module (SIM) chip paired with the first trusted device 140, such as a smart phone. In this configuration, both the first data device 134 and the first trusted device 140 may be programmed with the security key 106 of the paired device 146. Thus, the first trusted device 140 may verify the security information 148 (e.g., serial number) of the first data device 134 to authenticate that the first trusted device 140 is allowed to use other information on the first data device 134.

The programming unit 110 may include a safety controller 114 coupled to the programmer 112. The security controller 114 is a computing device for processing security information. The security controller 114 may include special encryption and computing hardware to set up the processing of encrypted information. For example, the safety controller 114 may include a quantum computer, parallel computing circuitry, a Field Programmable Gate Array (FPGA) configured to process safety information, a co-processor, an array of logic units, a microprocessor, or a combination thereof.

Security controller 114 may be a security device specifically configured to prevent unauthorized access to security information at the input, intermediate or final stages of processing the security information. The secure controller 114 may provide a secure execution environment for the secure code components when executed, for example, the secure controller 114 may be a Hardware Security Module (HSM), a microprocessor, a trusted security module (TPM), a dedicated security unit, or a combination thereof. The safety controller 114 may be part of the programming unit 110. For example, a security controller 114, such as a hardware security module, may be included within the programmer 112.

The security controller 114 may be coupled to the security module to provide specific security functions. The security modules may include a first security module 116, a second security module 118, and an nth security module 120. Each security module may provide specific security functions such as identification, authentication, encryption, decryption, verification, code signing, data extraction, or combinations thereof. For example, the security module may be hardware, software, or a combination thereof.

For example, the first security module 116 may be configured to provide an Application Programming Interface (API) to a standardized set of common security functions. In another example, the second security module 118 may be a combination of dedicated hardware and software to provide faster encryption and decryption of data.

The programming unit 110 may include secure storage of one or more security keys 106. The security keys 106 may be computed internally within the security programming system 100, such security keys 106 may be computed externally and received by the security programming system 100, or a combination thereof.

The security key 106 may be used to encrypt and decrypt security information. The security key 106 may be used to implement different security methods and agreements. For example, the secure key 106 may include a key pair 150 having a private key 152 and a public key 154 to implement a public key encryption system. In another example, the security key 106 may be used to implement different security agreements or methods. Although the security key 106 may be described as a public key encryption system, it should be understood that the security key 106 may be used to implement any of a variety of security paradigms.

In the illustrative example, the secure key 106 may include one or more key pairs 150 for a public key encryption system. The secure information may be encrypted using the public key 154 of one of the key pairs 150 and only decrypted using its private key 152 pair.

One of the advantages of the secure programming system 100 includes the ability to provide each programmable device 128 with a different set of security keys 106 and different versions of the security information 148 encrypted by the respective security keys 106. This ensures that the security key 106 used to decrypt the security information 148 on one of the programmable devices 128 cannot be used to decrypt the security information on the other programmable device 128. Each programmable device 128 may have a separate one of the security keys 106 to provide maximum protection.

Referring now to FIG. 2, an example of the programmer 112 is illustrated. The programmer 112 is an electromechanical device for supplying the programmable device 128.

The programmer 112 may be used to access the programmable device 128 and provide content efficient bearers to the programmable device 128. The content-valid bearer may contain data, code, security key 106, security information 148, and other relevant content.

The programmer 112 may have various configurations. The programmer 112 may include a programming processor 202, an input device socket 206, a device adapter 208, a destination socket 210, a device placement unit 212, and an output device socket 214. For example, the programmer 112 may be the programmer 112, a chip programmer, a device supply system, a circuit board programmer, or similar configuration system.

The programmer 112 may have a programmer identifier 216. The programmer identifier 216 is a unique value used to identify the programmer 112.

The programmer 112 may configure the programmable device 128 by initializing a data image and writing the data image to the programmable device 128. The data map may be configured for the device type of the programmable device 128. The programmer 112 may transfer data to the programmable device 128 using direct or indirect memory access.

The programmer 112 may receive a single active bearer image for the programmable device 128 and store the image in a local programmer storage unit. The active bearer image may be processed into a separate image for each programmable device 128. The programmable device 128 is configured to store memory structures, encrypted data, and user data on the programmable device 128. Configuration may include forming a disposable structure, such as a partition on the programmable device 128.

The programmed processor 202 may have various configurations. For example, the programmed processor 202 may include a safety controller or be coupled to a system controller. The programmed processor 202 may be a cell processor, a multiprocessor, a cloud computing component, or a combination thereof.

Programmer storage unit 204 is a device for storing and retrieving information. For example, the programmer's storage unit 204 of the programmer 112 may be a disk drive, solid state memory, optical storage device, or a combination thereof.

The programmer 112 may include software for operating the programmer 204. Software is control information for execution on programmed processor 202. Software may be stored in the programmer's storage unit 204 and executed on the programmer's processor 202.

The programmer 112 may include an input device receptacle 206. The input device socket 206 is the source of the programmable device 128. For example, the input device socket 206 may be a tray compliant with the Joint Electron Device Engineering Council (JEDEC) standard. The input device receptacle 206 may be used to support an unprogrammed device.

The programmer 112 may include an output device receptacle 214. The output device socket 214 is the destination of the supplied programmable device 128. For example, the output device receptacle 214 may be an empty JEDEC tray for supporting a finished device, storage tube, shipping package, or other similar structure.

The programmer 112 may include a device adapter 208. The device adapter 208 is a mechanism for coupling to the programmable device 128.

The device adapter 208 may have various configurations. For example, the device adapter 208 may include a destination socket 210 for mounting a programmable device 128, such as a chip. The receptacle is a mechanism for supporting the programmable device 128 and interfacing with the programmable device 128. The device adapter 208 may be modularized and the device adapter 208 may be removed from the programmer 112 to accommodate different receptacle configurations. The device adapter 208 may include a latching mechanism (not shown) for attachment to the programmer 112.

The destination socket 210 may support the programmable device 128. The destination socket 210 may be used to read new information or write new information to the programmable device 128.

The programmer 112 may include a device placement unit 212. The device placement unit 212 is a mechanism to position the programmable device 128 in one of the destination sockets 210.

The device placement unit 212 may be implemented in various ways. For example, the device placement unit 212 may be a robotic arm, a pick and place mechanism, or a combination thereof. Although the device placement unit 212 may be described as a rail-based positioning system, it is to be understood that any system capable of positioning one of the programmable devices 128 in the destination socket 210 may be used.

The device placement unit 212 may retrieve one or more blank programmable devices 128 from the input apparatus socket 206. The device placement unit 212 may deliver the programmable device 128 to the destination receptacle 210 of the device adapter 208.

Once the programmable device 128 is engaged and secured by the device adapter 208, the device programming process may begin. The programmer 112 may program a copy of the local information into the programmable device 128 in one of the destination sockets 210. For example, the local programmable copy of information may be in a pre-programmed host device, from a file in local storage, or from a remote server.

Once programming is complete, the device placement unit 212 may transfer the programmed programmable device 128 to the output device receptacle 214. The device placement unit 212 may transmit any of the programmable devices 128 having errors to a reject bin (not shown).

The programmer 112 may include a programmer identifier 216. Programmer identifier 216 is a unique value for programmer 112. The programmer identifier 216 may be used to identify the programmer 112. Programmer identifier 216 may be incorporated into the device identifier for each programmable device 128 to indicate which programmer 112 is used to program the device.

Referring now to FIG. 3, an example of one of the trusted devices 130 is illustrated. The trusted device 130 is a component having a secure storage unit 326 and a secure execution unit 324. The trusted device 130 is an active component that can execute secure code in the secure execution unit 324 to perform operations on secure data in the secure storage unit 326.

The trusted device 130 may be provided by the security programming system 100 to include security information. For example, the trusted device 130 may include a device identifier 302, a security algorithm 304, security credentials 306, and a key pair 150, each having a private key 152 and a public key 154.

In an illustrative example, the security key 106 may include one or more key pairs 150 for a public key encryption system. The secure information may be encrypted using a private key 152 of one of the key pairs 150 and decrypted using a public key 154. Similarly, information encrypted using public key 154 may be decrypted using private key 152.

The device identifier 302 is a data value that can uniquely identify each trusted device 130 individually. For example, the device identifier 302 may include a serial number, a tag, a security code, or a combination thereof.

The security algorithm 304 includes a security code component 314. The security algorithm 304 may provide an application programming interface to external systems to control security functions on the trusted device 130. The security algorithm 304 may be customized to each trusted device 130. For example, security algorithm 304 may include security code component 314 such as source code, executable code, library modules, link modules, configuration files, initialization data, hardware handles, or a combination thereof.

The security credential 306 is a secure item associated with one of the trusted devices 130. The security credentials 306 may be pre-programmed to prove that the device has a particular root of trust embedded therein. The security credential 306 may have one or more public keys 154 therein. The security credentials 306 may include secure data such as a key pair 150, a security key 106, an encryption password, or a combination thereof.

The security credentials 306 may be a securely stored data component. For example, the security credential 306 may be encrypted security information that can be decrypted before use.

Key pair 150 may be a secure component having two or more separate secure keys for encrypting and decrypting data. For example, key pair 150 may include a private key 152 and a public key 154. The secure information encrypted with public key 154 may be decrypted using private key 152.

The key pair 150 may be implemented in various ways. For example, key pair 150 may be configured to have different key lengths to change the security level. The key pair 150 may be implemented with different character lengths.

Although key pair 150 is described in the context of a public key encryption system, it should be understood that key pair 150 may also be used to implement any other encryption paradigm. For example, the key pair 150 may be used for symmetric encryption, asymmetric encryption, standards-based encryption, hash algorithms, or any other encryption system.

The trusted device 130 may include security functionality implemented as a security module. For example, the trusted device 130 may include a recognition module 316, an authentication module 320, an encryption module 318, and a code signing module 322.

The identification module 316 may verify an identifier of one of the programmable devices 128. The identification module 316 may receive the device identifier 302 of one of the programmable devices 128 and determine whether the device identifier 302 is correct. For example, the device identifier 320 may be compared to a list of known devices, compared to a checksum, compared to using a computational algorithm, or the like.

The authentication module 320 may verify one or more attributes of one of the programmable devices 128. The authentication module 320 may receive the device identifier 302 and security parameters including the one or more security keys 106 to determine whether the provided security parameters are valid. The authentication module 320 may also be used to verify the device identifier 302.

The validity of the security parameter may be determined in various ways. For example, the validity of the security parameters may be verified by successfully decrypting the security parameters using one of the security keys available to one of the trusted devices 130. In another example, the validity of the security parameter may be verified by decrypting one of the security parameters and comparing it to a predefined value stored in one of the trusted devices 130.

The encryption module 318 is a unit for performing an encryption operation. The encryption module 318 may provide an interface to perform computationally intensive tasks such as encryption and decryption. Other security modules may be coupled with the encryption module 318 to provide security functions.

The encryption module 318 may be implemented in various ways. For example, the encryption module 318 may include hardware, software, or a combination thereof. The encryption module 318 may provide a standard interface to allow other security modules to perform the required encryption functions.

The code signing module 322 is a unit for protecting the code component 314. The code signing module 322 may encrypt code components, decrypt code components, and handle execution of components. The code signing module 322 may be used to ensure that one of the code components is executed on one of the trusted devices 130 by verifying the security information associated with the code component 314.

In an illustrative example, each of the code components 314 may include an execution parameter indicating a trusted device 130 model that is authorized to execute the code component 314. The code signing module 322 may be used to verify the execution parameters, compare the parameters to model information in one of the trusted devices 130, and allow execution of the code component 314 only if these two values match. This can be used to limit the operation of the code assembly to a particular high-end phone or other particular device.

One of the advantages of the trusted device 130 is that the trusted device 130 can internally recognize and authenticate security information to increase the security level. The trusted device 130 may use the security key 106 stored in the secure store 326 to verify security information.

When the trusted device 130 is secure, the trusted device 130 may provide trust metrics. The trusted device 130 may have various configurations. For example, the trusted device 130 may have system identifiers, authentication mechanisms, encryption and decryption functions, code signing to protect executables, trusted storage, and trusted execution environments.

The system identifier may include components that identify or describe hardware and software components. The trusted device 130 may have the ability to securely verify its identity and other attributes. The trusted device 130 may be capable of securely encrypting and decrypting information. The trusted device 130 may be capable of verifying the trust code. The trusted device 130 may have secure storage and execution capabilities.

The secure programming system 100 may be capable of implementing a root-of-trust system. Root of trust (RoT) is a set of functions in a trusted computing environment that can establish trusted operations by the system. For example, the root of trust may serve as a separate secure compute engine that controls trusted computing platform cryptographic processes. Alternatively, a device may implement a root of trust as an inherently trusted hardware and software component. Trust roots are secure by design and may be implemented in hardware or protected by hardware. The Trust root may be used to perform security critical functions such as measuring or verifying software, protecting encryption keys, and performing device authentication.

The root of trust may provide various security functions including: real-time encryption, detection and reporting of tampering with secure data, detection of active tampering attempts, digital rights management, and other similar security functions.

It is difficult to implement secure operations in the remote hardware space because of the higher risk caused by physical access to the device. Such security devices require hardware to work closely with the protected data and software to ensure safe operation.

Referring now to FIG. 4, an example of one of the data devices 132 is illustrated. The data device 132 is a component having a secure storage unit 326. The data device 132 is a passive component that is capable of storing secure data in the secure storage unit 326 and providing access to the stored data when accessed by one of the trusted devices 130.

The data device 132 may be provided by the security programming system 100 to include security information. For example, the data device 132 may include a device identifier 302, a security algorithm 304, security credentials 306, and a key pair 150, the key pair 150 each having a private key 152 and a public key 154. In this case, the data within the secure storage unit 326 may be accessed from within the data device 132.

The secure storage unit 326 may be a write-once data area. Information may be programmed into the secure storage unit 326 and the secure storage unit 326 may then be processed to eliminate access to data within the secure storage unit 326 from outside the data device 132.

In an illustrative example, one of the data devices 132 may be a flash memory device. Within a flash memory device, the flash memory may be divided into different blocks. Some blocks may be used to provide general memory space. Other blocks may be configured to be private and used to store information that is not accessible from outside the flash memory device. The secure storage unit 326 may be formed using dedicated blocks.

In another example, the secure storage unit 326 may be a dedicated memory area on one of the data devices 132 protected by a security fuse. Data may be written to the secure storage unit 326 and then the external access may be eliminated by blowing the security fuses.

Each of the data devices 132 may include a trust credential 402. The trust credential 402 is a data structure that may include other security parameters. For example, the trust credential 402 may include the device identifier 302, the security algorithm 304, and the key pair 150.

Referring now to fig. 5, an example of a device identifier 302 is illustrated. The device identifier 302 is a data structure that may be used to uniquely identify one or a combination of the programmable device 128, the secure programming system 100, the programmer 112.

The device identifier 302 may have various configurations. For example, the device identifier 302 may include an input root of trust 504, a serial number tag 512, a firmware tag 506, a manufacturing tag 510, a product tag 508, an operation tag 514, an original equipment manufacturer tag 516 (OEM tag), a key pair 150, or the like.

The root of trust for input 504 is a security component. The root of trust 504 for input may be provided externally from one of the programmable devices 128. The root of trust of input 504 may be implemented in the target device at the time the target device is manufactured. The imported Trust root 504 may provide decryption seeds, compatibility scope for the surrounding components, compatible device types, firmware trust, manufacturing windows (development manufacturing phase (BoL) and recycle phase (EoL)), other parameters needed, or a combination thereof. The input root of trust 504 may modify the interpretation of other fields in the device identifier 302 based on the planned manufacturing structure (material list). The input root of trust 504 may specify or restrict the manufacturing structure to verifiable components that meet the criteria of the input root of trust 504.

Serial number indicia 512 is a security component that may include a serial number for one of the programmable devices 128. The device identifier 302 may include one or more of the sequence number markings 512. The serial number indicia 512 may include a manufacturing date code, a manufacturing lot code, a sequential part identifier, a component type code, additional parameters as desired, or a combination thereof. The combination of the entered root of trust 504 and the serial number tag 512 may provide a range of separate identification or compatible devices during assembly. The device identifier 302 may uniquely define the combination of hardware devices within the material list of the next level structure.

The firmware token 506 is a security component that can describe or identify the firmware version used in one of the programmable devices 128. For example, one of the programmable devices 128 may be a circuit board having firmware mounted thereon. The firmware label 506 may identify the version number of each individual firmware component. The firmware version information may be used to coordinate interoperability between code components in the programmable device 128. The input root of trust 504 may identify a firmware tag 506 that is intended for use in the programmable device 128. If the input Trust root 504 recognizes that the firmware tag 506 is not included in the expected bill of materials, then programming is not allowed.

Manufacturing indicia 510 is a security identifier that may describe one or more manufacturing properties. For example, one of the programmable devices 128 may include a manufacturing marker 510 (e.g., location information, manufacturing time information, manufacturing location information, time window, manufacturing execution system identification information, factory identifier, vendor identifier, manufacturing device information, or manufacturing-related parameters).

The product marking 508 is a security component that can describe a product used with the programmable device 128. The product indicia 508 may include relevant manufacturer, brand information, product line information, model information, or other product-related parameters.

The operation markers 514 are security components that may describe the operational attributes of the programmable device 128. The operation markers 514 may include operating voltage, voltage mode, current level, power consumption, heating factor, critical operating frequency, operating sequence information, or operating parameters.

The OEM mark 516 is a security component that may describe the original equipment manufacturer or a related contract manufacturer that may use the programmable device 128. The OEM mark 516 may include a manufacturer identifier 518, license information, a time window, an authorized location, an authorized factory, a product lot number, a serial number range, or other OEM related parameters.

The device identifier 302 is a multivariate data structure that includes security information for the programmable device 128. The data components of the device identifier 302 may be separately encrypted within the device identifier 302. The device identifier 302 itself may be encrypted. The device identifier 302 may be specific to each of the programmable devices 128 in terms of the data components forming the device identifier 302 and the degree of encryption and other security mechanisms used to protect the device identifier 302.

One of the many advantages of the device identifier 302 is that access to particular data components within the device identifier 302 is performed by decrypting only the components that are needed. By both the encryption device identifier 302 and the respective data elements, a finer security granularity may be provided. It is to be understood that the input root of trust 504 may exist in each of the programmable devices 128 included in the list of materials. Each of the programmable devices 128 may verify that it is coupled to an authenticated compatible component based on the root of trust 504 of the inputs established at the time it is manufactured. It has been unexpectedly discovered that the device identifier 302 can be used to limit the number of devices that can be programmed with a fixed list of materials. This aspect may prevent piracy of the overproduction of parts without the knowledge or authorization of the Original Equipment Manufacturer (OEM).

Referring now to fig. 6, an exemplary block diagram of the safety programming system 100 is illustrated. The security programming system 100 includes a plurality of security objects, such as a first security object 602 and a second security object 604. The first security object 602 may interface or communicate with the second security object 604.

A secure object refers to any hardware or software object having a security mechanism or protocol for preventing unauthorized eavesdropping or copying. For example, the security object may include, but is not limited to, an electronic component, an electronic device, a boot loader, firmware (FW), an Operating System (OS), a software application, a hardware programmer, a peripheral device, a website, a machine, and the like.

The first secure object 602 may interface with the recognition module 316, the authentication module 320, the encryption module 318, and the code signing module 322. For illustrative purposes, although the second security object 604 is illustrated as being connected only to the first security object 602, the second security object 604 may be connected to any combination of the recognition module 316, encryption module 318, authentication module 320, code signing module 322. The first secure object 602 or the second secure object 604 protects a security breach using, but not limited to, the identification module 316, the encryption module 318, the authentication module 320, the code signing module 322, or any other unit, module, or combination of functions of the security programming system 100.

The recognition module 316 generates an identity of a secure object to protect the secure object from unauthorized access to the secure object. The recognition module 316 extracts a recognition token 624 (ID token). The ID token 624 includes information used to verify identity before granting access to the secure object. The ID identifier 624 may include, but is not limited to, a subscriber identifier, a serial number of the device, a device identifier, and the like.

The ID token 624 may be extracted by the recognition module 316 using any security information or mechanism, including, but not limited to, a root of trust code 620 (RoT code) stored in the RoT code register 621 and root of trust data 622 (RoT data) stored in the RoT data register 623. The RoT code register 621 and RoT data register 623 may be volatile memory, non-volatile memory, combinational logic registers, or a combination thereof. For example, roT data 622 may represent information associated with a digital birth certificate of a device, a time window for using root of trust code 620, a part number or serial number that allows a range of root of trust codes 620, or a combination thereof. Root of trust data 622 may be established during manufacturing and functional testing of the component. By combining the Trust root code 620 with the Trust root data 622, the ID token 624 for each programming device 128 may be generated without additional components or duplication of the ID token 624.

The term "root of trust (RoT)" as referred to herein refers to a set of functions of a computing module that can establish trust or security, including hardware components, software components, or a combination of hardware and software components. For example, such functions may be implemented as, but not limited to, secure boot firmware, hardware initialization units, and cross-checking components/chips. Each of the hardware and software components can only be utilized with a planned and limited number of programmable devices 128. Also, for example, functions may be implemented using, but not limited to, a separate compute engine that controls the operation of the crypto processor. The programmer 112, which writes the firmware component to one of the programmable devices, may utilize the ID identifier 624 to select a decryption key for the firmware component. An attempt to copy the firmware components to an unauthorized one of the programmed devices 128 may result in an incorrect decryption of the firmware components, which may prevent the programmer 112 from performing the programming operation.

The ID token 624 can be decrypted from the RoT code 620 using the RoT data 622. The protected ID token 624 may be encrypted, so the ID token 624 may be decrypted only by the coupled version of the RoT code 620. The ID identifier 624 may be unique such that each secure object has an identifier of the secure object itself, so that no one secure object shares the identifier of the secure object itself with another secure object.

RoT code 620 comprises instructions or commands used by a particular set of hardware to decode data that can be used to recognize a device source or to decode content. RoT data 622 comprises protected data, and only this data can be coded using a coupled set of RoT codes 620. The RoT code 620 can be generated to operate with only a limited range of programmable devices 128 having appropriate RoT data 622. This combination may also verify that the correct firmware components are being applied to the correct hardware device and that only the planned number of programmed devices 128 is being generated.

RoT code 620 and RoT data 622 may be provided or generated by any security mechanism of the original manufacturer. For example, roT data 622 may be established at the time of manufacture of the device, and RoT code 620 may be programmed into a secure storage area of the device during programming or configuration of the device. The RoT code 620 may be generated to control a particular use and number of occurrences of the programming device 128.

Also, for example, the RoT code 620 and RoT data 622 can be sent from the host server or system to the secure programming system 100 in a secure manner such that only the secure programming system 100 is authorized and authenticated to receive the RoT code 620 and RoT data 622. Further, for example, the host server or system may include a secure host system 104 that sends a secure key 106 to the secure programming system 100 for identification or authentication before the secure programming system 100 may be able to receive or decrypt information from the secure host system 104.

As an example, the secure storage area may include, but is not limited to, a one-time programmable memory or any other storage area known only to authorized users or devices. As another example, the secure storage area may include, but is not limited to, storage or memory that is accessible only to authorized information or identifiers without permission to be denied.

For example, the RoT code 620 can be pre-programmed to a device (e.g., a security object with RoT data 622) when the programming device 128 is configured in a production environment or system and before the programming device 128 is integrated or operated in the production environment or system. The RoT code 620 may enable the programming device 128 to identify which other devices may be coupled to its interface. This can follow the planned build schedule, and it is unlikely that too many pirated components will be produced. Further, for example, a production environment or system may include, but is not limited to, portable devices, computers, servers, electronic circuit boards, and the like.

The authentication module 320 is a unit for verifying whether the identifier 624 is authorized for accessing the secure object. After the identification module 316 extracts the ID token 624, the authentication module 320 verifies the ID token 624 to identify whether the secure object is a valid object that can communicate with an authorization system to send or receive secure information. For example, if one of the ID tokens 624 is invalid, the secure object may not be allowed to exchange information with the programmer 112.

After the authentication module 320 verifies that the ID token 624 of the secure object is valid, the authentication module 320 may generate a combination of one of the ID token 624, the key token 628, and the encryption token 626. The key token 628 includes information for authenticating the ID token 624. The encryption token 626 includes information for encryption encoding or decoding information for information security or data confidentiality. For example, the programmer 112 may transfer the encrypted file to the secure object 602, and the secure object 602 may use the key token 628 to access the encryption token 626 in order to decompress and decode the software to be programmed into the secure device 602.

In one or more embodiments, the RoT code 620 can be used to generate an ID token 624, a key token 628, or an encryption token 626 from the RoT data 622. In one or more embodiments, the protection ID token 624, the key token 628, or the encryption token 626 may be encrypted; thus, the ID token 624, key token 628, or encrypted token 626 may be decrypted only by the correct version of the RoT code 620.

The encryption module 318 provides data encryption and decryption for security information exchanged to the secure object 602 or between the secure object 602 and an external system. External systems that may exchange security information with the security object 602 may include, but are not limited to, the programmer 112, the secure host system 104, and the host system.

In an embodiment, after the recognition module 316 extracts the ID token 624 or the authentication module 320 verifies the ID token 624, the encryption module 318 may generate the ID token 624, the key token 628, and the encryption token 626. RoT data 622 can be used by encryption module 318 to generate an encryption token 626 to decode information from RoT code 620.

In an embodiment, the encryption module 318 can use the password token 626 to generate the ID token 624 or the key token 628 to further decode other information from the RoT code 620. In an embodiment, the elimination of data leakage is greatly simplified using an encryption module 318 with multiple levels of protection that improve information security or data privacy.

In an embodiment, encryption module 318 may include encryption methods including, but not limited to, symmetric key encryption, public key encryption, and the like. For example, the encryption module 318 may include an encryption method in which both the sender and the recipient may share the same key or different keys (which may be calculated using a predetermined algorithm established in the RoT data 622).

As an example, the cryptographic methods may include, but are not limited to, block encryption, cryptographic hash functions, and the like. As another example, the encryption method may include, but is not limited to, data Encryption Standard (DES), advanced Encryption Standard (AES), triple DES, MD4 message digest algorithm, MD5 algorithm, secure hash algorithms 1 and 2, or any advanced encryption technique to be developed.

As an example, the encryption method may include, but is not limited to, public key or asymmetric key encryption techniques, where two different but mathematically related keys-a public key and a private key-may be used. As another example, a public key system may be established such that it is computationally infeasible to compute a key (e.g., a private key) from another key (e.g., a public key), even if such keys are related. Both public and private keys may be generated privately as interrelated pairs. For example, roT data 622 may provide a transformation seed to generate a private key within secure device 602.

For example, in a public key encryption system, a public key may be freely assigned while a private key paired therewith may be kept secret. In a public key encryption system, a public key may be used for encryption, while a private or secret key may be used for decryption.

The code signing module 322 verifies the integrity of code information exchanged between systems or devices. The code signing module 322 verifies that the contents of the exchanged information have been altered or tampered with.

For example, code signing module 322 may include a program that digitally signs an executable file or script to validate a software author or producer and verify that the executable code or script has not been altered or corrupted. For example, because the code is signed by, but not limited to, cryptographic hashes and checksums, the code can be verified as modified or compromised.

In an embodiment, after the recognition module 316 extracts the ID token 624 or the authentication module 320 verifies the ID token 624, the code signing module 322 may generate the ID token 624, the key token 628, and the encryption token 626. RoT data 622 can be used by code signature module 322 to generate encrypted tokens 626 to decode information from RoT code 620.

In an embodiment, the code signing module 322 can generate the ID token 624 or the key token 628 using the encryption token 626 to further decode other information from the RoT code 620. In an embodiment, the elimination of data leaks is greatly simplified using a code signing module 322 with multiple levels of protection that improve information security or data confidentiality.

A security object, such as first security object 602 or second security object 604, may interface with security enforcement engine 606. Security enforcement engine 606 includes programmed mechanisms to manage or control security objects. The secure execution engine 606 includes a secure execution unit 324 and a secure storage unit 326.

The secure execution unit 324 is a block that executes code or computer instructions in a protected environment. The environment in which the secure execution unit 324 operates may establish a flexible, extensible solution to the problem of establishing a large-scale, wide-area secure environment in which only trusted, certified application code may operate. The secure execution unit 324 may enable the programmer 112 and the secure objects to work together in a secure environment.

The secure execution unit 324 may execute the trust code stored by the secure storage unit 326 when the secure object is programmed, configured, tested, or authenticated prior to the secure object operating in the end user production environment. The trusted code executed by the secure execution unit 324 may be signed and authenticated.

The secure storage unit 326 stores and provides trust code for execution by the secure execution unit 324. In an embodiment, the use of secure execution engine 606 to store program code in secure storage unit 326 and the use of secure execution unit 324 to execute program code greatly simplifies the secure environment, providing an additional level of protection against data leakage.

For example, the trust code may be pre-stored in the secure store or memory area of the secure object when the secure object was previously programmed, configured, tested, or authenticated. Also, for example, the encryption module 318 may use information sent from the programmer 112 to the secure object to decipher the trust code.

Referring now to FIG. 7, therein is shown a second exemplary block diagram of the safety programming system 100. An example diagram illustrates the data flow of security information during the programming of security object 701.

For example, recognition tokens 624, depicted as ID1, ID2, and ID3, may include serial number tag 512 of secure object 701. The serial number indicia 512 is unique information assigned to each of the secure objects 701. The security object's serial number tag 512 may be different from another security object's serial number tag 512, such that it is not possible for two security objects 701 to share the same serial number tag 512. The serial number indicia 512 may be generated by the programmer 112. Each serial number tag 512 may be assigned to each security object by the programmer 112.

The input root of trust 504 (In _ RoT) may include, but is not limited to, the programmer identifier 216. The In RoT 504, denoted as In RoT 504, comprises information that has been programmed or configured prior to programming the security object 701. In one or more embodiments, previously programmed information may be programmed as a combination of adapters for programming security object 701, programmer 112, and security object 701. For example, in _ RoT 504 may be a securely loaded decryption engine, interface device definition (material list coupling), or a combination thereof.

The In _ RoT 504 may be separate or distinct from the ID token 624. The In RoT 504 may comprise previously programmed information different from the information to be programmed into the security object 701. The ID token 624 may define the next level destination of the sequencer 128 as part of the manufacturing plan build.

For example, in _ RoT 504 may include, but is not limited to, a serial number or unique key that is embedded or programmed into the device at the time the device is manufactured. Further, for example, the time to fabricate a device may be, but is not limited to, the time to fabricate a device at the silicon layer or system level prior to programming the device.

In one or more embodiments, the manufacturing execution system 702 (MES) may ingest or input the In RoT 504. The manufacturing execution system 702 may execute the build plan to manufacture the first plate 712 and the second plate 714. It should be appreciated that the manufacturing execution system 702 may manufacture any number of boards. The In _ RoT 504 can be combined with a programmer that generates a unique RoT (e.g., ID token 624) to produce a unique system-level RoT. The In _ RoT 504 may include information from a digital birth certificate that has been previously programmed into the device during manufacture of the device. For example, the digital birth certificate may include RoT data 622 and RoT code 620.

The In _ RoT 504 can include any number of fabrication marks 510, denoted as P1 and P2. The manufacturing indicia 510 includes information associated with the component when the component is manufactured. For example, the manufacturing indicia 510 may include, but is not limited to, a component ID, a programmer ID, a manufacturing location of the component, a date code, a manufacturing time of the component, and the like.

The manufacturing execution system 702 is a computerized system for manufacturing products for product quality control purposes. The MES 702 can track and record the conversion of raw materials to finished products. The MES 702 can provide information on how the current conditions of the plant floor can be optimized to improve production output. The MES 702 can operate in real-time to control a plurality of elements of a production process (e.g., inputs, personnel, machines, support services, etc.).

In one or more embodiments, the MES 702 can receive the In RoT 504 along with the ID token 624 to program the programmable device 128, such as the security object 701. The In RoT 504 and ID token 624 may be used to generate the device identifier 302 for the secure object. The device identifier 302 includes information that is unique and associated with only one piece of equipment or security object.

The device identifier 302 may include unique information that may be programmed into the system (e.g., the first plate 712 or the second plate 714). The first plate 712 and the second plate 714 are board level systems having a plurality of security objects 701 assembled and connected to each other in the system.

The first board 712 may include a system public key 154 for encryption. The system public key 154 may be implemented in a first board 712 for a public key encryption system. The system public key 154 may be part of one of the key pairs 150. The security information may be encrypted by a security object using the private key 152 of one of the key pairs 150 and decrypted by the first board 712 using the system public key 154.

The first board 712 may use the system public key 154 to encrypt the secure information and send it to the secure object, which may use the private key 152 to decrypt the encrypted information. Although the system public key 154 is described as being used for the first board 712, it can be appreciated that the system public key can also be implemented in the second board 714.

The security programming system 100 illustrates only one of many possible arrangements of components configured to provide the functionality described herein. Other arrangements may include fewer, additional, or different components, and the division of labor between components may vary depending on the arrangement. For example, in some embodiments, some security modules and any other components that are specifically relied upon by the omitted components may be omitted. As another example, in an embodiment, the system 100 may further include a plurality of serial numbers or other system identifiers.

Referring now to FIG. 8, a block diagram of a trusted device 800 is illustrated, according to an embodiment. The various components of the trusted device 800 may be implemented in a variety of systems, including the systems described above for the secure programming system 100. In an embodiment, the trusted hardware platform 802 may be combined to include a secure execution module 804 that may interface with a secure storage module 806.

During manufacture of the trusted hardware platform 802, the manufacturing execution system 702 may work for a predefined build plan that requires each of the programmatic devices 128 to include an ID token 624 as required by the build plan. Including the RoT data 622 and RoT code 620 can accurately generate the correct number of programming devices 128, including ID tokens 624, needed to execute the manufacturing execution system 702.

The identification module 316 can generate the ID token 624 by generating a RoT code 620 that conforms to RoT data 622 according to the needs of the manufacturing execution system 702. The encryption module 318 utilizing the RoT code 620 and RoT data 622 may generate an encryption token 626 and a key token 628. It is to be appreciated that the RoT data 622 can be designed into the electronic device at the time of manufacture, and that the RoT data 622 can configure the RoT code 620 when it is ready to be sent to the manufacturing execution system 702. Each subsystem level of the trusted hardware platform 802 may include an ID token 624, an encryption token 626, and a key token 628. The ID token 624, the encryption token 626, and the key token 628 may be used when the operating firmware of the trusted hardware platform 802 may be updated.

The authentication module 320 can utilize RoT code 620 and RoT data 622 to verify that the trusted hardware platform 802 is in fact an authenticated component and not a pirate device. Once the new firmware is loaded, the code signing module 322 may verify that the firmware has not been changed or tampered with before decrypting and loading code for controlling the operation of the trusted hardware platform 802.

It should be appreciated that the trusted hardware platform 802 may maintain the security and integrity of the hardware and software used to execute the manufacturing execution system 702 without compromising any of the hardware components or software components used to generate the trusted hardware platform 802. It is further understood that the assembly of programmable devices on a subsystem or board by the methods previously discussed can transform the subsystem into a trusted hardware platform 802.

Particular embodiments of RoT code 620 and RoT data 622 can be instantiated in trusted hardware platform 802. RoT data 622 and RoT code 620 may be configured for a secure Application Programming Interface (API) executed by trusted hardware platform 802. Exposing the secure API to the trusted hardware platform 802 for execution can ensure the secure programming of the RoT data 622 in a secure environment.

The security API may be associated with code programmed by the security algorithm 304 to a particular RoT in the device. The code RoT function may be exposed to the firmware (on the device) by the API mechanism. For example, the entry point of the code RoT may be an API function. The security API may run or execute on the device.

The security algorithm 304 may be used to program a security-related RoT. The security algorithm 304 may be executed on the programmer 112 or the security controller 114 of the programming unit 110. The security algorithm 304 may be associated with all or at least a plurality of programming steps that the programming unit 110 executes to program the data and code associated with RoT into the device.

It has been found that RoT code 620 and RoT data 622 can be customized to enable selective programming for particular types and numbers of trusted hardware platforms 802. RoT code 620 and RoT data 622 may provide security algorithms 304 for a single device or thousands of devices served by trusted hardware platform 702. The security algorithm 304 provides an abstract interface on the programming unit 110 that allows the remaining security information to be written to the programmable device 128. For example, the security algorithm 304 may be customized for applications such as programming FLASH-specific, EEPROM-specific, HSM-specific, and iPhone-specific. Basically, the security algorithm 304 can support a single device type and perform specific programmatic tasks. In a secure programming environment, the security algorithm 304 may write security information or trip a security fuse to a particular block in the flash memory.

The security algorithm 304 simplifies security programming by abstracting the complexity of mapping critical security use cases to the system. This enables such security APIs to be embedded into the devices by the security algorithms 304, wherein such security algorithms 304 may be customized on a device-by-device basis. The security algorithm 304 may provide a new paradigm for programming proprietary code into various devices while preventing unauthorized access to proprietary code resources. The security algorithm 304 represented by the security API may simplify the manufacturing process, protect proprietary code, and prevent piracy by preventing programming of unauthorized devices.

The security algorithm 304 may be customized to provide specific support for storing data and code for each RoT in the secure storage of the target device. The security algorithm 304 may also configure data and code to execute in secure execution based on the secure execution characteristics of the device. The security algorithm 304 exposes the secure API interface to firmware for proprietary execution.

Referring now to fig. 9, an example of a management and security processing system 902 (MSP system) is illustrated. MSP system 902 can securely deploy and provide programmable device 128.

The MSP system 902 can separately configure data devices with encryption information and active trusted devices to provide a secure programming and operating environment. MSP system 902 may allow for secure programming of programmable device 128 at a secure Original Equipment Manufacturer (OEM) site.

MSP system 902 may be one embodiment of security programmed system 100. Components of MSP system 902 can be implemented using components of secure programming system 100.

The MSP system 902 may support the operation of portions of the system distributed across multiple locations or sites. The MSP system 902 may include an OEM development site 940 and a factory site 942. The OEM development site 940 may be used to prepare the actual programming and provisioning of the programmable device 128. The OEM development site 940 may be used to prepare information for programming multiple plants. The OEM development site 940 prepares the location of a programming project 944 for the OEM, the programming project 944 having information for configuring a set of secure devices (e.g., programmable devices 128, security components, trusted devices 130, or other similar devices).

Although there are differences between different types of security devices, the terms are generally understood to be interchangeable and generic in nature. For convenience and brevity, security devices, security components, programmable devices 128, trusted devices 130, and other similar components may be used interchangeably in this specification.

An OEM development site 940 may obtain a firmware image 914 for providing the programmable device 128 and preparing a programming project 944. The programming items 944 may then be securely transferred to the factory floor 942 and may be used to control the programming of the programmable device 128.

The OEM development site 940 may have a set of secure manufacturing systems and data stores for facilitating the creation of the programming project 944. For example, the OEM development site 940 may include OEM keying material 904, OEM secure boot loader 906, OEM firmware development system 908, OEM control tools 910, firmware update service 912, and OEM management system 924.

The factory floor 942 is a location for programming and supplying the programmable device 128. The factory floor 942 may be a programming center, manufacturing facility, contract manufacturer site, or the like. In an embodiment, the factory floor 942 is where the programmer 112 and the programmable device 128 are located and operated.

MSP system 902 may include a secure boot loader 918. The secure boot loader 918 is secure programming code that may be executed when the programmable device 128 is booted to ensure compliance with a security protocol. The OEM secure boot loader 906 establishes a device identifier, establishes the ability to accept the encrypted data stream and decrypt on the device, and initializes the secure runtime environment on the device so that firmware can be securely executed on the device.

The MSP system 902 may also include security firmware 920. The security firmware 920 is software code and data to be embedded in the non-volatile memory of the programmable device 128. The secure firmware 920 may be transferred in an encrypted state and decrypted at the programmer 112.

MSP system 902 may include a firmware decryption key 922. The firmware decryption key 922 may be used to decrypt the secure firmware 920 that has been encrypted using an encryption key associated with the firmware decryption key 922. For example, the firmware decryption key and encryption key may be part of a symmetric key pair used for encryption.

The MSP system 902 may include a firmware image 914 from an OEM. The firmware image 914 is embedded application code that is loaded by the OEM secure boot loader 906 and run on the programmable device 128 during and after manufacturing.

The MSP system 902 may include OEM keying material 904. The OEM key material 904 may include information such as a silicon vendor device authentication key 955, an OEM device credential signing key 947 required to sign the OEM device credential 946, and an OEM device credential template 950.

OEM credential template 950 is a set of information used to form OEM credential 951. Which includes the basic necessary information of the OEM credential 951. The OEM credential 951 is a set of information that defines an OEM customer 968. The OEM credentials 951 may include an OEM identifier 966, an OEM public key 962, and an OEM private key 952. The OEM identifier 966 is a value that uniquely identifies the OEM.

A silicon vendor is an entity that can manufacture or provide the programmable device 128. The silicon vendor may be identified by a silicon vendor identifier 956. The silicon vendor identifier 956 is a value linked to the silicon vendor. For example, the silicon vendor identifier 956 may be linked to the company that actually manufactures the integrated circuits or components that form the programmable device 128. The silicon vendor may also be a company that pre-configures the programmable device 128 prior to programming by transferring the programmable device 128 through the system.

The MSP system 902 may include an OEM firmware development system 908. The firmware development system 908 supports development of a firmware image 914 for deployment to the programmable device 128.

MSP system 902 may include an OEM control tool 910 (OMT). The OEM control tool 910 is a secure application or system that can bind the OEM secure boot loader 906 to the firmware image 914. The OEM control tool 910 may sign and encrypt the firmware image 914 and prepare the firmware image 914 for field updates. The field update may allow for remote changes to firmware deployed in the programmable device 128 in a reliable manner. The OEM control tool 910 may generate the secure firmware 920 by encrypting the firmware image 914 using the firmware decryption key 922. The OEM control tool 910 may include an HSM or a TSM and may be implemented by hardware or software.

MPS system 902 may include OEM management system 924.OEM management system 924 is a system for defining programming projects 944 for OEM users. The programming item 944 is a packet of information defining a safe production run for the programmable device 128.

OEM management system 924 may bind OEM secure boot loader 906, firmware image 914, OEM credentials 951, OEM keying material 904, and production count 948 to programming item 944. Once the programming item 944 begins to be created, the programming item 944 may be updated with references, code, and data including the OEM secure boot loader 906, the firmware image 914, the OEM keying material 904, the OEM credentials 951, and the production count 948. The binding program means that the information is part of the parameters of the programmatic item 944. The OEM management system 924 may also bind the programmatic item 944 to a particular secure programmatic system at the factory floor 942. The programmatic item 944 may include the system identifier 814 of the programmatic system or subsystem (e.g., the safety programmatic system 100, the programmatic unit 110, the programmer 112, or a combination thereof). Next, programmatic item 944 can only be executed on systems having system identifiers 814.

The production count 948 is a pointer that describes the number of safety devices to be produced in a production run. The production count 948 may be compared to the number of increments updated when the security device begins or completes production. Programmer 112 receiving programming project 944 may use production count 948 to limit the number of devices programmed and provisioned to prevent unauthorized production of programmable device 128. During production, the current count 978 may indicate the current number of products that have been produced. The system may stop programming by comparing the current count 978 to the production count 948, and stop programming when the current count 978 equals the production count 948.

The OEM management system 924 may be configured in various ways. For example, the OEM management system 944 may be implemented in a shared configuration and the programming 944 may be generated for deployment to a plurality of OEMs each having their own factory (e.g., factory floor 942). A secure main storage system 102, a secure main system 104, a secure programming system 100, or a combination of the above systems and subsystems may be used.

The MSP system 902 can include a factory management system 930. The factory management system 930 is a system for managing safety programmed components at a factory floor 942. The factory management system 930 may receive the programming items 944 and decryption from the OEM management system 944 and distribute the manufacturing information to other security and programming systems located at the factory floor 942.

The plant management system 930 may be implemented in various ways. For example, the fab management system 930 may be implemented with the fab execution system 702, the programmed processor 202, a host computer system, or another similar processing system.

The MSP system 902 can include a plant safety system 932. The factory security system is an HSM-based security device that generates keys and credentials to be programmed into the programmable device 128. The factory security system 932 may support multi-tenant OEM architecture by isolating security information of one OEM from security information of another OEM. This allows the factory safety system 932 to program and set up different sets of different OEM programmable devices 128 for different programmers.

The plant safety system 932 may be configured in various ways. For example, the plant safety system 932 may be implemented using the safety host system 104, the safety controller 114, the programmed processor 202, the first safety module 116, the second safety module 118, the nth safety module 120, or a combination thereof. The plant security system 932 may be implemented in a centralized fashion or a decentralized fashion using one or more security components in the MSP system 902.

The plant security system 932 may provide high security cryptographic services including key pair generation, encryption, decryption, credential management, secure storage, secure execution, and other similar secure processing features. The plant safety system 932 may also support safety development, safety control, safety deployment data and code, safety settings, safety programming, and safety updates.

The plant security system 932 may perform device authentication based on device credentials, deployment management and versioning, digital lifecycle management, and application management. The plant security system 932 may provide symmetric encryption, hashing functions, data encapsulation, digital signatures, key agreement and transmission, key management, and user access control.

The plant security system 932 may include plant security system credentials 933 for authenticating the identity of the plant security system 932. A plant security system credential 933 may be used to sign information communicated from the OEM development site 940 and the OEM management system 924 to the plant management system 930 and the plant security system 936. The plant security system 932 may include a plant security system data encryption key 980 and a plant security system data authentication key 982. The key may be used to securely encrypt, decrypt, sign, and verify secure information.

The MSP system 902 can include a host system 936 at a factory site 942. The host system 936 is a computer system that controls the execution of the programming items 944 and manages the communication between the programmer 112 and the plant safety system 932.

The host system 936 may be implemented in various ways. For example, host system 936 may be implemented using secure controller 114, programmed processor 202, or another similar computing system coupled to secure processing system 100. The host system 936 may be coupled to the plant safety system 932, the programmer 112, the plant management system 930, or other similar systems.

MSP system 902 may include a programmer 112 for programming programmable device 128. The programmer 112 may receive a set of blank or partially programmed devices and use information from the programming project 944 to securely program the programmable device 128.

The programmer 112 may create a serial data list 964 for programming the programmable device 128. The serial data list 964 is a list of device specific data to be programmed into the programmable device 128. This may include firmware images 914, OEM device credentials 946, code, data, or other information. The serial data list 964 may vary based on individual device information, such as serial numbers, device identifiers, data credentials, or similar device-specific parameters.

MSP system 902 may include device credentials for protecting programmable device 128. The device credentials may include silicon vendor device credentials 926, original equipment manufacturer device credentials 946 (OEM device credentials 946), or other device credentials. The device credentials may include information about the programmable device 128 including the public key, a device identifier 302, a silicon vendor identifier 956, an OEM identifier 966, or other similar information.

The silicon vendor device credential 926 is a set of data elements that securely defines the identity of one of the security components, such as the programmable device 128 or the trusted device 130. The silicon vendor device credential 926 may include a device identifier 302, a silicon vendor public key 954, and/or other security information. The information encrypted by the silicon vendor private key 958 may be decrypted using the silicon vendor public key 954 of the silicon vendor key pair 960.

The silicon vendor device credentials 926 can be programmed into the secure storage unit of the secure element by the silicon vendor or manufacturer before the secure element is transmitted to other manufacturers or users. The silicon vendor device credential 926 may be stored in a write-once secure storage unit, wherein additional information may be added to the silicon vendor device credential 926 but existing information cannot be erased or modified. When no further modification is required, portions of the secure storage unit may be locked. The secure storage unit may include one or more data elements, such as device credentials and other related security data.

The silicon vendor device credential 926 may be implemented in various ways. For example, the silicon vendor device credential 926 may be implemented using the manufacturing token 510, the security credential 306, the security algorithm 304, the product token 508, the operation token 514, the input root of trust 504, the trust credential 402, or another similar data element.

The MSP system 902 can include a device data tracking system 934 for providing device-level programmed statistics in real-time. The device data tracking system 934 may track device level information for the security programming system 100 or remotely located devices in the local factory. Device data tracking system 934 can track device level information for each programmable device 128 configured by programmer 112 in MSP system 902. The device data tracking system 934 may track data such as the silicon vendor device credential 926, the system identifier 814, the device identifier 302, or other data elements programmed into the device. The device data tracking system 934 may track device states including valid states, configuration states, replica states, or other device-level states.

MSP system 902 may include a device provisioning service 938. The device provisioning service 938 is a system that provisions programmable devices 128 over the internet. The device provisioning service 938 may be a combination of hardware and software that can securely transmit provisioning information to the field programmable device 128. The device provisioning service 938 may distribute security information, data updates, software updates, and other security and operational information needed for continued secure operation of the device.

MSP system 902 may include firmware update services 912. The firmware update service 912 is a system for updating the firmware of the programmable device 128 on the internet (e.g., OEM cloud 928). The firmware update service 912 may securely send firmware updates 916 to a system having one or more programmable devices 128 and update the programmable devices 128 with new firmware. The firmware update 916 is a software and data packet used to update the firmware in the programmable device 128. The firmware update service 912 may be part of a system with secure software and hardware that can deploy firmware updates 916 and associated security information to ensure that the programmable device 128 is safely updated.

MSP system 902 can be operated in various ways. In an illustrative example, MSP system 902 can be operated based on security component use cases 970. The secure component use case 970 may describe one way to securely program the programmable device 128 using the MSP system 902, where the programmable device 128 is ready to be configured with firmware and has the silicon vendor device credentials 926 pre-installed at the silicon vendor equipment.

Security component use case 970 may contain two main steps. In step 1, a silicon vendor device credential 926 is extracted from one of the programmable devices 128 and the device is authenticated. In step 2, an OEM device credential 946 is established based on the silicon vendor device credential 926 that authenticates the device. Next, the OEM device credential 946 is programmed into the device.

In such a use case, the HSM-based security system (e.g., the plant security system 932) may be integrated as part of a security programming system (e.g., a system for programming a secure microcontroller unit having integrated security regions). The integrated secure enclave may be a protected area of memory that may be written once without change. This allows for the non-modifiable storage of secure data, such as keys, code or credentials.

The system may include an OEM management system 924, a factory management system 930, a job creation and job transfer system, and a device data tracking system 934 for managing status data of the programmable device 128. The various systems may be implemented in various ways. For example, the OEM management system 924, the factory management system 930, the job setup and job transfer system, and the device data tracking system 934 may all be implemented as software on the host system 936. In another example, the systems may each run on dedicated hardware.

In this security model, the factory floor 942 may act as an agent for OEM users and may perform the functions of the OEM management system 924. This effectively means that the OEM user 968 implicitly trusts the factory floor 942 by providing the OEM keying material 904 and OEM certificate 951 and setting the production count 948 with the programmable device 128. Thus, the activities are performed on the host system 936 of the programming unit 110, so that the job setup, the generation of OEM keying material 904, and the configuration of the secure programming system 100 are performed by authorized personnel at physically secure locations within the factory floor 942.

Some implementations may focus on providing the OEM device credentials 946 onto the programmable device 128 configured as a secure component. However, it should be understood that the flow of the OEM key material 904 secured by the OEM system and the updating of the secured production count 948 is protected by physically secure components and a secure data channel.

Because the data is encrypted and connected to a particular one of the plant security systems 932, the OEM data from the OEM development site 940 is secure and the OEM data is encrypted in its entirety by the OEM management system 924 up to the plant security systems 932. For example, the programming item 944 may be encrypted using a factory security system credential 933, the factory security system credential 933 being decryptable by only an intended one of the factory security systems 932.

In another example, the transfer of the OEM key material 904, including the OEM device credential signing key 947, is done securely (since the material is encrypted during transmission). The OEM device credential signing key 947 may include a private key component.

In the illustrative example, the import completion is reliable because private key 152 of programmable device 128 never leaves the device and with OEM device credential signing key 947 into OEM management system 924. Since the data is encrypted, the need for physical security may be reduced.

In another illustrative example, MSP system 902 can be operated based on a microcontroller unit use case 972 in which MSP system 902 is used to provision programmable device 128 and trusted device 130, such as a secure microcontroller unit. The secure microcontroller unit may include secure processing and secure storage facilities.

MCU use case 972 may include two main steps. In a first step, the OEM secure boot loader 906 may be programmed into the programmable device 128. Thereafter, the OEM secure boot loader 906 may be used to boot the programmable device 128 to establish the device authentication key pair 974 and the device decryption key pair 976 for the programmable device 128. Portions of the two key pairs may then be used to establish, program, and sign the OEM device credential 946.

In a second step, MSP system 902 can read silicon vendor device credentials 926 and verify programmable device 128. The firmware decryption key 922 may be encrypted with a device decryption key from the silicon vendor device certificate 926. The encrypted firmware and the encrypted firmware decryption key 922 may be programmed on the programmable device 128.

The OEM secure boot loader 906, the OEM firmware development 908, the OEM control tool 910, the OEM management system 924, and the generation of the OEM keying material 904 may all be performed at the OEM development site 940. The OEM user 968 controls the overall project definition and the determination of the production count 948.

The OEM software execution environment may be hosted on a computer at the OEM development site 940. All OEM trust roots may be securely transferred from the OEM development site 940 to the factory site 942. The plant management system 930, the plant safety system 932, and the device data tracking system 934 may be executed at a plant site 942 on a host system 936.

In an embodiment, this first step must be performed in a secure facility (such as an OEM-trusted factory, silicon vendor, OEM factory, or programming center) because it requires secure provisioning of the programmable device 128. Step two may then be performed at a facility with a lower security level, such as an untrusted factory, a contract manufacturer, a third party partner, or similar type of facility.

In this security model, an OEM root of trust and programming 944 is defined at the OEM development site 940, and this OEM root of trust and programming 944 is distributed to the plant site 942. It is important that OEM users manage their own root of trust to improve the security of the OEM product supply chain.

In the illustrative example, the MCU use case 972 requires physical security because the key pair 150 of the programmable device 128 is generated in the plant security system 932 and this key pair may be exposed at the plant site 942. The physical connection between the programmable device 128 and the programmer 112 is clear so that people with physical access to the systems of the factory floor 942 can snoop and steal important information. Thus, entity security should be implemented to protect the secure information.

In an alternative example of the MCU use case 972, the programmable device 128 may be blank and not pre-programmed with the silicon vendor device credentials 926. In this case, the OEM device credential 946 may be used for authentication. Further, the firmware decryption key 922 may be encrypted using a public decryption key (e.g., OEM public key 962) from the OEM device credential 946.

Referring now to fig. 10, a detailed example of a security component use case 970 is illustrated. The security component use case 970 describes a process for securely configuring a security component (e.g., the programmable device 128). The MSP system 902 can securely deploy and provide each programmable device 128 according to the secure component use cases 970.

In the security component use case 970, the security components may be instantiated, transmitted and managed at different sites. The site may include different types of locations (e.g., silicon manufacturer 1004, OEM location 1006, programming center 1008, programmer location 1010, and device location 1012). Each venue represents a location where some type of security programming related to an action may occur. In addition, use cases may include data and actions embedded at the programmer 112 and device locations 1012.

The security component use case 970 may include three different sequences of events, each for performing a different security activity. In a first sequence 1014, MSP system 902 may initialize factory security system 932 using OEM management system 924. This may be performed at the OEM development site 940, the factory site 942, or another similar location.

The MSP system 902 may also initialize the factory management system 930 at the factory floor 942, the programming center 1008, or another similar location. Factory management system 930 may be updated with current count 978, silicon vendor public key 954, OEM private key 952, and OEM device credential template 950. The plant management system 930 may forward the information to the plant safety system 932 for safe processing.

In the second sequence 1016, the secure component is programmed at the Silicon Vendor (SV) factory using the silicon vendor device credentials 926.

In a third sequence 1018, MSP system 902 can cryptographically authenticate each device (e.g., programmable device 128 or trusted device 130) using silicon vendor device credentials 926 pre-installed in second sequence 1016. Next, an OEM device credential 946 can be created and programmed into the programmable device 128.

The OEM device credential 946 may be established by reusing a public key portion of the device identification key pair from the silicon vendor device credential 926, such as the silicon vendor public key 954. Thus, the silicon vendor public key 954 may be used to compute the OEM device credentials 946 so both credentials are authenticated using the same credentials. Alternatively, a different key pair may be used to represent an OEM identifier separate from the silicon vendor key pair. This may be performed by the plant safety system 932 or the safety component itself.

In a second sequence 1016, step 1020 is performed at the silicon manufacturer 1004. Silicon manufacturer 1004 may be a company that establishes an original security component. A silicon vendor device credential 926 is established for each security component (e.g., the programmable device 128 or the trusted device 130). The silicon vendor device credential 926 may include unique information about each secure component (e.g., device identifier 302, serial number, product type, date of manufacture, or similar device information).

Step 1022 is also performed at the silicon manufacturer 1004. Each of the silicon vendor device credentials 926 is signed using a silicon vendor private key 958 and a silicon vendor identifier 956 of the silicon manufacturer. The silicon vendor device credential 926 is signed to encrypt the data of the credential. The data can only be decrypted using the silicon vendor public key 954.

Step 1024 is also performed at the silicon manufacturer 1004. Each of the programmable devices 128 is programmed with a silicon vendor device credential 926 that is signed with a silicon vendor private key 958. The silicon vendor device credential 926 signed by the silicon vendor private key 958 shows that the silicon vendor approved or provided the device. Successfully decrypting the silicon vendor device credential 926 using the silicon vendor public key 954 can verify that the programmable device 128 is from the silicon vendor that signed it.

The second sequence 1016 may uniquely mark each programmable device 128 with a unique and separate entity of the silicon vendor device credential 926 that has been further signed using the silicon vendor private key 958. This provides that the silicon vendor device credential 926 can be deciphered using the silicon vendor public key 954 to verify that the silicon vendor device credential 926 is provided by the silicon vendor with the silicon vendor identifier 956. This allows a factory or other device user to determine the authentication of the programmable device 128.

The first sequence 1014 is performed at silicon manufacturer 1004, OEM location 1006 and programming center 1008. The first sequence 1014 may configure programming components at the programming center 1008 for safety programming.

In step 1030, the silicon vendor may generate a silicon vendor key pair 960 with a silicon vendor public key 954 and a silicon vendor private key 958. This may be a silicon vendor key pair 1080 with a silicon vendor private key 958 and a silicon vendor public key 954.

In step 1032, the silicon vendor public key 954 may be transmitted to the OEM user 1006. The silicon vendor public key 954 may be sent in an explicit and unencrypted manner. For example, the silicon vendor public key 954 may be sent over a network link.

In step 1034, the OEM user 1006 may register the OEM voucher 951 with the factory management system 930 and the factory security system 932 of the programming center 1008. The OEM credentials 951 may include the OEM public key 962 for decryption and authentication of information encrypted or signed using the OEM private key 962. Registration of OEM credentials at programming center 1008 may be performed securely to provide programming center 1008 with secure information of OEM users 1006. Registration may be performed to introduce and recognize OEM credentials into the factory management system 930 and the factory security system 932.

In step 1035, the plant management system 930 and the plant security system 932 may send the plant security system encryption key 980 to the OEM management system 924 in a secure exchange process. The factory security system data encryption key 980 may be used to encrypt information sent from the OEM user 1006 to the factory management system 930 and the factory security system 932 to support secure transmission of the information. Factory security system 932 may send factory security system data encryption keys to OEM management system 924.

In step 1036, the OEM user 1006 may create a package with SV device authentication public key, OEM device credential signing key and OEM device credential template 950. The OEM device credential signing key may be established in the OEM management system 924 or imported from an external security system (e.g., an external HSM). The factory security system data encryption key 980 may be used to encapsulate a packet in the OEM management system 924, which is then sent to the factory management system 930 and the factory security system 932. Since the sealed package has been encrypted using the plant security system data encryption key 980 in the plant security system 932, decryption can only be performed using the plant security system data authentication key 982 of the plant security system 932. The OEM device credential template 950 is a template of the OEM device credential 946 and is then signed by the OEM private signing key, this template including the public key 152 of the device with the device identifier 320. The OEM public key 962 is an encrypted value associated with the OEM user 1006. The OEM public key 962 has various formats. For example, the key may be formatted as an X.509 public key certificate or another public key format. The x.509 standard defines a public key certificate to show ownership of the public key. The OEM public key 962 may provide authentication information for the public key. The OEM public key 962 may be used for device authentication in the programming center 1008.

In step 1038, the OEM user 1006 may send a packet with the silicon vendor public key 954, the OEM private key 952 and the OEM device authentication template 950 to the programming center 1008. The information in the packet may then be used to sign the programmable device 128.

The third sequence 1018 is executed on the programmer 112 and the programmable device 128 at the programming center 1008 or at the factory floor 942. A third sequence 1018 can authenticate the security component, provision and cryptographically sign the security component with OEM information, and verify that the configured device is authorized.

In step 1040, the programmer 112 may read the silicon vendor device credential 926 of each programmable device 128 to be programmed. The silicon vendor device credential 926 is explicitly transmitted from the programmable device 128 to the programmer 112.

In step 1042, the silicon vendor device credential 926 may be transmitted from the programmer 112 to the factory management system 930 and the factory security system 932. The plant management system 930 controls the programming operations and the plant safety system 932 manages the device and system safety.

In step 1044, the silicon vendor device credential 926 is received at the factory management system 930 of the programming center 1008. The programmer 112 is located at the factory floor 942.

In step 1046, the programmable device 128 may be authenticated using the silicon vendor public key 954. This step confirms that the device to be programmed is provided by the silicon vendor having the silicon vendor identifier 956. The programmable device 128 is authenticated when the silicon vendor device credential 926 signed using the silicon vendor private key 958 in sequence 1 is decrypted using the silicon vendor public key 954. If the silicon vendor public key 954 can be used to access information in the silicon vendor device credential 926, the device is authenticated.

In step 1048, the OEM device credential 946 is formatted based on the OEM device credential template 950. The OEM device credential 946 is then signed with the OEM private key 952.

In step 1050, the OEM device credential 946 is transmitted to the programmer 112. Because OEM device credential 946 is encrypted and signed using OEM private key 952, OEM device credential 946 may be communicated transparently.

In step 1052, the programmer 112 may build a serial data list 964. The serial data list 964 is a list of device specific data to be programmed into the programmable device 128. This may include a serial number, device identifier, OEM device credential 946, manufacturing mark, code, data, mark, MAC address, device private key, or other information.

In step 1054, the device specific data included on the serial data list 964 may be programmed into the programmable device 128 by the programmer 112. The serial data list 964 may indicate the location where device specific data should be stored. For example, the OEM device credential 946 may be stored in a secure storage unit.

In step 1056, the silicon vendor device credentials 926 and the OEM device credentials 946 are retrieved and retrieved by the programmer 112 from a secure component (e.g., the programmable device 128 or the trusted device 130). Although copies of the silicon vendor device credential 926 and the OEM device credential 946 may already exist in the factory security system 932 or elsewhere in the system, the device credentials are re-extracted to verify the programmable device 128 and detect potential duplicate production runs, unauthorized copying, or other improper activity. A verification step may be used to ensure that the device credential has been programmed and has no errors. This may include programming failures, device damage, bit errors, or the like.

In step 1058, the silicon vendor device credential 926 and the OEM device credential 946 are sent to the factory security system 932 for verification and further use. The retrieved device credentials may be used for a second round of authentication to verify that the correct one of the programmable devices 128 is programmed. This can be used to prevent unauthorized copying of the programmable device 128 and to prevent counterfeiting of the device.

In step 1060, the silicon vendor device credential 926 and the OEM equipment credential 946 are verified to ensure that the programmable device 128 is correct. This may include verifying the silicon vendor device credential 926 using the silicon vendor public key 954 and verifying the OEM device credential 946 using the OEM public key 962. Verification of the device credential involves comparing the public key in the device credential with the public key in the silicon vendor credential 1078 to ensure that both of these public keys match. In addition, the credential may be processed by a credential verification tool (not shown) to ensure that the format of the credential is valid. The factory security system 932 is also used to verify the signature on the credential.

In step 1062, the verification result is sent back to the programmer 112. In step 1064, the programmer 112 may process the completed device. If the programmable device 128 is not verified, the programmer 112 may identify devices having a verified status indicating a bad device and transfer the devices to a bad device container (not shown) for disposal. If the programmable device 128 is properly verified, the programmable device 128 may be updated with the verified status values and passed as verified components. Alternatively, the programmer 112 may generate a verification report to record the device identifier and verification status of each programmable device 128 in a production run. The inactive programmable device 128 may be removed or destroyed at a later time.

Referring now to fig. 11, an example of a use case 1102 on a device is illustrated. The seed use case 1102 on the device may be executed in a hardware security module at the original equipment manufacturer location.

In the on-device seed and credential generation use case 1102, security components can be instantiated and managed across multiple locations. The location may include various configurations. The locations may include a silicon manufacturer 1104, an original equipment manufacturer 1106, a programming center 1108, a manufacturing center, or the like. In addition, use cases may include data and actions embedded at the programmer 112 level and the device level 1112.

In step 1122, the blank programmable device 128 and the reference boot loader software may be provided to the silicon-on-microcontroller unit vendor and the blank programmable device 128 and the reference boot loader software may be physically transferred to a second location (e.g., the OEM 1106) for further processing. The physical transfer is a secure physical transfer to prevent unauthorized access to the blank programmable device 128 and the security software.

In step 1124, the programmable device 128 may be received at a second location, such as an OEM. The OEM may develop the secure kernel and secure boot loader by modifying the reference boot loader software. The OEM may also develop and provide an encrypted firmware image and a firmware encryption key (UPK). The OEM may also provide the total number of devices that need to be produced. The security kernel and seed kernel may be maintained in a first hardware security module (HSM # 1) device at the OEM and may be provided to the programming center by encrypted transmission to a second hardware security module device (HSM # 2) at the site.

In step 1126, the second hardware security module of the security device may send the seed kernel to the programmer 112. Seeds were generated on HSM #2 of the device. The seed kernel needs to be programmed into the device, which will execute on the device to generate the seed and key pair. The public key will enter the device credential and the private key can be programmed into the device.

Step 1126 may send the seed kernel to the programmer 112, and the programmer 112 programs the seed kernel into the device. Then, the device is restarted and the seed kernel is executed. The seed core may generate a key pair. The private key is stored in a hidden memory area on the device. The public key (Kpub) is returned to the HSM #2.HSM #2 may also generate signed credentials, merge these signed credentials with the security kernel, and program them into the device.

This use case is the most secure use case since the device secret, seed core and subsequent private key are generated in HSM #2 and are not exposed outside the device. The public key may be sent and exposed outside the device. Thus, even if some data is exchanged in a clear manner, the data exchange between the programmer 112 and the device is secure and security breaches are minimized. This is in contrast to the off-device seed use case 1102 where the security kernel and seed programming are explicitly transmitted between the programmer and the device. This may be a security hole if the data is intercepted and more stringent site security requirements are required.

In step 1128, the programmer 112 may program the trusted device 128 with the programmable payload P, and then lock the device from any modifications of the programmable payload. Because the device can generate the private key on demand at any time using the seed on the device, there is no need to program the private key of the key pair into the device. This generation of the private key is part of and can only be securely accessed by the security kernel.

In step 1130, one of the programmable devices 128 may be programmed with the seed core. After installing the seed core, step 1128 may continue and the programmer may issue a reboot command to the device.

In step 1132, the device may generate the device seed and security key 106, and then generate and send the public key to a programmatic center level, such as the MES. The public key may be sent in a clear manner (since the public key may be shared; the public key is not a hidden value).

In step 1134, the system may generate and sign a device credential. The security kernel may then be merged with the device credential and sent to the programmer 112. The merged security kernel is sent using an encrypted transmission that uses the programmer's credentials.

In step 1136, the programmer 112 may receive the security kernel and provide one of the security devices 128 with the security kernel. The security kernel may be sent to one of the programmable devices 128 using an encrypted transport channel (this channel uses a public key).

In step 1138, the device may decrypt and install the security kernel. Further, a signature may be added to the device. After the core is installed, step 1136 may send a reboot command to the device, and the device may return the credential in step 1140.

In step 1142, the secure device generates a device-specific super-encrypted UPK using the public data encryption key from the device credential of the device. The super-encryption key and encrypted firmware image may then be sent back to the programmer 112 for programming to one of the programmable devices 128.

In step 1144, the encrypted file may be programmed into one of the programmable devices 128. The encrypted file may be transmitted to one of the programmable devices 128 as an encrypted file using the public key.

In step 1146, the programmer 112 may transfer the encrypted file to one of the programmable devices 128, where the image is decrypted and installed into one of the programmable devices 128. The installation of the image is authorized and verified by sending the credential and the module list back to the programmer 112.

In step 1148, the programmer 112 may verify the installation of the encrypted file on the programmable device by matching the list of credentials and modules to a list of known credentials and modules.

Generating the device seed in the second hardware security module at the programming center increases the overall level of manufacturing security by reducing the number of opportunities to compromise the security components. Because the programming center is a monitored environment (24 hour per day video monitoring), the programmable device 128 can be programmed with greater security and integrity.

3.0 functional overview

The security programming system 100 may configure and provide security components (e.g., the programmable device 128 and the trusted device 130) in a variety of ways. Depending on the type of operations performed on the security component, different levels of security may be implemented. Different use cases and process flows can be implemented on the same physical system to accommodate different end user requirements.

Referring now to fig. 12, a first example of a flow diagram for an embedded trusted root system 1200 is illustrated, according to an embodiment. The various components of the trusted device (e.g., 802) may be executed in various systems, including systems such as the secure programming system (e.g., 100) described above. In an embodiment, each of the processes described in connection with the functional blocks recited below may be implemented using a set of secure hardware and a secure manufacturing process that are verified using a trusted hardware platform at each stage of sub-component manufacturing.

The flow diagram of embedded root of trust system 1200 includes: root-of-trust data (e.g., 622) is established in the semiconductor device in block 1202. Trust root data may include identification sequences designed into circuits of a semiconductor device to be configured during a semiconductor device manufacturing process.

Flow may proceed to identifying a build plan for a manufacturing execution system (e.g., 702), which includes determining the number and configuration of semiconductor devices in block 1204. The requirements of the manufacturing execution system may be identified and customized from the semiconductor manufacturer. In the case of third party manufacturing, an OEM may order semiconductor devices that are configured and shipped to an assembler to support the build plan.

Flow may proceed to block 1206 to generate root-of-trust code (e.g., 620), where the root-of-trust code may be generated to support a build plan for the manufacturing execution system. The root of trust code may limit the actual processing of a semiconductor device to a precise number of devices. The root of trust code may identify which circuits may be coupled to the semiconductor device and the characteristics of the coupled semiconductor device (e.g., manufacturing date, serial number range, revision level, manufacturing location, etc.).

Flow proceeds to compute the manufacturing token in block 1208, where the Trust root code may use the Trust root data to compute the exact number of ID tokens (e.g., 624), provide an encryption token (e.g., 626), and a key token (e.g., 628) that may be used when programming the subcomponents comprising the semiconductor device. The key token and the encryption token may be used when the firmware is loaded onto the sub-component. Each assembly and programming phase of a trusted hardware platform (e.g., 802) may be managed by embedded root of trust system 1200.

Flow proceeds to verify firmware integrity in block 1210. Integrity of code information is exchanged between systems or devices. The code signing module (e.g., 322) uses a digital signature to verify whether the contents of the exchanged information have been altered or tampered with, which may be verified using an OEM device credential signing key (e.g., 947) or a signature stored in the root of trust data.

Referring now to fig. 13, a second example of a flow diagram for an embedded trusted root system 1300 is illustrated, according to an embodiment. The various components of the trusted device (e.g., 802) may be executed in various systems, including systems such as the secure programming system (e.g., 100) described above. In an embodiment, each of the processes described in connection with the functional blocks described below may be implemented using a secure hardware set and a secure manufacturing process that are verified by a trusted hardware platform at each stage of sub-component manufacturing. A second example may be used to program an OEM credential (e.g., 951) into a programmable device (e.g., 128) using an OEM identifier (e.g., 966). Alternatively, the second example may be used to program an OEM device credential (e.g., 946) identifying a particular OEM device into a programmable device.

The flow diagram of the embedded root of trust system 1300 includes generating a security algorithm (e.g., 304) to embed a root of trust (RoT) into a programmable device in block 1302. The security algorithm and RoT are stored in a RoT code register (e.g., 621) of the programmable device by a programmer (e.g., 112). A security algorithm may be generated using a programming project (e.g., 944) at an Original Equipment Manufacturer (OEM) development site (e.g., 940) and programmed into a programmable device by a programmer at a factory site (e.g., 942).

A security algorithm is a process performed by a hardware system. For example, the RoT may include at least an identification token (e.g., 624), an OEM credential (e.g., 951), and an OEM device credential. The OEM credential may include an OEM identifier (e.g., 966) and an OEM public key (e.g., 962). The OEM credential has only the OEM public key and no OEM private key (e.g., 952).

The security algorithm involves all or at least some of the programming steps performed by a programming unit (e.g., 110) to program data and code associated with the RoT to be programmed into the programmable device. The security algorithm includes a security code component (e.g., 314). The RoT code provides an Application Programming Interface (API) to external systems to control security functions on the trusted device (e.g., 130). The security algorithm may be customized or may be different from each trusted device of a set of trusted devices programmed at a factory floor (e.g., 942) using the same programming project. For example, the secure code components may include source code, executable code, library modules, link modules, configuration files, initialization data, hardware handles, or a combination thereof. Additionally, for example, the security algorithm may optionally be stored in a secure storage unit (e.g., 326) of the programmable device and executed in an execution unit (e.g., 324) of the programmable device. The security algorithm may typically be executed on a programmer (e.g., 112) and inject data and code related to the Trust root into the programmable device. Additionally, for example, security algorithms may be part of the traceable target operation but may rarely be stored on the programmable device. The security algorithms may be stored on the programmable device, but these security algorithms are typically not stored on the programmable device.

Flow may continue in block 1304 to execute a security algorithm on the hardware system. The hardware system may include at least a programmer, a plant safety system (e.g., 932), a host system (e.g., 836), an execution unit, or a combination thereof. For example, a safety controller (e.g., 114) of a programmer or programming unit executes a safety algorithm to generate safety information for a programmable device.

In block 1306, the security algorithm instructs the hardware system to generate security information including, but not limited to, a key pair. For example, a factory security system may be used to generate the key pair. The key pair may include an OEM device public key or a silicon vendor public key (e.g., 954) and an OEM device private key or a silicon vendor private key (e.g., 958).

At block 1308, the security algorithm instructs the hardware system to store the key to the programmable device. The programmer communicates with the execution unit to store the key pair in the secure storage unit.

In block 1310, the security algorithm instructs the hardware system to generate OEM device credentials using the OEM device public key. The OEM device credentials may be generated using a factory security system. The OEM device credentials may include an OEM identifier (e.g., 966). The OEM device credential may be signed by the factory security system using an OEM equipment credential signing key (e.g., 947).

In block 1312, the security algorithm instructs the hardware system to store the OEM device credential in the programmable device. An execution unit may be used to store the OEM device credential.

The security algorithm is completed when the OEM device credential is programmed into the programmable device. A security algorithm is specifically established for each programmable device. The code that constitutes the security algorithm may come from a job package or a programmatic project (e.g., 944). The security algorithm may be bundled with the data of the programmed project to be programmed into the programmable device.

Flow may proceed to verify the programmable device in block 1314 to ensure that the OEM device credential has the proper device credential and has been properly programmed. The programmable device may be verified by a programmer, a host system, a factory safety system, or a combination thereof.

For example, a programmer or host system requests the execution unit to retrieve OEM device credentials from the secure storage unit. The programmer or execution unit verifies whether the OEM device credential is signed by the OEM device credential signing key. The programmer or execution unit uses the OEM device public key in the OEM device credential to challenge the programmable device to decrypt the encrypted data stream. If the response (e.g., decrypted data stream) from the programmable device matches the original data stream from the programmer or execution unit, the programmed OEM device credential is verified.

In an embodiment, a factory management system (e.g., 930) manages multiple systems. The plant management system accepts an input or request from an OEM management system (e.g., 924) and passes this input or request to the plant security system.

Among other advantages, security algorithms are used to extract device-specific complexity of how to build and program the RoT, and extract complexity from OEMs by providing Application Programming Interfaces (APIs) to firmware on programmable devices to build abstraction layers so that the RoT can be manipulated with the firmware.

In embodiments, all secure transactions (e.g., key generation, key verification, signature generation and verification, etc.) may be performed using only the factory security system. The factory management system (e.g., 930) may not be used to perform such transactions.

In accordance with one or more embodiments, a system may be implemented for fraud detection and prevention of a programmable device (e.g., 128). Although examples of systems are described, other embodiments may be applied to any system operable to perform the functions described herein. The components of the system may be connected by, for example, a data bus, a data link, a Local Area Network (LAN), a Wide Area Network (WAN), the internet, an intranet, and an extranet. Any number of devices within the system may be directly connected to each other by wired or wireless communication segments.

4.0 exemplary embodiment

Examples of some embodiments are presented (but not limited to) in the following clauses:

according to an embodiment, a system comprises: an identification module implemented at least in part by hardware, the identification module to generate an identification token for use by the manufacturing execution system based on a root of trust data cache of the programmable device and a root of trust code cache of the programmable device; an encryption module implemented at least in part by hardware, the encryption module to calculate an encryption token and a key token for authenticating the trust data cache and the trust root code cache; an authentication module implemented at least in part by hardware, the authentication module to verify a trusted hardware platform based on the encryption token and the key token; and a code signing module implemented at least in part by hardware, the code signing module verifying the firmware integrity of the trusted hardware platform prior to programming the programmable device.

In an embodiment, the root of trust code cache includes a security algorithm generated using programming projects at an Original Equipment Manufacturer (OEM) development site, and the security algorithm is stored in a programmable device at the factory site by a programmer.

In an embodiment, further comprising a factory safety system implemented at least in part by hardware, the factory safety system storing a root of trust (RoT) in a programmable device based on a safety algorithm.

In an embodiment, wherein the programmer generates the security information for storage in the programmable device based on a security algorithm.

In an embodiment, the programmer stores the key pair in the programmable device based on a security algorithm.

In an embodiment, wherein the programmer generates the credential with the public key and the private key based on a security algorithm.

In an embodiment, wherein the programmer stores the credentials in the programmable device based on a security algorithm.

According to an embodiment, a method comprises the steps of: generating an identifier for use by the manufacturing execution system based on the root of trust data cache of the programmable device and the root of trust code cache of the programmable device; calculating an encryption identifier and a key identifier for authenticating the trust data buffer and the trust root code buffer; verifying the trusted hardware platform based on the encrypted token and the key token; and verifying the firmware integrity of the trusted hardware platform prior to programming the programmable device.

In an embodiment, further comprising the steps of: generating a security algorithm using a programming project at an Original Equipment Manufacturer (OEM) development site; and storing, by a programmer at the factory site, the security algorithm in a root-of-trust code register of the programmable device.

In an embodiment, further comprising the steps of: a root of trust (RoT) is stored in a programmable device based on a security algorithm.

In an embodiment, further comprising the steps of: security information for storage in the programmable device is generated based on a security algorithm.

In an embodiment, further comprising the steps of: the key pair is stored in the programmable device based on a security algorithm.

In an embodiment, further comprising the steps of: a credential having a public key and a private key is generated based on a security algorithm.

In an embodiment, further comprising the steps of: the credentials are stored in a programmable device based on a security algorithm.

Other examples of these and other embodiments may be found herein.

5.0 implementation mechanisms-hardware overview

According to an embodiment, the techniques described herein are implemented by one or more special-purpose computing devices. A special-purpose computing device may be a desktop computer system, portable computer system, handheld device, smart phone, media device, game control panel, network device, or any other device that includes hardwired and/or program logic to implement the techniques. A special-purpose computing device may be hardwired to perform the techniques, or may include digital electronics such as one or more Application Specific Integrated Circuits (ASICs) or Field Programmable Gate Arrays (FPGAs) that are continuously programmed to perform the techniques, or may include one or more general-purpose hardware processors programmed to perform the techniques according to program instructions in firmware, memory, other storage, or a combination. Such special purpose computing devices may also incorporate customized hard wired logic, ASICs, or FPGAs with customized programming to complete the technology.

Referring now to FIG. 14, there is illustrated a block diagram of a computer system 1400 used in implementing the above-described techniques in accordance with an embodiment. Computer system 1400 may be, for example, a desktop computing device, a laptop computing device, a tablet computer, a smart phone, a server appliance, a mainframe computing host, a multimedia device, a handheld device, a network appliance, or any other suitable device.

Computer system 1400 includes one or more buses 1402 or other communication mechanisms for communicating information, and one or more hardware processors 1404 coupled with bus 1402 for processing information. The hardware processor 1404 may be, for example, a general purpose microprocessor. The bus 1402 may include various internal and/or external components including, but not limited to, an internal processor or memory bus, a serial ATA bus, a PCI Express bus, a universal serial bus, a hypertransport bus, an Infiniband bus, and/or any other suitable wired or wireless communication channel.

Computer system 1400 also includes a main memory 1406 (e.g., a Random Access Memory (RAM) or other dynamic or volatile storage device) coupled to bus 1402 for storing information and instructions to be executed by processor 1404. Main memory 1406 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 1404. When such instructions are stored in a non-transitory storage medium accessible to processor 1404, such instructions cause computer system 1400 to become a special-purpose machine that is customized to perform the operations specified in the instructions.

Computer system 1400 further includes one or more Read Only Memories (ROM) 1408 or other static storage device coupled to bus 1402 for storing static information and instructions for processor 1404. One or more storage devices 1410, such as a Solid State Drive (SSD), a magnetic disk, optical disk or other suitable non-volatile storage device, are provided and coupled to bus 1402 for storing information and instructions.

Computer system 1400 can be coupled via bus 1402 to one or more displays 1412 for presenting information to a computer user. For example, computer systems 00 may be connected to a Liquid Crystal Display (LCD) screen via a high-definition multimedia interface (HDMI) cable or other suitable cable, and/or directly to a Light Emitting Diode (LED) television via a wireless connection (such as inter-level Wi-Fi). Other examples of suitable types of displays 1412 may include, but are not limited to, plasma display devices, projectors, cathode Ray Tube (CRT) screens, electronic paper, virtual reality headsets, braille terminals, and/or any suitable device for outputting information to a computer user. In an embodiment, any suitable type of output device (e.g., audio speakers or a printer) may be used in place of display 1412.

In an embodiment, the output of display 1412 may be accelerated by one or more Graphics Processing Units (GPUs) in computer system 1400. A GPU may be, for example, a highly parallelized multi-core floating-point processing unit that is highly optimized to perform computational operations related to the display of graphics data, 3D data, and/or multimedia. In addition to computing image and/or film data directly for output to the display 1412, a GPU may be used to take image or other film data off-screen and read this data back into the process for off-screen image processing with very high performance. Various other computational tasks may be offloaded from the processor 1404 to the GPU.

One or more input devices 1414 are coupled to the bus 1402 to communicate information and command selections to the processor 1404. An example of input device 1414 is a keyboard that includes alphanumeric and other keys. Another type of user input device 1414 is cursor control 1416, such as a mouse, a trackball, or cursor arrow keys for communicating direction information and command selections to processor 1404 and for controlling cursor movement on display 1412. The input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y) that allow the apparatus to specify positions in a plane. Other examples of suitable input devices 1414 include a touch panel secured to display 1412, a camera, a microphone, an accelerometer, a motion detector, and/or other sensors. In an embodiment, a network-based input device 1414 may be used. In such an embodiment, user input and/or other information or commands can be relayed from the input device 1414 to the network link 1420 on the computer system 1400 through routers and/or switches on a Local Area Network (LAN) or other suitable shared network, or through an inter-peer network.

Computer system 1400 can implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware, and/or program logic that, in conjunction with the computer system, makes or programs computer system 1400 into a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system 1400, which is responsive to processor 1404 executing one or more sequences of one or more instructions contained in main memory 1406 by processor 1404. Such instructions may be read into main memory 1406 from another storage medium, such as storage device 1410. Execution of the sequences of instructions contained in main memory 1406 causes processor 1404 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.

The term "storage medium" as used herein refers to any non-transitory medium that stores data and/or instructions that cause a machine to operate in a specific manner. Such storage media may include non-volatile media and/or volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 1410. Volatile media includes volatile memory, such as main memory 1406. Common forms of storage media include, for example, a floppy disk, a flexible disk, hard disk, solid state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, and any other memory chip or cartridge.

Storage media is distinct from but may be used in conjunction with transmission media. The transmission medium participates in transmitting information between the storage media. Transmission media include, for example, coaxial cables, copper wire and fiber optics, including the wires that comprise bus 1402. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.

Various forms of media are involved in carrying one or more sequences of one or more instructions to processor 1404 for execution. For example, the instructions may initially be carried on a magnetic disk or solid state drive of a remote computer. The remote computer can load the instructions into a volatile memory of the remote computer and send the instructions as modulated signals over a network, such as a cable network or a cellular network, using a modem. The computer system 1400 may receive data from the network and demodulate the signal to decode the transmitted instructions. Appropriate circuitry may then place the data on the bus 1402. Bus 1402 transfers data to main memory 1406 where instructions are retrieved from processor 1404 and executed. The instructions received by main memory 1406 may optionally be stored on storage device 1410 either before or after execution by processor 1404.

In one embodiment, computer system 1400 can also include one or more communication interfaces 1418 coupled to bus 1402. Communication interface 1418 provides a generally two-way data communication coupling to network link 1420, which network link 1420 is coupled to a local network 1422. For example, communication interface 1418 may be an Integrated Services Digital Network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, the one or more communication interfaces 1418 can include a Local Area Network (LAN) card to provide a data communication connection to a compatible LAN. As another example, the one or more communication interfaces 1418 can include a radio network interface controller (e.g., an 802.11 based controller, a bluetooth controller, a Long Term Evolution (LTE) modem, and/or other types of wireless interfaces). In any such implementation, the communication interface 1418 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

Network link 1420 generally provides data communication through one or more networks to other data devices. For example, network link 1420 may provide a connection through local network 1422 to a host computer 1424 or from a service provider 1426 to an operating data device. A service provider 1426, which may be, for example, an Internet Service Provider (ISP), then provides data communication services over a wide area network (e.g., the global packet data communication network now commonly referred to as the "internet" 1428). Local network 1422 and internet 1428 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 1420, and through communication interface 1418, which carry the digital data to and from computer system 1400, are exemplary forms of transmission media.

In one embodiment, computer system 1400 can send messages and receive data, including program code and/or other types of instructions, through the network(s), network link 1420 and communication interface 1418. In the Internet example, a server 30 might transmit a requested code for an application program through Internet 1428, ISP 1426, local network 1422 and communication interface 1418. The received code may be executed by processor 1404 as it is received, and/or stored in storage device 1410, or other non-volatile memory for later execution. As another example, information received over network link 1420 may be interpreted and/or processed by a software component of computer system 1400 (e.g., a web browser, an application, or a server), which in turn may be directed by the operating system and/or other intermediary layers of software components to processor 1404 based on its execution.

In embodiments, some or all of the systems described herein may be or include server computer systems that include one or more computer systems 140, the one or more computer systems 140 collectively implementing the various components of the system as a set of server-side processes. The server computer system may include a web server, an application server, a database server, and/or other conventional server components including the above-described components for providing the described functionality. The server computer system may receive network-based communications that include input data from various sources, including, but not limited to, user-operated client computing devices (e.g., desktop computers, tablet computers or smart phones, remote sensing devices, and/or other server computer systems).

In embodiments, some server components may be implemented in whole or in part using "cloud-based" components that are coupled to the system by one or more networks (e.g., the internet). The cloud-based components may expose interfaces for such cloud-based components to provide processing, storage, software, and/or other resources to other components of the system. In embodiments, the cloud-based component may be implemented by a third-party entity on behalf of another entity to which the component is deployed. However, in other embodiments, the described system may be implemented with a computer system that is fully owned and operated by a single entity.

In an embodiment, an apparatus includes a processor and is configured to perform any of the foregoing methods. In an embodiment, when a non-transitory computer readable storage medium storing software instructions is executed by one or more processors, the instructions cause performance of any one of the methods described above.

6.0 extensions and substitutions

As used herein, the terms "first," "second," "some," and "specific" are used as a general term for naming the queries, plans, representations, steps, objects, devices, or other items from one another so that the items may be referenced after their introduction. Unless otherwise indicated, the use of these terms does not imply a sequence, order, or any other characteristics of the referenced items.

In the accompanying drawings, various components are depicted as being communicatively coupled to various other components via arrows. These arrows illustrate only some examples of information flow between components. Neither the direction of the arrows nor the absence of arrowed lines between certain components should be interpreted as indicating whether or not there is communication between certain components themselves. In practice, each component may have a suitable communication interface by which the component may be communicatively coupled to the other components as necessary to carry out any of the functions described herein.

In the foregoing specification, embodiments of the invention have been described with reference to various specific details that may vary from implementation to implementation. Accordingly, the sole and exclusive indicator of what is the invention, and is intended by the applicants to be the scope of the invention, is the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction. In this regard, although specific claim dependencies are set forth in the claims of the present application, it should be noted that features of the dependent claims of the present application may be combined with features of other dependent claims and independent claims of the present application as appropriate, not merely in accordance with the specific dependencies described in the claims. Moreover, although separate embodiments are discussed herein, any combination of the embodiments and/or portions of the embodiments described herein may be combined to form further embodiments.

The definitions set forth herein for terms contained in such claims shall apply to the meaning of such terms as used in the claims. Thus, any limitation, element, property, feature, advantage or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. Accordingly, the specification and the appended drawings are to be regarded in an illustrative manner; and not as restrictive.

Claims

1. An apparatus, comprising:

a programming unit, comprising:

a security controller that generates a security algorithm in a secure execution environment, the security algorithm being dynamically configured based on a device type of a programmable device;

a programmer configured to execute the security algorithm, the security algorithm programming a security application design interface into the programmable device;

an identification module, the identification module implemented at least in part by hardware, the identification module generating an identification token based on a root-of-trust data cache of a programmable device and a root-of-trust code cache of the programmable device, the identification token having a device identifier, the device identifier being used to authorize access to the programmable device, the root-of-trust data cache being used to store security data, the root-of-trust code cache being used to store code for the security algorithm;

an encryption module, the encryption module implemented at least in part by hardware, the encryption module to generate a key token for authenticating the Trust root data cache and the Trust root code cache, the key token to authenticate the identity token;

an authentication module, implemented at least in part by hardware, that verifies the identification token with the key token, the authentication module verifying the programmable device to authorize access to the programmer; and

a code signing module, the code signing module implemented at least in part by hardware, the code signing module verifying a digital signature of a payload before the programmer programs the payload in the programmable device using the secure application programming interface.

2. The apparatus of claim 1, wherein the root-of-trust code register comprises the security algorithm generated using a programming project at an Original Equipment Manufacturer (OEM) development site, and the security algorithm is stored in the programmable device at a factory site by a programmer.

3. The apparatus of claim 2, further comprising a plant security system implemented at least in part by hardware, the plant security system storing a root of trust (RoT) in the programmable device based on the security algorithm.

4. The apparatus of claim 2, wherein the programmer generates security information for storage in the programmable device based on the security algorithm.

5. The apparatus of claim 2, wherein the programmer stores a key pair in the programmable device based on the security algorithm.

6. The apparatus of claim 2, wherein the programmer generates a credential with a public key and a private key based on the security algorithm.

7. The apparatus of claim 6, wherein the programmer stores the credential in the programmable device based on the security algorithm.

8. A method, comprising the steps of:

generating a security algorithm in a secure execution environment, the security algorithm being dynamically configured based on a device type of a programmable device;

executing the security algorithm on a programmer to program a secure application programming interface into the programmable device;

generating an identification token based on a root-of-trust data cache of the programmable device and a root-of-trust code cache of the programmable device, the identification token having a device identifier, the device identifier being used to authorize access to the programmable device, the root-of-trust data cache being used to store security data, the root-of-trust code cache being used to store code for the security algorithm;

generating a key token for authenticating the Trust root data cache and the Trust root code cache, the key token for authenticating the identity token;

authorizing a trusted hardware platform that verifies the programmable device to access the programmer by verifying the identifying token with the key token; and

verifying the validly-hosted digital signature of the trusted hardware platform before the programmer programs the validly-hosted in the programmable device using the secure application programming interface.

9. The method of claim 8, further comprising the steps of:

generating the security algorithm using a programming project at an Original Equipment Manufacturer (OEM) development site; and

storing, by the programmer at a factory site, the security algorithm in the Trust root code register of the programmable device.

10. The method of claim 9, further comprising the steps of: a root of trust (RoT) is stored in the programmable device based on the security algorithm.

11. The method of claim 9, further comprising the steps of: generating security information for storage in the programmable device based on the security algorithm.

12. The method of claim 9, further comprising the steps of: a key pair is stored in the programmable device based on the security algorithm.

13. The method of claim 9, further comprising the steps of: a credential having a public key and a private key is generated based on the security algorithm.

14. The method of claim 13, further comprising the steps of: storing the credential in the programmable device based on the security algorithm.

15. A non-transitory computer-readable medium storing instructions that, when executed by one or more computing devices, perform the steps of:

executing the security algorithm on a programmer to program a security application programming interface into the programmable device;

generating a key token for authenticating the root of trust data cache and the root of trust code cache, the key token for authenticating the identifier;

verifying a digital signature of a payload of the trusted hardware platform before the programmer programs the payload in the programmable device using the secure application programming interface.

16. The non-transitory computer readable medium of claim 15, further comprising the steps of:

storing, by a programmer at a factory site, the security algorithm in the Trust root code register of the programmable device.

17. The non-transitory computer readable medium of claim 16, further comprising the steps of: a root of trust (RoT) is stored in the programmable device based on the security algorithm.

18. The non-transitory computer readable medium of claim 16, further comprising the steps of: generating security information for storage in the programmable device based on the security algorithm.

19. The non-transitory computer readable medium of claim 16, further comprising the steps of: a key pair is stored in the programmable device based on the security algorithm.

20. The non-transitory computer readable medium of claim 16, further comprising the steps of: a credential having a public key and a private key is generated based on the security algorithm.