Patent Description:
Certain operations of electronic circuit board assembly are performed away from the main production assembly lines. While various feeder machines and robotic handling systems populate electronic circuit boards with integrated circuits, the operations related to processing integrated circuits, such as programming, testing, calibration, and measurement are generally performed in separate areas on separate equipment rather than being integrated into the main production assembly lines.

Customizable integrated circuits or devices, such as Flash memories (Flash), electrically erasable programmable read only memories (EEPROM), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), and microcontrollers incorporating non-volatile memory elements, can be configured with separate programming equipment. Programming equipment is often located in a separate area from the circuit board assembly lines.

<CIT>discloses methods and systems for security in a wireless utility network. The methods and systems use different levels of trust to securely enroll new nodes into a network through other nodes acting as proxies. A node's security state with respect to another node in the network is categorized into one of several trust levels. A node responds to certain requests, actions or messages based on its trust level with the other entity. Initially, a node is not trusted. A first trust level is established based on a digital certificate that is stored in a node when the node is manufactured. A second trust level is established based on a second digital certificate obtained from a certifying authority while a node is in the first trust level. A node with a verified second certificate can be fully enrolled in the network and participate as a network node with minimal or no constraints.

<CIT> discloses systems and methods for secure hardware provisioning.

<CIT>discloses a system where a communication device performs secure communication using a digital certificate to enable a device of a communication party to verify that a self-certificate is generated by a device indicated on the self-certificate.

<CIT> discloses a method for reliably identifying a security profile of a device that generates digital signatures. The method comprises, for each of a plurality of devices manufactured in a secure environment, recording together a public key with a security profile of the manufactured device and generating a digital signature therefor to collectively define a security certificate, the public key and security profile thereby being securely linked together. The method further comprises, before each manufactured device is released from the secure environment, incorporating its respective security certificate into the manufactured device such that the security certificate is sent with a digital signature that is generated by the manufactured device using the private key.

Due account shall be taken of any element which is equivalent to an element specified in the claims.

Embodiments are described herein according to the following outline:.

Approaches, techniques, and mechanisms are disclosed for provisioning programmable devices in a secure manner. A secure programming system may individually encrypt a target payload of data and code and then program information into each individual programmable device. The secure programming system may create a customized payload package that can only be decrypted by a system or a device having correct security keys. Such customization may be needed to meet the demands set by the trends of microcontrollers with the addition of security features.

There has been demand for global manufacturing and programming for devices of increasing densities and speeds. Programming data may be often created on one continent and programmed in another. Original equipment manufacturers (OEMs) may frequently create programming images, but multiple contract manufacturers (CMs) or programming centers may program data into parts or devices using the images. As such, security and traceability of the programming data are very important to OEMs and CMs.

Configurations of the security keys can control the operations of the programmable devices. The security keys can allow the programmable devices to be programmed or accessed only when the programmable devices are identified as valid. Programmable devices may include memory chips, printed circuit boards (PCBs), electronic devices (e.g., smart phones, media players, etc.), microcontrollers, microprocessors, application processors, programmable logic devices, field programmable gate arrays, other consumer and industrial electronic devices, etc..

To enhance the security and traceability of a programmable device, a digital "birth" certificate may be injected into a programmable device during manufacture of the programmable device. The birth certificate can allow the device to have a unique identity so that it may be authorized to be programmed at a CM or OEM facility to have specific computing functionalities. The birth certificate can also allow the device to be eventually used by an authorized user.

The identity that was programmed into the birth certificate during manufacture of the device allows access to or operations of only valid or authorized devices. Without such identity, other approaches are vulnerable to having unauthorized, fake, or clone devices used in a system. The identity may be recognized using a unique identifier that is used to validate whether the device is genuine or not. An example of the unique identifier may be a serial number of the device, a location where the device is manufactured or programmed, a name of a manufacturer who makes the device, a time when the device is manufactured or programmed, etc..

Another example of the unique identifier may be a version of a firmware to be programmed into the device, a type of security key(s) that may be used with cryptography to protect the birth certificate or other information in the device, etc. To make the device even more secure, any combination of the examples given above may be used to make it harder for any illegal attempts to make, use, copy, etc., the device or its contents.

Having the birth certificate embedded in the device at the time the device is manufactured eliminates fake devices. The birth certificate may be securely stored in an area of the device that cannot be tampered with or illegally accessed by unauthorized users. This defeats the cloning or duplication of the device.

In other aspects, the invention encompasses computer apparatuses and computer-readable media configured to carry out the foregoing techniques.

Referring now to <FIG>, therein is shown an illustrative view of various aspects of a secure programming system <NUM> in which the techniques described herein may be practiced, according to an embodiment. The secure programming system <NUM> can individually configure data devices and active, trusted devices with cryptographic information to provide a secure programming and operation environment.

The secure programming system <NUM> comprises at least a programming unit <NUM> having a programmer <NUM>, a security controller <NUM>, security keys <NUM>, adapters for coupling to programmable devices, a first security module <NUM>, a second security module <NUM>, and an nth security module <NUM>. The secure programming system <NUM> can be coupled to a security master system <NUM> having a secure master storage system <NUM>.

The security master system <NUM> and the secure master storage system <NUM> can generate and securely store the security keys <NUM>. For example, the security keys <NUM> can be used for cryptography algorithms, device authentication, code signing, data encryption, data decryption, etc..

For example, the security keys <NUM> used for cryptography algorithms can include a single symmetric key, an asymmetric key pair, etc. Also, for example, the security keys <NUM> used for device authentication or code signing can include an asymmetric public-private key pair, etc. Further, for example, the security keys <NUM> used for data encryption or decryption can include a single symmetric key for symmetric encryption/decryption, an asymmetric key pair with a public key and a private key for asymmetric encryption/decryption, etc..

As an example, single symmetric keys may be used by algorithms for cryptography that use the same cryptographic keys for both encryption of plaintext and decryption of ciphertext. The keys may be identical or there may be a simple transformation to go between the two keys. The keys may represent a shared secret between two or more devices that can be used to maintain a private information link.

As another example, asymmetric key pairs may be used by algorithms for public-key cryptography or asymmetric cryptography. The asymmetric key pairs may be used by any cryptographic system that uses pairs of keys: public keys that may be disseminated widely paired with private keys, which may be known only to the owners of the private keys. For example, the asymmetric key pairs may have at least two functions: using a public key to authenticate that information originated with a holder of the paired private key, or encrypting information with a public key to ensure that only the holder of the paired private key can decrypt it.

For example, in a public-key encryption system, any transmitting device can encrypt information using the public key of the receiving device, but such information can be decrypted only with the receiving device's private key. For this to work, a user may be able to computationally generate a public and private key pair to be used for encryption and decryption. The strength of a public-key cryptography system may rely on the degree of difficulty (e.g., computational impracticality) for a properly generated private key to be determined from its corresponding public key. Security then may depend only on keeping the private key private, and the public key may be published without compromising security.

System <NUM> comprises one or more computing devices. These one or more computing devices comprise any combination of hardware and software configured to implement the various logical components described herein, including components of the programming unit <NUM> having the programmer <NUM>, the security controller <NUM>, the adapters, the first security module <NUM>, the second security module <NUM>, and the nth security module <NUM>. For example, the 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 various data repositories in the one or more memories for storing data structures utilized and manipulated by the various components.

The programming unit <NUM> can be a secure system for programming data, metadata, and code onto the programmable devices <NUM>. The programming unit <NUM> can receive security information from the security master system <NUM>, process the information, and transfer an individually configured version of the security information to the programmable devices <NUM>.

The programming unit <NUM> can include the programmer <NUM>. The programmer <NUM> can be an electromechanical system for physically programming the programmable devices <NUM>. For example, the programmer <NUM> can receive a tray containing the programmable devices <NUM>, electrically couple the programmable devices <NUM> to an adapter unit, and transfer security information into the programmable devices <NUM>. The programming unit <NUM> can receive individualized status information from each of the programmable devices <NUM> and customize the security information transferred to each of the programmable devices <NUM> on an individual device basis. For example, each of the programmable devices <NUM> can receive an individual block of information that is different from the information transferred to others of the programmable devices.

The programmer <NUM> can be coupled to one or more of the adapters that can be used to access the programmable devices <NUM>. The adapters can include a first adapter <NUM>, a second adapter <NUM>, and a nth adapter <NUM>.

In an illustrative example, the first adapter <NUM> can be a hardware device that can be used to electrically connect one or more of the programmable devices to the programmer <NUM>. The programmer <NUM> can then transfer a version of the security information to one of the programmable devices <NUM>. The first adapter <NUM> can include one or more sockets for mounting the programmable devices <NUM>. The first adapter <NUM> can include a socket, a connector, a zero-insertion-force (ZIF) socket, or a similar device to mounting integrated circuits.

Although the adapters are described as electromechanical units for mounting the programmable devices <NUM>, it is understood that the adapters can have other implementations as well. For example, if the programmable devices <NUM> are independent electronic devices, such as a cell phone, a consumer electronic device, a circuit board, or a similar device with active components, then the adapters can include mechanisms to communicate with the programmable devices <NUM>. The adapters can include a cable link, a wireless communication link, an electronic data bus interface, an optical interface, bed-of-nails contacts or fixtures for In-System Programming (ISP), or any other communication mechanism.

ISP, also called In-Circuit Serial Programming (ICSP), may refer to the ability of a chip, such as a programmable logic device, a microcontroller, other embedded devices, etc., to be programmed while installed in a system, rather than having the chip be programmed prior to installing it into the system. ISP may use programming protocols for programming a device, such as Peripheral Interface Controller (PIC) microcontrollers, the Parallax Propeller, etc..

The programmable devices <NUM> are devices that can be provisioned with secure information by the programming unit <NUM>. For example, the programmable devices <NUM> can include data devices such as flash memory units, programmable read only memories, secure data storage devices, or other data storage devices.

Provisioning may include transferring data and/or code information to a device. For example, a flash memory unit can be provisioned by programming it with data.

The programmable devices <NUM> can also include trusted devices <NUM> that include security data and security programming information. For example, the programmable devices <NUM> can include trusted devices <NUM> such as cell phones, hardware security modules, trusted programming modules, circuit board, or similar devices.

The data devices <NUM> can include any number of devices, e.g., a first data device <NUM>, a second data device <NUM>, and a nth data device <NUM>. The trusted devices <NUM> can include any number of trusted devices, e.g., a first trusted device <NUM>, a second trusted device <NUM>, and up to a nth trusted device <NUM>.

The programmable devices <NUM> can each be provisioned with individually customized security information. Thus, each of the programmable devices <NUM> can include a separate set of the security keys <NUM> that can be used to individually encrypt the data stored in programmable devices <NUM>. This provides the ability to encrypt security information <NUM> differently on each of the programmable devices <NUM> to maximize security.

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

In an illustrative example, the secure programming system <NUM> can be used to establish one of the paired devices <NUM> having the first data device <NUM>, such as a system information module (SIM) chip, paired with the first trusted device <NUM>, such as a smart phone. In this configuration, the first data device <NUM> and the first trusted device <NUM> can both be programmed with the security keys <NUM> for the paired devices <NUM>. Thus the first trusted device <NUM> can validate the security information <NUM>, such as a serial number, of the first data device <NUM> to authenticate that the first trusted device <NUM> is allowed to use the other information on the first data device <NUM>.

The programming unit <NUM> can include a security controller <NUM> coupled to the programmer <NUM>. The security controller <NUM> are computing devices for processing security information. The security controller <NUM> can include specific cryptographic and computational hardware to facility the processing of the cryptographic information. For example, the security controller <NUM> can include a quantum computer, parallel computing circuitry, field programmable gate arrays configured to process security information, a co-processor, an array logic unit, a microprocessor, or a combination thereof.

For illustrative purposes, the security controller <NUM> is shown as a separate unit from the programmer <NUM>, although it is understood that the security controller <NUM> may be implemented in a different manner. For example, the security controller <NUM> and the programmer <NUM> may be implemented in the same physical hardware unit, device, system, etc..

The security controller <NUM> can be a secure device specially configured to prevent unauthorized access to security information at the input, intermediate, or final stages of processing the security information. The security controller <NUM> can provide a secure execution environment for secure code elements to execute in. For example, the security controller <NUM> can be a hardware security module (HSM), a microprocessor, a trusted security module (TPM), a dedicated security unit, or a combination thereof.

The security controller <NUM> can be coupled to security modules to provide specific security functionality. The security modules can include a first security module <NUM>, a second security module <NUM>, and a nth security module <NUM>. Each of the security modules can provide a specific security functionality such as identification, authentication, encryption, decryption, validation, code signing, data extraction, or a combination thereof.

For example, the first security module <NUM> can be configured to provide an application programming interface (API) to a standardized set of commonly used security functions. In another example, the second security module <NUM> can be a combination of dedicated hardware and software to provide faster encryption and decryption of data.

The programming unit <NUM> can include the secure storage of one or more of the security keys <NUM>. The security keys <NUM> can be calculated internal to the secure programming system <NUM>, can be calculated externally and received by the secure programming system <NUM>, or a combination thereof.

The security keys <NUM> can be used to encrypt and decrypt the security information. The security keys <NUM> can be used to implement different security methodologies and protocols. For example, the security keys <NUM> implement a public key encryption system. In another example, the security keys <NUM> can be used to implement a different security protocol or methodology. Although the security keys <NUM> can be described as a public key encryption system, it is understood that the security keys <NUM> can be used to implement different security paradigms.

One of the advantages of the secure programming system <NUM> includes the ability to provision each of the programmable devices <NUM> with a different set of the security keys <NUM> and a different version of the security information <NUM> encrypted by the individual security keys <NUM>. This can ensure that the security keys <NUM> used to decrypt the security information <NUM> on one of the programmable devices <NUM> cannot be used to decrypt the security information on another one of the programmable devices <NUM>. Each of the programmable devices <NUM> can have a separate one of the security keys <NUM> to provide maximum protection.

Referring now to <FIG>, therein is shown an example block diagram of the secure programming system <NUM>. The secure programming system <NUM> may include a system topology that includes the security controller <NUM> connected to the programmer <NUM> that interfaces with a host computer <NUM> and a number of adapters (e.g., <NUM>, <NUM>, <NUM>, etc.). Each of the adapters may interface with a number of the programmable devices <NUM>.

The host computer <NUM> may include a system that interfaces with the programmer <NUM> to exchange commands and data to securely configure, program, verify, analyze, etc., the programmable devices <NUM>. For example, the host computer <NUM> may be the security master system <NUM>, the secure master storage system <NUM>, a server, a workstation, etc..

For illustrative purposes, each adapter shown is connected to eight programmable devices <NUM>, although it is understood that each adapter may be connected to any number of programmable devices <NUM>. For example, the programmable devices <NUM> may represent, but are not limited to, any of: devices under test (DUT), integrated circuits, media, etc..

Also, for example, each adapter may be connected to any types or any combination of programmable devices <NUM>, including, but are not limited to, any of: integrated circuits, media, electronics devices, microcontrollers, microprocessors, application processors, programmable logic devices, FPGAs, smartphones, tablets, laptops, computers, set top boxes, mobile devices, game consoles, display devices, PCBs, media players, mobile phones, smartphones, Internet of Things (IoT) devices, consumer or industrial electronic devices, any other electronic devices, etc. Further, for example, media may include, but are not limited to, any of: volatile memories, non-volatile memories, hard drives, solid state drives (SSDs) removable drives, Compact Disc Read-Only Memory (CD-ROM) or CD-R discs, digital versatile discs (DVD), flash memories, Universal Serial Bus (USB) drives, etc..

The secure programming system <NUM> may be used by, for example, flash vendors, electronic device manufacturers, programming centers, contract manufacturers (CM), etc., to program the programmable devices <NUM>. The secure programming system <NUM> may be used to program the programmable devices <NUM> for on-line or off-line programming.

For example, an on-line programming of the programmable devices <NUM> by the programmer <NUM> may be controlled by or connected to any combination of the host computer <NUM>, the security controller <NUM>, a network, etc. Also, for example, an off-line programming of the programmable devices <NUM> may include a process of setting up the programmer <NUM> by any combination of the host computer <NUM>, the security controller <NUM>, a network, etc., and the programmer <NUM> may subsequently program the programmable devices <NUM> without further intervention by the host computer <NUM>, the security controller <NUM>, the network, etc..

The programmable devices <NUM> may include, but are not limited to, any of: memory chips, circuit boards, electronic devices (e.g., smart phones, media players, other consumer and industrial electronic devices, etc.), etc. For example, the programmable devices <NUM> may be programmed by the programmer <NUM>, which may be optimized or configured for programming high-density eMMC devices with memory densities of at least <NUM> GB.

Referring now to <FIG>, therein is shown a second example block diagram of the secure programming system <NUM>. The secure programming system <NUM> may include a number of programming units <NUM>. Each programming unit <NUM> may include a main board <NUM> that interfaces with a cache module <NUM> and an interposer <NUM>.

The main board <NUM> may include a number of printed circuit boards that manage programming operations of a programming unit <NUM>. The main board <NUM> may exchange control information or payload information with the host computer <NUM> or the programmable devices <NUM>. The main board <NUM> may include a network interface <NUM> for the main board <NUM> to communicate with the security controller <NUM>, the host computer <NUM>, etc..

The network interface <NUM> may include wireless networks or wire networks. For example, wireless networks may include, but are not limited to, any of: <NUM>, Bluetooth, other types of wireless interfaces, etc. Also for example, wire networks may include, but are not limited to, any of: Gigabit Ethernet (GigE), other networking technologies used in local area networks (LANs) or metropolitan area networks (MANs), etc. The main board <NUM> may operate using an operating system (OS) including, but is not limited to, any of: Linux, Windows, Macintosh, Android, etc..

The cache module <NUM> may include storage capacity for storing or retrieving secure information or information that may be used to program the programmable devices <NUM>. The cache module <NUM> may include any storage capacity for storing program image information. For example, the cache module <NUM> may include at least <NUM> GB of storage capacity for storing program image.

The interposer <NUM> (e.g., a PCB, a substrate, etc.) may include a number of passive or active components <NUM>. The interposer <NUM> may include a number of adapter connectors <NUM> assembled on the interposer <NUM> to provide an interface for the main board <NUM> to send programming information to the programmable devices <NUM> or receive programming status or statistics from the programmable devices <NUM>.

The adapter connectors <NUM> may be physically connected to socket adapters <NUM>, in which the programmable devices <NUM> may be mounted before the programmable devices <NUM> are configured, identified, authenticated, or programmed by the security controller <NUM>, the programming units <NUM>, etc. The socket adapters <NUM> may include individually replaceable sockets. The socket adapters <NUM> may represent the adapters (e.g., <NUM>, <NUM>, <NUM>, etc.) shown in <FIG>.

In one or more embodiments, the secure programming system <NUM> may include any number of functionalities and performance metrics. For example, the programming units <NUM> may have a data download performance of, but is not limited to, <NUM> megabytes per second (MB/s) using GigE data download from the host computer <NUM> to the programmer <NUM>, which may be at least <NUM> times of a download speed of the current technology. Also, for example, for data programming performance, the programming units <NUM> may have a speed of, but is not limited to, a <NUM>-MHz double-data-rate (DDR) interface, which is at least 4X a speed of the current technology.

In one or more embodiments, the secure programming system <NUM> may include any programmer capacities and scalability. For example, the programming units <NUM> may have a capacity of, but is not limited to, at least <NUM> GB of local cache in the cache module <NUM>, which may be field upgradeable to, but is not limited to, <NUM> GB.

In one or more embodiments, the secure programming system <NUM> may include any number of programming sites, such as the socket adapters <NUM>, per programming unit <NUM> with one socket per adapter. For example, the secure programming system <NUM> may be provisioned to support, but is not limited to, eight programming sites per programming unit <NUM>, which is at least two times of a number of programming sites per programmer of the current technology.

In one or more embodiments, the secure programming system <NUM> may include any number of the programming units <NUM>. For example, the secure programming system <NUM> may include, but is not limited to, <NUM> programming units <NUM>.

In one or more embodiments, increased download speeds are greatly simplified using the secure programming system <NUM>. For example, the programming units <NUM> may increase download speeds by minimizing setup times for large files (e.g., including, but are not limited to, at least <NUM> GB, etc.) for improved productivity. For large file downloads, the programming units <NUM> may provide a reduced setup time for configuring the programmable devices <NUM>, transferring and storing programming images, etc., to optimize a machine utilization and a data input/output (I/O) total cost of programming (TCOP).

In one or more embodiments, improved programming or verification speeds may greatly be simplified using the secure programming system <NUM>. The programming units <NUM> may deliver data to the programmable devices <NUM> at a speed of, but is not limited to, an interface between the programming units <NUM> and the programmable devices <NUM>. It is understood that the programming or verification speed of the current technology has not been able to keep up with the speed of the interface between the programmer and the devices.

A maximum program/verify speed of a programming unit <NUM> may be gated or dependent on sequential read/write speeds of the programmable devices <NUM>. As device speeds increase, the programming unit <NUM> may program or verify the programmable devices <NUM> at the device speeds, while speeds of other programmers using the current technology are limited and thus cannot keep up with the device speeds.

For example, the programming units <NUM> may program or verify the programmable devices <NUM> at speeds of, but are not limited to, any of: fastest eMMC devices, secure devices (SD), etc., that are available at the time of programming of the devices. Also, for example, for the fastest eMMC devices that are currently available, the programming units <NUM> may program or verify the programmable devices <NUM> at a speed of, but is not limited to, <NUM> MB/s.

For example, the programming units <NUM> may be operated at a clock speed of, but is not limited to, <NUM> using double data rate (DDR) clocks. Also, for example, for a <NUM>-GB image, the programming units <NUM> may program <NUM> programmable devices <NUM> in at most <NUM> minutes, whereas other programmers using the current technology may program only <NUM> programmable devices <NUM> in at least <NUM>-<NUM> minutes or <NUM> programmable devices <NUM> in at least <NUM>-<NUM> minutes.

The secure programming system <NUM> may include an increased socket capacity. For example, the programming units <NUM> in the secure programming system <NUM> may altogether support, but are not limited to, <NUM> socket adapters <NUM> in the secure programming system <NUM>. Also, for example, the secure programming system <NUM> may have at least <NUM> times of a socket capacity of the current technology. Further, for example, the secure programming system <NUM> may have a total cost advantage of <NUM> programming handler instead of <NUM> programming handlers of the current technology. A programming handler is a unit that is predefined or pre-configured for the programming units <NUM> to interface with specific types of the programmable devices <NUM>.

Referring now to <FIG>, therein is shown an example application of the secure programming system <NUM>. The example application may be utilized by an original equipment manufacturer (OEM) <NUM> to use a secure data management (SDM) architecture of the secure programming system <NUM> to communicate with an electronics manufacturing service (EMS) provider <NUM> to program the programmable devices <NUM>.

For illustrative purposes, although the EMS provider <NUM> is shown as an example of a facility that can program the programmable devices <NUM>, it is understood that any facility may program the programmable devices <NUM>. For example, a programming center or any other facilities may program the programmable devices <NUM>.

In one or more embodiments, the SDM architecture may include processes for a job creation, a job execution, a device identification, a device authentication, a device cryptography, etc., to securely and reliably program the programmable devices <NUM>. The SDM architecture may include processes of programming unique secure information into the programmable devices <NUM> during manufacture of the programmable devices <NUM> for traceability and data breach prevention. For example, the programmable devices <NUM> may include, but are not limited to, any of: Internet of Things (IoT) devices, any other electronics devices, etc..

The SDM architecture may include a connected programming strategy, for multinational corporations (MNC) that have a global network of a variety of interconnected devices including, but are not limited to, any of: mobile phones, automotive electronics, computers, etc. The SDM architecture may enable an offshore manufacturing strategy and a just-in-time (JIT) programming method that eliminates inventory security risks.

The secure programming system <NUM> may support global manufacturing. The secure programming system <NUM> may provide a SDM environment with a fully connected infrastructure from headquarters to manufacturing sites.

The secure programming system <NUM> may secure programming job files from creation in engineering departments to factory floors, whether in-house at an OEM facility or remotely at an electronic manufacturing supplier (EMS) site. For example, an EMS may represent a contract manufacturer (CM), etc. The secure programming system <NUM> may restrict access to the programming job files to only the programmer <NUM> with an option for JIT or offline automated programming.

For example, the programming job files may be created by the OEM workstation <NUM>. The job files may then be sent to the OEM local server <NUM> to schedule jobs to be tested at the OEM <NUM>. The job files may be pushed or sent to the EMS local server <NUM>. The EMS workstation <NUM> may select which jobs to download and run on the programming unit <NUM> at the EMS site.

The secure programming system <NUM> may provide serialization of each programmable device <NUM> with a unique identification (ID). The unique identification may be generated using serialization, which may include a process of sequentially generate serial numbers and assigning the serial numbers to devices as the devices are programmed. A serial number may uniquely identify each device. For example, the serialization may be applied to or used by any of: integrated circuits, media, electronics devices, microcontrollers, microprocessors, application processors, programmable logic devices, FPGAs, smartphones, tablets, laptops, computers, set top boxes, mobile devices, game consoles, display devices, PCBs, media players, mobile phones, smartphones, IoT devices, consumer or industrial electronic devices, any other electronic devices, etc..

The secure programming system <NUM> may link job files to a programming algorithm. The secure programming system <NUM> may provide programming statistics that serve as unique IDs. The secure programming system <NUM> may combine job files, serial numbers, security keys, programming data statistics, etc., for the programmer <NUM> to create a device birth certificate <NUM>. As such, the device birth certificate <NUM> may establish a Root of Trust (RoT), which may be combined with other security features (e.g., identification, authentication, cryptography, etc.) to provide additional levels of security.

Referring now to <FIG>, therein is shown a second example application of the secure programming system <NUM>. The second example application depicts a SDM environment that may be used by the EMS provider <NUM> for monitoring of and collecting statistics from programming the programmable devices <NUM>. During production of the programmable devices <NUM>, programming statistics data may be continuously collected by the programming unit <NUM> and reported to the EMS local server <NUM>. The statistics data may then be sent to the OEM <NUM>.

The statistics may be sent to an OEM cloud <NUM>, which may provide shared processing resources and data to computers and other devices on demand. The OEM cloud <NUM> may include Internet-based storage and computing resources (e.g., networks, servers, storage, applications, services, etc.). The OEM cloud <NUM> may provide users and enterprises with various capabilities to store and process data in data centers. For example, the OEM cloud <NUM> may include the OEM local server <NUM>, the OEM workstation <NUM>, etc..

The statistics data may be collected over any timeframe (e.g., real-time, predefined durations, etc.). The statistics data may be queried at an OEM location by the OEM workstation <NUM>, the OEM local server <NUM>, etc. The statistics data may include programming information, serial numbers, other unique information, etc., that establish unique information for a device birth certificate <NUM> for each programmable device <NUM>.

In one or more embodiments, a job creation process may be implemented in software (SW). The job creation process may be distinct from a job running SW to eliminate operator errors.

The statistics data may include programming metrics reports, such as a number of devices consumed, programmed, pass, fail, etc. Programming metrics reports may be used to improve reliability and security. The reliability may increase programming yields to greater than <NUM>%. The metrics reports may provide faster device support and a TCOP cut by <NUM>/<NUM>. The SDM environment may include a remote monitoring application program interface (API) to collect and report the statistics data.

Referring now to <FIG>, therein is shown a third example block diagram of the secure programming system <NUM>. The third example block diagram depicts serialization of the secure programming system <NUM>.

The secure programming system <NUM> may include a serial number server <NUM> to use serialization to create or generate serial numbers as unique signatures or identifier for a device birth certificate <NUM> of a programmable device <NUM>. The secure programming system <NUM> may include a device identification <NUM>, which may include a serial number, that may be used to generate the device birth certificate <NUM>. The device birth certificate <NUM> may then be stored into the programmable devices <NUM>.

In an embodiment, the serial number server <NUM>, the security controller <NUM>, or the authentication unit <NUM> may be units or components that are separate or outside of the programmer <NUM>. In another embodiment, any combination of the serial number server <NUM>, the security controller <NUM>, the authentication unit <NUM>, etc. may be integrated into the programmer <NUM>.

The device identification <NUM> may be a computing device for processing security information. In an embodiment, the device identification <NUM> may include specific cryptographic and computational hardware to facility the processing of the serial numbers to generate unique identifiers to be used for the device birth certificate <NUM>. In another embodiment, serial numbers may be used directly as unique identifiers, which may not be encrypted.

The device identification <NUM> may include a cryptography mechanism using the security keys <NUM>. As an example, the cryptographic mechanism may include, but is not limited to, a public-key or an asymmetric key cryptography in which a pair of two different but mathematically related keys may be used -- a public key and a private key. As another example, a public key system may be constructed so that calculation of one key (e.g., a private key) may be computationally infeasible from the other key (e.g., a public key), even though they are related. Both public and private keys may be generated secretly as an interrelated pair.

For example, the device identification <NUM> may be implemented in the programmer <NUM> to encrypt a unique identifier using a private key of the programmer <NUM> before the unique identifier is used to generate the device birth certificate <NUM> and the device birth certificate <NUM> is programmed into the programmable devices <NUM>. When the device birth certificate <NUM> is retrieved after a programmable device <NUM> is programmed, the encrypted unique identifier may be decrypted using a public key of a key pair.

The secure programming system <NUM> may include an authentication unit <NUM> that saves the serial numbers for subsequent processing. For example, after the programmable devices <NUM> are programmed, the saved serial numbers may be used by the authentication unit <NUM> to verify if a serial number sent from the host computer <NUM> of <FIG> matches one of the saved serial numbers. If a match occurs, the authentication unit <NUM> may grant the host computer <NUM> access to the programmable device <NUM> that has been identified by the serial number.

The secure programming system <NUM> may include the security controller <NUM> to provide an additional level of protection. The security controller <NUM> may provide a security key, which may be saved in the device birth certificate <NUM>. The security key may be used for cryptography to encrypt or decrypt contents of the device birth certificate <NUM>.

Referring now to <FIG>, therein is shown an example block diagram depicting an on-the-fly update solution of the secure programming system <NUM>. Combined with secure over-the-air updates <NUM> and data exchange services provided by a secure cloud <NUM>, a total security solution for IoT devices may be possible using the secure programming system <NUM>. The security solution may be provided with or without proprietary silicon chips having security functionalities.

The secure over-the-air (OTA) updates <NUM> may include various methods of distributing new software, configuration settings, etc., or updating encryption keys to devices, such as cellphones, set-top boxes, secure voice communication equipment, encrypted <NUM>-way radios, etc. The secure over-the-air (OTA) updates <NUM> may be provided by the secure cloud <NUM> to send firmware updates to the programming unit <NUM>. The secure cloud <NUM> may receive the updates from a server <NUM>. For example, the server <NUM> may include the secure master storage system <NUM>, the security master system <NUM>, the security keys <NUM>, etc..

In an embodiment, the server <NUM> may send secure information to the programming unit <NUM> to create the device birth certificate <NUM>, which may be subsequently programmed into the programmable devices <NUM>. In another embodiment, the server <NUM> may create the device birth certificate <NUM> and send the device birth certificate <NUM> to the programming unit <NUM> to program or store the device birth certificate <NUM> in the programmable devices <NUM>. As an example, the device birth certificate <NUM> may be used for downstream cloud-based updates and data analysis services to securely update firmware (FW) for the programmable devices <NUM>, including IoT clients, etc., and retrieve data from known trusted end-points.

The secure programming system <NUM> may provide an optimal option for programming the programmable devices <NUM>. The secure programming system <NUM> may include a managed and secure programming (MSP) mechanism for baseline programming. The secure programming system <NUM> may add the serialization as an integrated serialization at time of programming the programmable devices <NUM>. The secure programming system <NUM> may include a unique algorithm to address private one-time programmable (OTP) memory regions of microcontrollers, flash memories, other non-volatile memories, etc..

Referring now to <FIG>, therein is shown an example block diagram depicting an end-to-end (E2E) solution beyond manufacturing of the secure programming system <NUM>. The secure programming system <NUM> may provide the end-to-end solution without a custom or proprietary security chip, which is an added cost.

Existing methods provide approaches for over over-the-air updates and authentication, but these approaches ignore the FW/SW and manufacturing 'Root of Trust' issues. The existing methods may provide device security that requires extra chips, which impose extra bill of material (BOM), power, and silicon or board real estate costs.

However, the secure programming system <NUM> provides a different approach with additional benefits. The secure programming system <NUM> may not require the added real estate, power, or bill of materials costs. The secure programming system <NUM> may be platform and ecosystem independent since existing or additional security chips are not required in the secure programming system <NUM>. The secure programming system <NUM> may provide a foundational architecture on which other approaches may reside or use. The secure programming system <NUM> may be available to silicon suppliers that program the programmable devices <NUM> when the programmable devices <NUM> are manufactured at a silicon level or a system level prior to programming the programmable devices <NUM>.

The secure programming system <NUM> may include a secure data management (SDM) <NUM>, which may include a protection hardware solution mechanism with manufacturing monitoring processes. The protection hardware solution mechanism may provide programming jobs with product firmware and semiconductor device programming algorithms that may be created at an OEM facility. The SDM <NUM> may be used for data sharing quality of service (QoS), distributed analytics, etc..

The secure programming system <NUM> may include an edge management <NUM>, which may be used for device authentication, device management, application updates, etc., for the programmable devices <NUM>. The secure programming system <NUM> may include a secure firmware management <NUM>, which may be used for firmware and security certificates, audit trails on core device changes, statistics collection, etc. The secure firmware management <NUM> may be involved with updating the firmware in the programmable devices after receiving update information from the secure cloud <NUM> using the secure over-the-air updates <NUM>.

The programming jobs may be encrypted and assigned to a specific programmer <NUM> anywhere around the world. If a programming job arrives at a programmer <NUM> with an assigned programmer serial number, the job file may get decrypted and a programming process may begin. The programming job may also include local serialization within an OEM facility. The SDM <NUM> may use local servers at each location (e.g., OEM, EMS, etc.) to facilitate network key exchanges, job encryptions, job transfers to manufacturing facilities, statistics collections, etc..

When a programmable device <NUM> is programmed, the device birth certificate <NUM> may be used. For example, the device birth certificate <NUM> may include a program device ID, birth certificate parameters, a serial number of the programmer or programmer ID, a job package number, a manufacturer ID, etc. The device birth certificate <NUM> may be linked to or associated with a job package that is actually programmed into a programmable device <NUM>.

The device birth certificate <NUM> or components of the device birth certificate <NUM> may be stored in secure non-volatile memory areas of the programmable devices <NUM> with a variety of features. Each of the secure non-volatile memory areas may provide varying degrees of security. For example, the features may include OTP areas, device private OTP areas, hardware fuses, Read-Only Memory (ROM), write protected memory, cryptographically controlled memory access areas (e.g., Replay Protected Memory Block (RPMB), etc.), etc. Also, for example, these features may apply to the programmable devices <NUM>.

The device private OTP areas may have different properties than those of the OTP areas. As an example, a device private OTP area of a programmable device <NUM> may be internally accessed or programmed only by the programmable device <NUM>. As another example, an OTP area of a programmable device <NUM> may be externally accessed or programmed by the programmer <NUM> or internally accessed or programmed by the programmable device <NUM>.

For example, the device birth certificate <NUM> may reside or stored in the OTP memory, which may be tamper resistant. The OTP memory may include a programmable memory, which may not be overwritten after the memory is programmed. Also, for example, the device birth certificate <NUM> may be stored in an OTP region of a read-only memory (ROM) on the programmable device <NUM>. Encryption may be used to prevent unauthorized readings of the OTP region.

The secure programming system <NUM> may impregnate the programmable devices <NUM> with the device birth certificate <NUM>. The device birth certificate <NUM> may be employed for a device, a board, a system, etc..

The serialization may be used for service and traceability. The traceability may be used to determine a device history, a location of where the device was manufactured, a location of the programmer that programmed the device, the image that was used to program the device, etc..

The secure programming system <NUM> may include the edge management <NUM> for authentication and verification using a device ID for identification. The secure programming system <NUM> may use the authentication to prevent reverse engineering of the programmable devices <NUM>. The secure programming system <NUM> may use the identification to identify the programmable devices <NUM>. Both the authentication and the verification/identification may be built on top of the device birth certificate <NUM>.

The device birth certificate <NUM> may provide the Root of Trust or the basis for the trust. The device birth certificate <NUM> may provide security for on-the-fly updates. The device birth certificate <NUM> may provide security for a first time boot process to be sure that programming occurs on a known device.

In an embodiment, security is greatly simplified using the device birth certificate <NUM>. The security is improved because the device birth certificate <NUM> provides an additional level of protection using the authentication and the verification of the programmable devices <NUM>.

The secure programming system <NUM> may include another Root of Trust on top of the Root of Trust. For example, the secure programming system <NUM> may be configured to have a license key upon boot up of the secure master storage system <NUM>, the security master system <NUM>, the secure programming system <NUM>, the programmer <NUM>, the programmable devices <NUM>, etc. The secure programming system <NUM> may provide an application in the programming unit <NUM> that secures content or information to be sent to and utilized by the programmable devices <NUM>.

In an embodiment, the secure programming system <NUM> may provide a software solution without additional hardware or security chips/devices. For example, the secure programming system <NUM> may use software in the programmer <NUM> to program the device birth certificate <NUM> into the programmable devices <NUM>. The software may include functionalities to identify or authenticate the programmable devices <NUM> using cryptography.

The device birth certificate <NUM> may be stored in an OTP memory having any sizes. For example, the OTP memory may have less than <NUM> kilobyte (KB). Also, for example, the OTP memory may be a separate partition in a flash memory. Further, for example, the OTP memory may be in a Replay Protected Memory Block.

For example, the OTP memory may include a memory region of any sizes (e.g., <NUM> KB, <NUM> KB, <NUM> KB, etc.). Also, for example, the secure programming system <NUM> may use an existing region or a user data region in a memory device and then may convert or configure the region into an OTP region.

For example, the device birth certificate <NUM> may be read protected or encrypted so that the device birth certificate <NUM> cannot be hacked to prevent the device birth certificate <NUM> from being copied or altered.

The serialization may be used to generate the serial number, which is a unique number for each device or customer who is using a manufacturing service to program a device. A serial number may include unique information or stamp on the device. For example, the serial number may include a numerical value indicating a position of a device on the programmer <NUM>. Also, for example, the serial number may be identified using non-electronic methods including, but are not limited to, any of: a radio frequency identification (RFID) tag, a sticker, a label, an identifier that would need optical methods to recognize the identification of the device, etc..

In an embodiment, reliability is greatly simplified using the device birth certificate <NUM>. The device birth certificate <NUM> may include security features or programming parameters that improve programming data security and traceability. The programming parameters may maintain reliability with greater than <NUM>% programming yields of the programmable devices <NUM>. Furthermore, the secure programming system <NUM> may provide faster custom device support and leverage automation, thereby reducing the total cost of programming (TCOP) of each device.

System <NUM> 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 work between the components may vary depending on the arrangement. For example, in some embodiments, some of the security modules may be omitted, along with any other components relied upon exclusively by the omitted component(s). As another example, in an embodiment, system <NUM> may further include multiple serial numbers or other system identifiers.

Referring now to <FIG>, therein is shown an example of the device birth certificate <NUM> according to an embodiment. The security information <NUM> may include, but is not limited to, the device birth certificate <NUM> programmed to the programmable devices <NUM> at time of manufacture of the programmable devices <NUM>. For example, the device birth certificate <NUM> may be implemented in systems for media related services (e.g., digital rights management (DRM), etc.), financial services (e.g., e-payments, etc.), personal identification, etc..

In one or more embodiments, a programming unit <NUM> may create a device birth certificate <NUM> for each programmable device <NUM>. The device birth certificate <NUM> may enable identification or authentication of a programmable device <NUM>. An unauthorized, fake, or clone device may be rejected or disabled by a programming unit <NUM> when the device birth certificate <NUM> is invalidated by the programming unit <NUM>.

The secure programming system <NUM> may provide a unique SDM technology having an improved programming quality and security at the time of manufacture. The secure programming system <NUM> may generate a device birth certificate <NUM> for a programmable device <NUM> to establish a Root of Trust. The device birth certificate <NUM> may be stored on the devices or the media.

The term Root of Trust referred to herein may refer to a set of functions in a trusted or secured computing module that includes hardware components, software components, or a combination of hardware and software components. For example, these functions may be implemented in, but are not limited to, a boot firmware, a hardware initialization unit, a cross-checking component/chip, etc. Also, for example, the functions may be implemented using, but is not limited to, a separate compute engine that controls operations of a cryptographic processor.

The secure programming system <NUM> may provide a mechanism having a unique role to play in a womb-to-tomb security for devices and data of the devices. In security, the number-one challenge for growth and market acceptance creates barriers for companies to investing in IoT. The challenge relates to concerns about the privacy and security aspects of the loT. Security starts with firmware (FW), for example, in security flaws of the IoT devices including insecure software/firmware and insufficient authentication.

In one or more embodiments, the secure programming system <NUM> may provide improved security for IoT devices. The secure programming system <NUM> provides a womb-to-tomb security for the loT devices and secures manufacturing at any locations for all systems using a Root of Trust established in manufacturing. The secure programming system <NUM> may provide secured updates, a data analysis, or possibly an end-to-end service for the lifetime of the devices.

The secure programming system <NUM> may provide security that starts with programming and manufacturing. The secure programming system <NUM> provides security that starts at the time of manufacture. The security may be provided by controlled FW code, proven untampered programming, and the device birth certificate <NUM> that establishes the Root of Trust for subsequent updates and data analysis.

The programming unit <NUM> may inject or program the device birth certificate <NUM> into each programmable device <NUM> at a time of manufacturing the programmable device <NUM>. The device birth certificate <NUM> may include device specific information or unique DNA. This process may establish a unique Root of Trust for each device at a time of manufacturing the device.

An RoT may be stored in a secure storage, including, but is not limited to, a tamper resistant Non-Volatile Memory (NVM) region on the device. The secure storage may be available for the active lifetime of the device. A Root of Trust may be used to deliver device related services. For example, the device related services may include, but are not limited to, a device identification, a device authentication, a secure device provisioning, a secure update service, media related services (e.g., DRM, etc.), financial services (e.g., e-payments, etc.), etc..

The device birth certificate <NUM> may be used to uniquely identify any combination of the programmable devices <NUM>, the secure programming system <NUM>, the programmer <NUM>, etc. The device birth certificate <NUM> may have a variety of configurations. In one or more embodiments, the device birth certificate <NUM> may include any combination of manufacturer markers <NUM>, incoming Root of Trust (In_RoT) markers <NUM>, serial number markers <NUM>, software markers <NUM>, manufacturing markers <NUM>, system test markers <NUM>, operating markers <NUM>, Physically Uncloneable Function (PUF) markers <NUM>, the security keys <NUM>, product markers <NUM>, etc..

The manufacturer markers <NUM> are security elements that can describe or identify the manufacturer that may make or use the programmable devices <NUM>. For example, the manufacturer markers <NUM> may be used to identify original equipment manufacturers (OEM), electronics manufacturing service (EMS) providers, programming centers, contract manufacturers (CM), etc. The manufacturer markers <NUM> may include manufacturer IDs, programming company IDs, programmer IDs, license information, time windows, authorized locations (e.g., postal addresses, geographical coordinates, etc.) of manufacturers, authorized factories, product lot sizes, serial number ranges of the programmable devices <NUM>, other OEM related parameters, etc..

The In_RoT markers <NUM> are security elements that can describe information that have been previously programmed or configured in a programmable device <NUM> prior to programming the programmable device <NUM>. The In_RoT markers <NUM> may be retrieved from a device birth certificate <NUM> of a programmable device <NUM> that was previously programmed.

In an embodiment, In_RoT markers <NUM> in a device birth certificate <NUM> of a programmable device <NUM> that was previously programmed may be used to generate a device birth certificate <NUM> for another programmable device <NUM>, which may include, but is not limited to, any of: a printed circuit board, an electronics or computing system, etc. In another embodiment, a device birth certificate <NUM> of a programmable device <NUM> that was previously programmed may be re-programmed with additional security elements, markers, RoTs, etc..

In one or more embodiments, the previously programmed information may have been programmed into any combination of: adapters (e.g., <NUM>, <NUM>, <NUM>, etc.) that used for programming the programmable devices <NUM>, the programmer <NUM>, the security controller <NUM>, the security master system <NUM>, the programmable devices <NUM>, the secure master storage system <NUM>, security modules (e.g., <NUM>, <NUM>, <NUM>, etc.), etc..

For example, the In_RoT markers <NUM> of a programmed device <NUM> that has already been programmed may include a programmer identification (ID) that was used to program the programmed device <NUM>. The programmer ID may identify the programmer <NUM>, the programming unit <NUM>, etc..

A serial number marker <NUM> is unique information assigned to each programmable device <NUM>. A serial number marker <NUM> of a programmable device <NUM> may be different from another serial number marker <NUM> of another programmable device <NUM> such that there may not be two programmable devices <NUM> that share the same serial number marker. The serial number markers <NUM> may be generated by the programmer <NUM>. Each serial number marker <NUM> may be assigned to each programmable device <NUM> by the programmer <NUM>. For example, a serial number marker <NUM> may represent an ID of a programmable device <NUM>.

The software markers <NUM> are security elements that can describe or identify the software used in the programmable devices <NUM>. For example, the software markers <NUM> may identify boot loaders, OS, firmware, applications, etc..

For example, the software markers <NUM> may identify the versions of the firmware used in the programmable devices <NUM>. Also, for example, a programmable device <NUM> may be a printed circuit board having firmware installed on the board. A firmware marker <NUM> may identify the version number for each separate firmware element. The firmware version information could be used to coordinate interoperability between code elements in the programmable devices <NUM>.

For example, the software markers <NUM> may include information about how the firmware used in the programmable devices <NUM> may be verified. The firmware used in the programmable devices <NUM> may be verified using a verification method that may detect if the firmware code has been altered, corrupted, or compromised. As an example, a verification method may include, but is not limited to, any of: hash functions, checksums, Data Encryption Standard (DES) algorithms, Advanced Encryption Standard (AES) algorithms, triple-DES algorithms, MD4 message-digest algorithms, MD5 algorithms, Secure Hash Algorithms <NUM> and <NUM>, any other algorithms, etc..

The manufacturing markers <NUM> are security elements that can describe one or more manufacturing properties. The manufacturing markers <NUM> may include information associated with components when the components are manufactured. For example, the manufacturing markers <NUM> may include, but are not limited to, any of: a programmer ID of the programmer <NUM>, a customer ID, a location (e.g., geographical coordinates, etc.) of manufacture or programming of a component, a date or a time of manufacture or programming of a component, a time window, a factory or manufacturer ID, a vendor ID, a customer ID, OEM identification information, MES identification information, manufacturing equipment information, manufacturing related parameters, etc..

Also, for example, a manufacturing marker <NUM> may include a customer ID of a company or an OEM that contracts an EMS provider to build, assemble, program, test, etc., the programmable devices <NUM>. Further, for example, a manufacturing marker <NUM> may include a uniform resource locator (URL) identifier pointing to where a job package is stored in the cloud, a revision control ID or information that may be used to determine what is on the device compared to the state of the device when it is an un-programmed device, etc..

The system test markers <NUM> are security elements that can describe test environments. For example, the system test markers <NUM> may include information that conveys test parameters that are used to configure the programmer <NUM>. Also, for example, the system test markers <NUM> may include results of tests performed to verify the programmable devices <NUM>. In this example, the system test markers <NUM> may include information that indicate whether each programmable device <NUM> passes or fails a certification test, a compatibility test, etc..

The operating markers <NUM> are security elements that can describe the operating properties for the programmable devices <NUM>. The operating markers <NUM> can include, but are not limited to, any of: operating voltages, voltage patterns, current levels, power draws, heating factors, critical operating frequencies, operating sequence information, operating parameters, etc..

The PUF markers <NUM> are security elements that can describe types of physical entities implemented in the programmable devices <NUM>. PUFs may be physical entities that are embodied in physical structures of the programmable devices <NUM>. PUFs may be evaluated but may not be predicted. Furthermore, an individual PUF device may be made but practically impossible to duplicate, even given the exact manufacturing process that produced it. PUFs may be implemented in integrated circuits of the programmable devices <NUM>. PUFs may be used in secure data applications.

PUFs may depend on the uniqueness of their physical microstructures. These microstructures may depend on random physical factors that may be introduced during manufacturing of the programmable devices <NUM>. These factors may be unpredictable or uncontrollable, thus making it impossible to duplicate or clone the microstructures.

For example, PUFs may be subject to environmental variations, including, but are not limited to, any of: temperatures, supply voltages, electromagnetic interferences, etc., which may affect the performance of the PUFs. Also, for example, the PUF markers <NUM> may include, but are not limited to, any of: a number of static random-access memory (SRAM) bits at power up, etc..

The security keys <NUM> are information used for cryptography. The security keys <NUM> may include at least a pair of a private key and a public key that are used together for cryptography. For example, security information may be encrypted with the private key and decrypted using the public key. Also, for example, security information encrypted using the public key may be decrypted using the private key. Each programmable device <NUM> may include a separate key pair that may be used to individually encrypt or decrypt the security information <NUM> stored in the programmable device <NUM>. The security master system <NUM> or the secure master storage system <NUM> may generate and securely store the security keys <NUM> for encrypting or decrypting the security information <NUM>.

The product markers <NUM> are security elements that can describe the products used with the programmable devices <NUM>. The product markers <NUM> may include related manufacturers, branding information, product line information, model information, or other product related parameters, etc..

In one or more embodiments, the device birth certificate <NUM> may include a device related fingerprint. The device related fingerprint may be associated with a programmable device <NUM>. For example, the device related fingerprint may include, but is not limited to, any combination of the serial number markers <NUM>, the manufacturer markers <NUM>, the manufacturing markers <NUM>, etc..

For example, the serial number markers <NUM> may include a device serial number that uniquely identifies the programmable device <NUM>. Also, for example, the manufacturer markers <NUM> may include a manufacturer ID that uniquely identifies a manufacturer of the programmable device <NUM>.

For example, the manufacturing markers <NUM> may include a customer ID that uniquely identifies an entity, a company, a person, etc., that contracts or hires a manufacturer to make, use, or program the programmable device <NUM>. Also, for example, the manufacturing markers <NUM> may include device coordinates (e.g., geographical coordinates X, Y, and Z in meters, etc.) that identify a physical location where the programmable device <NUM> is made or assembled.

The device coordinates may be applicable to a programmable device <NUM> that was at rest or within a predefined distance from a physical location of the manufacturer when the programmable device <NUM> was manufactured by the manufacturer. In an embodiment, the device security of the programmable device <NUM> is greatly simplified by verifying the device coordinates in the manufacturing markers <NUM> before the programmable device <NUM> is programmed. The programmable device <NUM> may be programmed only if the device coordinates point to a physical geographical location of an authorized manufacturer.

In one or more embodiments, the device birth certificate <NUM> may include a programming related fingerprint. For example, the programming related fingerprint may include, but is not limited to, any combination of the manufacturer markers <NUM>, the manufacturing markers <NUM>, the software markers <NUM>, etc..

For example, the manufacturer markers <NUM> may include programming company IDs that uniquely identify companies that are hired or contracted to program the programmable devices <NUM>. Also, for example, the manufacturer markers <NUM> may include programmer IDs that uniquely identify serial numbers of programmers <NUM> that are used to program the programmable devices <NUM>.

For example, the manufacturing markers <NUM> may include programming coordinates (e.g., geographical coordinates X, Y, and Z in meters, etc.) that identify a physical location where the programmable device <NUM> was programmed. Also, for example, the manufacturing markers <NUM> may include a job key that is used for cryptography to protect a programming job. As such, the job key may secure programming jobs throughout a supply chain, where the jobs may be transferred from an OEM/design facility to a manufacturing facility. The job key may also facilitate traceability of a programming job in a job store repository (e.g., server, private cloud, public cloud, etc.).

For example, the manufacturing markers <NUM> may include a job checksum that may be used to verify a programming job. The checksum may be computed by a programming engine of the programmer <NUM>.

In one or more embodiments, the device birth certificate <NUM> may include a security related fingerprint. For example, the security related fingerprint may include, but is not limited to, the security keys <NUM>, etc..

For example, the security keys <NUM> may include device keys that may be used for cryptography to protect secure information in the programmable devices <NUM>. Also, for example, the device keys may include, but are not limited to, any of: asymmetric keys, symmetric keys, etc., to encrypt or decrypt information in the device birth certificate <NUM>. The security keys <NUM> may enable the programmer <NUM> to securely communicate with trusted endpoints (e.g., servers, trusted devices, etc.).

In one or more embodiments, the device birth certificate <NUM> may include a fingerprint to enhance or improve device identification and authentication. For example, the fingerprint for the device identification and authentication may include, but is not limited to, any combination of the serial number markers <NUM>, the manufacturing markers <NUM>, etc..

For example, the serial number markers <NUM> may include serial numbers of components on a printed circuit board during manufacture. Also, for example, the serial numbers may represent IDs or unique identifiers of central processing units (CPUs), other electrical components, users of the programming unit <NUM>, etc., on the PCB. Further, for example, the serial number markers <NUM> may include MAC addresses of PCBs, system-on-a-chips (SoCs), peripheral devices, etc..

For example, the manufacturing markers <NUM> may include device data, including, but are not limited to, pictures or images showing placement of various components (e.g., CPUs, SoCs, peripheral devices, etc.) on a PCB. Also, for example, the manufacturing markers <NUM> may include pictures in any formats (e.g., Joint Photographic Experts Group (JPEG), Graphics Interchange Format(GIF), Tagged Image File Format (TIFF), Portable Network Graphics (PNG), bitmap image file (BMP), device independent bitmap (DIB), etc.). Captured pictures stored in the programmable devices <NUM> may subsequently be retrieved by the secure programming system <NUM> for verification or identification of a device, a board, a system, etc..

In one or more embodiments, the device birth certificate <NUM> may include a fingerprint for a secure storage of code or data. For example, the fingerprint for the secure storage may include, but is not limited to, any combination of the security keys <NUM>, the software markers <NUM>, etc..

For example, the security keys <NUM> may be used for software (SW), which may be pre-installed on the system during manufacture. The SW may be pre-installed prior to programming the programmable devices <NUM>. The SW may be pre-installed on the programmer <NUM>, the security controller <NUM>, the security modules (e.g., <NUM>, <NUM>, <NUM>, etc.), the security master system <NUM>, the secure master storage system <NUM>, etc..

For example, the security keys <NUM> may include a pair of a private key and a public key. SW may be encrypted with the private key and decrypted using the public key. Similarly, SW encrypted using the public key may be decrypted using the private key. SW may be encrypted by any of: the programmer <NUM>, the security controller <NUM>, the security modules (e.g., <NUM>, <NUM>, <NUM>, etc.), the security master system <NUM>, the secure master storage system <NUM>, etc. Prior to programming the programmable devices <NUM>, the programmer <NUM> may use the public key to decrypt the encrypted SW. After SW is decrypted, SW may be used to retrieve the device birth certificate <NUM>.

For example, the software markers <NUM> may include information that describe or identify additional codes that are security sensitive. The codes may be run on the programmable devices <NUM>. The codes may be extracted or decrypted on demand to provide access to data related to the device birth certificate <NUM>. In an embodiment, data security is greatly simplified using codes encrypted and programmed into the programmable devices <NUM> at manufacture of the programmable devices <NUM>. Only the codes that are programmed on the programmable devices <NUM> may be used to access the device birth certificate <NUM>.

For example, codes that are programmed on the programmable devices <NUM> may be identified only by the software markers <NUM>. The software markers <NUM> may identify a location or an address of a secure storage where the codes are stored. As such, the codes that are hidden or have access restriction enhance security.

In one or more embodiments, birth certificate related data on the programmable devices <NUM> may be secured by the secure programming system <NUM>. Data related to the device birth certificate <NUM> may be stored in non-volatile, tamper resistant, and secure memories on the programmable devices <NUM>.

The device birth certificate <NUM> may be secured because the device birth certificate <NUM> is encrypted and may only be decrypted by a system or a device having the correct security keys <NUM>. Contents of the memories on the programmable devices <NUM> may be programmed to store the device birth certificate <NUM> only during manufacture of the programmable devices <NUM>.

For example, for the programmable devices <NUM> (e.g., smartphones, tablets, set top boxes, etc.) that use embedded MMC (eMMC) flash storage, a Replay Protected Memory Block (RPMB) partition of the flash storage may be used to store the device birth certificate <NUM>. An RPMB partition may be used for storing secure data because it prevents illegal data copy or access. An RPMB partition may only be handled or accessed by security keys. For example, security keys may include, but is not limited to, any of: hash functions, checksums, Data Encryption Standard (DES) algorithms, Advanced Encryption Standard (AES) algorithms, triple-DES algorithms, MD4 message-digest algorithms, MD5 algorithms, Secure Hash Algorithms <NUM> and <NUM>, any other algorithms, etc..

Also, for example, a write-protected partition of a flash storage may be used to store the device birth certificate <NUM> in conjunction with cryptography to create a tamper resistant and secure area for storage. For microcontroller-based devices, a one-time programmable (OTP) memory or a flash memory may be used with cryptography to store the device birth certificate <NUM> data securely. Microcontrollers may support secure data exchange protocols that may not be available during normal operation of the programmable devices <NUM>. Prior to normal operation of the programmable devices <NUM>, such protocols may be used to securely exchange data with the programmable devices <NUM> in a process of programming the programmable devices <NUM>.

In one or more embodiments, for systems that do not include NVM, security chips may be used to hold a subset of information related to the device birth certificate <NUM> to enable device identification or authentication. For example, the security chips may include any combination of the security controller <NUM>, the security modules (e.g., <NUM>, <NUM>, <NUM>, etc.), the security master system <NUM>, the secure master storage system <NUM>, etc..

Referring now to <FIG>, therein is shown an example process flow for data security, in accordance with one or more embodiments. In some embodiments, a system (e.g., <NUM>) is performed through one or more computing devices or units.

Examples of some embodiments are represented, without limitation, in the following clauses:.

In an embodiment, the system encrypts the device identification with the security key, and the device birth certificate is generated with the device identification that has been encrypted.

In an embodiment, the device identification is a unique identifier of the programmable device.

In an embodiment, the device birth certificate is stored in a one-time programmable (OTP) memory of the programmable device.

In an embodiment, the device birth certificate includes a manufacturer marker, the manufacturer marker includes a manufacturer identification that uniquely identifies a manufacturer of the programmable device.

In an embodiment, the device birth certificate includes a manufacturer marker, the manufacturer marker includes a programmer identification that uniquely identifies a serial number of the programmer that programs the programmable device.

In an embodiment, the security key includes a pair of a public key and a private key.

Embodiments include an apparatus comprising a processor and configured to perform any one of the foregoing methods. Embodiments include a computer readable storage medium, storing software instructions, which when executed by one or more processors cause performance of any one of the foregoing methods.

Note that, although separate embodiments are discussed herein, any combination of embodiments and/or partial embodiments discussed herein may be combined to form further embodiments.

Other examples of these and other embodiments are found throughout this disclosure.

The special-purpose computing devices may be desktop computer systems, portable computer systems, handheld devices, smartphones, media devices, gaming consoles, networking devices, IoT devices, or any other device that incorporates hard-wired and/or program logic to implement the techniques.

Referring now to <FIG>, therein is shown a block diagram that illustrates a computer system <NUM> utilized in implementing the above-described techniques, according to an embodiment. Computer system <NUM> may be, for example, a desktop computing device, laptop computing device, tablet, smartphone, server appliance, computing mainframe, multimedia device, handheld device, networking apparatus, or any other suitable device.

Computer system <NUM> includes one or more busses <NUM> or other communication mechanism for communicating information, and one or more hardware processors <NUM> coupled with busses <NUM> for processing information. Hardware processors <NUM> may be, for example, a general purpose microprocessor. Busses <NUM> may include various internal and/or external components, including, without limitation, internal processor or memory busses, 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 <NUM> also includes a main memory <NUM>, such as a random access memory (RAM) or other dynamic or volatile storage device, coupled to bus <NUM> for storing information and instructions to be executed by processor <NUM>.

Computer system <NUM> further includes one or more read only memories (ROM) <NUM> or other static storage devices coupled to bus <NUM> for storing static information and instructions for processor <NUM>. One or more storage devices <NUM>, such as a solid-state drive (SSD), magnetic disk, optical disk, or other suitable non-volatile storage device, is provided and coupled to bus <NUM> for storing information and instructions.

Computer system <NUM> may be coupled via bus <NUM> to one or more displays <NUM> for presenting information to a computer user. For instance, computer system <NUM> may be connected via a High-Definition Multimedia Interface (HDMI) cable or other suitable cabling to a Liquid Crystal Display (LCD) monitor, and/or via a wireless connection such as peer-to-peer Wi-Fi Direct connection to a Light-Emitting Diode (LED) television. Other examples of suitable types of displays <NUM> may include, without limitation, plasma display devices, projectors, cathode ray tube (CRT) monitors, electronic paper, virtual reality headsets, braille terminal, and/or any other suitable device for outputting information to a computer user. In an embodiment, any suitable type of output device, such as, for instance, an audio speaker or printer, may be utilized instead of a display <NUM>.

In an embodiment, output to display <NUM> may be accelerated by one or more graphics processing unit (GPUs) in computer system <NUM>. A GPU may be, for example, a highly parallelized, multi-core floating point processing unit highly optimized to perform computing operations related to the display of graphics data, 3D data, and/or multimedia. In addition to computing image and/or video data directly for output to display <NUM>, a GPU may also be used to render imagery or other video data off-screen, and read that data back into a program for off-screen image processing with very high performance. Various other computing tasks may be off-loaded from the processor <NUM> to the GPU.

One or more input devices <NUM> are coupled to bus <NUM> for communicating information and command selections to processor <NUM>. One example of an input device <NUM> is a keyboard, including alphanumeric and other keys. Another type of user input device <NUM> is cursor control <NUM>, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor <NUM> and for controlling cursor movement on display <NUM>. Yet other examples of suitable input devices <NUM> include a touch-screen panel affixed to a display <NUM>, cameras, microphones, accelerometers, motion detectors, and/or other sensors. In an embodiment, a network-based input device <NUM> may be utilized. In such an embodiment, user input and/or other information or commands may be relayed via routers and/or switches on a Local Area Network (LAN) or other suitable shared network, or via a peer-to-peer network, from the input device <NUM> to a network link <NUM> on the computer system <NUM>.

A computer system <NUM> may implement techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computer system causes or programs computer system <NUM> to be a special-purpose machine.

The remote computer can load the instructions into its dynamic memory and use a modem to send the instructions over a network, such as a cable network or cellular network, as modulated signals. A modem local to computer system <NUM> can receive the data on the network and demodulate the signal to decode the transmitted instructions. Appropriate circuitry can then place the data on bus <NUM>.

A computer system <NUM> may also include, in an embodiment, one or more communication interfaces <NUM> coupled to bus <NUM>. A communication interface <NUM> provides a data communication coupling, typically two-way, to a network link <NUM> that is connected to a local network <NUM>. For example, a communication interface <NUM> 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 <NUM> may include a local area network (LAN) card to provide a data communication connection to a compatible LAN. As yet another example, the one or more communication interfaces <NUM> may include a wireless network interface controller, such as an <NUM>-based controller, Bluetooth controller, Long Term Evolution (LTE) modem, and/or other types of wireless interfaces. In any such implementation, communication interface <NUM> sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information.

For example, network link <NUM> may provide a connection through local network <NUM> to a host computer <NUM> or to data equipment operated by a Service Provider <NUM>. Service Provider <NUM>, which may for example be an Internet Service Provider (ISP), in turn provides data communication services through a wide area network, such as the world wide packet data communication network now commonly referred to as the "Internet" <NUM>.

In an embodiment, computer system <NUM> can send messages and receive data, including program code and/or other types of instructions, through the network(s), network link <NUM>, and communication interface <NUM>. The received code may be executed by hardware processors <NUM> as it is received, and/or stored in storage device <NUM>, or other non-volatile storage for later execution. As another example, information received via a network link <NUM> may be interpreted and/or processed by a software component of the computer system <NUM>, such as a web browser, application, or server, which in turn issues instructions based thereon to a hardware processor <NUM>, possibly via an operating system and/or other intermediate layers of software components.

In an embodiment, some or all of the systems described herein may be or comprise server computer systems, including one or more computer systems <NUM> that collectively implement various components of the system as a set of server-side processes. The server computer systems may include web server, application server, database server, and/or other conventional server components that certain above-described components utilize to provide the described functionality. The server computer systems may receive network-based communications comprising input data from any of a variety of sources, including without limitation user-operated client computing devices such as desktop computers, tablets, or smartphones, remote sensing devices, and/or other server computer systems.

In an embodiment, certain server components may be implemented in full or in part using "cloud"-based components that are coupled to the systems by one or more networks, such as the Internet. The cloud-based components may expose interfaces by which they provide processing, storage, software, and/or other resources to other components of the systems. In an embodiment, the cloud-based components may be implemented by third-party entities, on behalf of another entity for whom the components are deployed. In other embodiments, however, the described systems may be implemented entirely by computer systems owned and operated by a single entity.

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

As used herein, the terms "first," "second," "certain," and "particular" are used as naming conventions to distinguish queries, plans, representations, steps, objects, devices, or other items from each other, so that these items may be referenced after they have been introduced. Unless otherwise specified herein, the use of these terms does not imply an ordering, timing, or any other characteristic of the referenced items.

In the drawings, the various components are depicted as being communicatively coupled to various other components by arrows. These arrows illustrate only certain examples of information flows between the components. Neither the direction of the arrows nor the lack of arrow lines between certain components should be interpreted as indicating the existence or absence of communication between the certain components themselves. Indeed, each component may feature a suitable communication interface by which the component may become communicatively coupled to other components as needed to accomplish any of the functions described herein.

In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. Thus, the sole and exclusive indicator of what is the invention, and is intended by the applicants to be 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 out in the claims of this application, it is to be noted that the features of the dependent claims of this application may be combined as appropriate with the features of other dependent claims and with the features of the independent claims of this application, and not merely according to the specific dependencies recited in the set of claims. Moreover, although separate embodiments are discussed herein, any combination of embodiments and/or partial embodiments discussed herein may be combined to form further embodiments.

Claim 1:
A system (<NUM>) comprising:
a serial number server (<NUM>) integrated within a programmer (<NUM>) and configured to:
generate a serial number (<NUM>) unique and serialized for a programmable device (<NUM>), the programmable device (<NUM>) comprising any of: an integrated circuit, a programmable logic device, a field programmable gate array, FPGA, or a smartphone;
a security controller (<NUM>) configured to:
generate a security key (<NUM>) to protect a content of the programmable device (<NUM>);
the programmer (<NUM>) configured to:
couple the programmable device (<NUM>) to the programmer (<NUM>) via an adapter (<NUM>),
generate a device birth certificate (<NUM>) that includes a manufacturing marker (<NUM>), the serial number (<NUM>) generated by the serial number server (<NUM>), and the security key (<NUM>), the manufacturing marker (<NUM>) identifying a location (<NUM>) where the programmable device (<NUM>) was manufactured,
encrypt the contents of the device birth certificate (<NUM>) with the security key (<NUM>), and
program a secure non-volatile memory area of the programmable device (<NUM>) with the device birth certificate (<NUM>) at time of manufacture of the programmable device (<NUM>) for improving security in a programming system (<NUM>) using the programmed device birth certificate (<NUM>) for subsequent authentication of the programmable device (<NUM>), wherein the secure non-volatile memory area includes an area of the programmable device (<NUM>) that cannot be tampered with or illegally accessed by an unauthorized user and may be programmed to store the device birth certificate (<NUM>) only during manufacture of the programmable device (<NUM>); and
an authentication unit (<NUM>) configured to:
verify if the serial number (<NUM>) sent from a host computer (<NUM>) matches the serial number (<NUM>) that has been saved to the programmable device (<NUM>) for granting the host computer (<NUM>) access to the programmable device (<NUM>) that has been identified by the serial number (<NUM>).