HK1155587B - System and method for remote device registration - Google Patents

Abstract

A system and method for remote device registration, to monitor and meter the injection of keying or other confidential information onto a device, is provided. A producer who utilizes one or more separate manufacturers, operates a remote module that communicates over forward and backward channels with a local module at the manufacturer. Encrypted data transmissions are sent by producer to the manufacturer and are decrypted to obtain sensitive data used in the devices. As data transmissions are decrypted, credits from a credit pool are depleted and can be replenished by the producer through credit instructions. As distribution images are decrypted, usage records are created and eventually concatenated, and sent as usage reports back to the producer, to enable the producer to monitor and meter production at the manufacturer. In an alternative arrangement overproduction may be inhibited by introducing a separation of duties within a manufacturing process. Typically a producer will contract out the various stages of manufacturing to multiple contractors. In general, separation of duties involves purposefully separating manufacturing stages, for silicon chips or other devices, so that the end product must have been "touched", by each subcontractor, in order for the end product to be fully functional.

Description

System and method for remote device registration

Description of the cases

The present application is a divisional application of the chinese patent application entitled "system and method for remote device registration" filed on 12/6/2006 with application number 200680025923.6.

Technical Field

The present invention relates generally to the manufacture of devices having sensitive data contained therein, and in particular to remotely controlling and monitoring the injection of such sensitive data into such devices.

Background

Devices participating in a cryptographically secure communication system will typically have some type of unique and immutable information that is injected into the device at the time of manufacture of the device. This information may be a cryptographic key, a shared secret, or some other data that may be cryptographically bound to an inherently unique property of the device. Such information may be generally referred to as a "key" and the injection of information may be generally referred to as "keying" or "key injection" the device.

The purpose of the injected key is to ensure that the device is accepted as a trusted participant of the secure communication system at some point in the future after the device has been distributed. However, the producer of the device may often wish to ensure that the device is legitimately manufactured and thus wishes to protect the key that is injected into the device. Producers typically attempt to protect keys to protect future revenues because authentication of keys can be used to provide conditional access to the security system and its contents, etc. In addition, the key that is injected is important because it enables the customer or user of the device to avoid the lengthy process required to register the device.

Such conditional access of the device to the system may be granted based on the cryptographic authentication key being trusted. This trust is based on the fact that: it is extremely difficult to reproduce trusted data outside the manufacturing process. Systems providing conditional access, including, for example, satellite television and radio, continually disseminate information, but it is desirable to control access to their content and thus control revenue for providing such content. These systems rely on manufacturing processes and Original Equipment Manufacturers (OEMs), specifically key injection, to provide a root of trust for the devices and ultimately for the entire secure communication system.

The key injected into the device is sometimes in a standard format and purchased from the governing body, e.g., a High Definition Content Protection (HDCP) key that is used to protect data when it is sent from your computer to your display, etc. via a cable. The governing body is thus also interested in ensuring that the keys distributed to the device producers are protected from loss. This creates producer responsibility and thus increases the importance of protecting the injected key. In some cases, the producer may be penalized for losing or duplicating the key, and if they gain an inadvertent reputation of handling the key, the governing body may limit or restrict the distribution of the key. Maintaining this relationship is often important to the producer, especially when the key is in a standard format required for the device to be compatible with other devices and/or infrastructure. In this case, if a particular key cannot be used, the device will not function as intended.

In modern commercial environments involving ever increasing device complexity and sophistication, it is common for individual components to be manufactured and keyed by one manufacturer and then assembled by another manufacturer. In this case, there are certain safety concerns when the producer of the device or the owner of the communication system is not the manufacturer of the device. Thus, it is critical for a device producer to ensure the authenticity of the manufacturing system that is responsible for the authenticity of the producer's device.

Of particular concern when considering the authenticity of the manufacturing process is the issue related to the confidentiality of the secret information used to manufacture the device, and the issue of ensuring that the manufacturer accurately informs the producer of the identity and quantity of the units manufactured. Ideally, the producer of a device should try to get assurance that the producer has not created and distributed "grey market" or "black market" parts or devices. For example, a certain number of keyed products are sent back to the producer, but the producer still has the remaining keys, and those excess keys can then be used to manufacture and sell devices. The producer thus loses revenue because the producer is the person who profits from the sale. Other actions such as cloning or stealing the key may also occur, which are difficult to detect and control when the keying process is outsourced. In some cases, the key may be published on the internet so that the user can gain access to the conditional access system without paying for such a service.

Traditionally, producers who are concerned about keeping the information injection phase secret at the manufacturing site have had little other choice but absolute trust that the producer is operating in a manner that properly accounts for producer device and system security. The protection mechanism is typically naive, in that the keying information is typically bulk-keyed and sent to the manufacturer where all keying information is decrypted immediately upon arrival of the information, the manufacturer being trusted not to compromise the bulk information.

One method of restricting access to keyed information is to use an online client server mechanism. With this mechanism in place, a client at the manufacturer's facility will be connected to the network and will request keying information on a per device basis from a remote key providing server under the control of the producer.

There are many problems with implementing such manufacturing systems that rely on off-site, remotely networked servers and provide keying information in real-time. The foremost problem is that off-board servers cannot guarantee a minimum service level or response time to the manufacturing line if they use a common shared packet-switched network. To prevent problems on the manufacturing line, a certain service level is optimal in terms of latency and throughput. Given the modern production situation, where manufacturing lines exist in remote jurisdictions with respect to producers, such guaranteed network availability can be very expensive.

Manufacturing equipment typically does not begin a production run until all necessary materials, including data materials, are not ready. Otherwise, the risk of line delays will be high. Any keying system used by the manufacturer should be able to substantially guarantee service availability and provide an appropriate response. This requires that all data sources and keying information be available locally prior to a production run.

Given that all data sources must be available locally to the production line that may exist on the computer system and to the media that is not under the direct control of the producer, the producer must consider how to ensure the confidentiality of any secret keying information.

In order to start and complete a production run, sufficient data should be available locally to the manufacturer. In the event that a producer discovers the producer's unauthorized and contract-violating behavior, the producer should also consider how to prevent such a rogue producer from producing gray or black market products after the contract is terminated.

Another problem associated with cloning stems from overproduction, a particular type of cloning operation that is of particular concern to silicon chip producers. Overproduction can occur when a producer of an Integrated Circuit (IC) outsources their IC design to one or more third party manufacturing companies for manufacture. The purpose of outsourcing some or all of the manufacturing steps is to reduce production costs by selecting a third party that can provide the best price for a particular stage in the manufacturing process. For example, a factory-less design room (e.g., a producer) may wish to contract with overseas manufacturers to produce chips that they have designed. Such overseas manufacturers are often selected because they are able to produce electronic components relatively inexpensively.

Outsourcing, however, generally increases the risk that a particular contractual party may over-produce a product that they have contracted to produce to supply the grey market. For example, if a contracted manufacturer is not credited and overproduces an IC according to a design provided by a producer without notifying the producer of such overproduction, additional products may be sold in a grey market channel as "counterfeit" or "cloned" ICs. This allows third party manufacturers to realize additional profits and revenues at the expense of revenue and future product demand for their customers, i.e., producers/designers.

This may occur because in these cases, often the producer will not process the product except to receive the engineering sample at the beginning of the production phase. Thus, there is an opportunity to steal parts and products at various stages of the manufacturing process after the design. In some cases, an employee of a contract manufacturer who has good credit may be a thief. "yield shrinkage" may occur when an employee steals a product directly from a manufacturing line. This is detrimental not only to producers and contract manufacturers due to revenue, but also to relationships between producers and manufacturers that conduct future business.

It is therefore an object of the present invention to obviate or mitigate the above disadvantages.

Disclosure of Invention

The present invention provides systems and methods that enable a producer who wishes to use a separate entity for at least a portion of a manufacturing process to monitor and protect device production from a remote location.

The present invention also provides means for segregating the addition of sensitive data to the product between segregated entities to inhibit grey market production due to overproduction and yield shrinkage.

In one aspect, the present invention provides a method for remotely controlling the injection of sensitive data into a device during device production. The method comprises the following steps: the controller prepares and cryptographically protects sensitive data in the data transmission; the controller transmits data transmission to a server, and the server is provided with a security module used for executing password operation; the security module extracts sensitive data from the data transmission; and the server providing the sensitive data to the device for injection into the device; wherein the controller is remotely located with respect to the server.

In another aspect, the present invention provides a system for remotely controlling the injection of sensitive data into a device during device production. The system comprises: a controller having a first security module for performing cryptographic operations; the server is remotely located with respect to the server and connected to the controller through a forward channel and a backward channel, the forward channel being used by the controller for providing a data transmission to the server, the data transmission cryptographically protecting sensitive data, the second security module extracting data from the transmission; and an agent, operative with the device, for injecting the data after extracting the data from the transmission, the agent obtaining the data from the second security module.

In another aspect, a module for controlling insertion of sensitive data into a device in multiple stages is provided. The module includes a cryptographic transform that intercepts and transforms the data stream in the device and a cryptographic key stored in memory, a portion of the sensitive data being added to the cryptographic key at various stages, the cryptographic key being transformed for its operation, wherein the cryptographic transform correctly alters the data stream after successful insertion of the sensitive data.

In another aspect, a method for controlling the injection of sensitive data into a device is provided. The method comprises the following steps: including a module in the device, the module having a cryptographic transform for intercepting and transforming a data stream in the device; and adding a portion of the sensitive data to a memory stored in the module at each of a plurality of stages in device production; wherein the cryptographic transformation correctly alters the data stream after successful insertion of the sensitive data.

Drawings

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings.

FIG. 1 is a schematic block diagram of a remote device registration system;

FIG. 2 is a schematic representation of the Graphical User Interface (GUI) illustrated in FIG. 1;

FIG. 3 is a schematic representation of a distribution image;

FIG. 4 is a flow chart illustrating a key injection and reporting process;

FIG. 5 is a flow chart illustrating a preparation process;

FIG. 6 is a flow chart depicting a credit indication process;

FIG. 7 illustrates a mapping scheme of another embodiment supporting multiple products;

FIG. 8 illustrates an example of a filtered log report; and

fig. 9 is a block diagram illustrating another embodiment of a remote device registration system.

FIG. 10 is a schematic block diagram of an embodiment of key injection using multiple stages in a manufacturing process.

FIG. 11 is a schematic representation of a mask incorporating a registration model using the embodiment of FIG. 10 to separate the key injection phase.

Fig. 12 is a schematic representation of a stage of the embodiment shown in fig. 10.

Fig. 13 is a flowchart of the steps taken in producing a device using the embodiment of fig. 10.

FIG. 14 is a schematic block diagram of an example product produced according to the mask shown in FIG. 11.

Detailed Description

Referring to fig. 1, a remote device registration or trusted key injection system is indicated generally by the reference numeral 10. The producer 12 of the device 22 utilizes the services of a separate entity, in this case the external manufacturer 14, to inject unique and invariant information into the device 22. The information, which will be referred to as a "key" hereinafter, may be a cryptographic key, a shared secret, or some other data that may be cryptographically bound to an inherently unique property of the device 22. The step of injecting the key into the device 22 will be referred to hereinafter as "keying" or "key injection".

The producer 12 utilizes a controller 16, with the controller 16 being a remote computer system to the manufacturer's facility. The controller 16 includes a Hardware Security Module (HSM) 11. The HSM11 is a protected device used by the controller 16 to perform cryptographic security operations such as encryption, decryption, and signing. The HSM11 may be tamper resistant (e.g. physically inaccessible) or may be reactive to tampering (e.g. erase data if tampered with). The controller 16 is responsible for packaging and communicating the keys and other information to the manufacturer 14 and for monitoring the distribution and use of the keys by the manufacturer 14. The producer 12 typically obtains the bulk key (not shown) from an external source such as a governing body, e.g., the producer of the HDCP key. The keys are stored in the data storage device 15 until they are distributed to a particular manufacturer 14. The controller 12 and its operation may be monitored, modified and thereby controlled by an operator using a Graphical User Interface (GUI) 13. The GUI 13 is typically a software application that is displayed using and interacts with a personal computer (not shown).

The controller 16 is connected to the server 18 at the manufacturer 14 through a conduit 23. The conduit 23 includes two forward communication channels, a control channel 26 and a distribution channel 25, and a backward channel 24. The control channel 26 is used by the controller 16 to measure the number of keys that the manufacturer 14 may use by sending a credit indication. The distribution channel 25 is used by the controller 16 to distribute the protected key block to the maker 14. The backward channel 24 is used by the system 10 to make the controller 16 aware of the use of keys for reporting and auditing purposes. Channels 24, 25 and 26 may be any communication channel and need not be reliable or secure. Using a combination of technical mechanisms and processes provides reliability and security over the channels 24, 25 and 26. For example, if a message sent to the module 18 on the forward path 26 is not decrypted because it is corrupted, the user may call the operator of the system controller module 16 and then have them send the message again.

The manufacturer 14 utilizes one or more servers 18. to the manufacturer's facility, the servers 18 are local computer systems and the activities of the servers are monitored and measured by messages sent by the controller 16. The server 18 also reports back to the controller 16 via the back channel 24. The server 18 includes an HSM28 similar to the HSM11 utilized by the controller 16. The HSM28 stores a protected credit pool 30 that indicates how many keys the manufacturer 14 may use. The use of the key is measured by the controller 16 by monitoring the data reported by the server 18 and adding or subtracting from the credit pool 30 accordingly. Credit pool 30 is an abstraction that represents the number of keys that can be decrypted by HSM28 before server 18 must request and obtain more keys from controller 16. The controller 16 distributes the key to the server 18 over a distribution channel 25 and, as explained more fully below, the server 18 will store the key in the local data storage device 17.

Manufacturer 14 utilizes one or more devices 20, and devices 20 are used to inject encryption keys into devices 22. Typically, keying occurs during a test phase of the manufacturing process, and thus the device 20 is often a tester on an assembly line. The device 20 comprises a key agent 21, the key agent 21 typically being a software program or a toolkit that is loaded to the device 20 for managing key injection on the application side. The key proxy 21 communicates with the server 18 to request and obtain keys when they are needed. Typically, the server 18 will provide enough keys to the key agent 21 so as not to disrupt the timing of the production process. However, the server 18 will not provide an unnecessary number of keys to limit the use of keys until a keying authorization is provided by the controller 16 based on the measurement of the credit pool 30.

Typically, the key agent 21 has a threshold level that indicates when a new batch of keys is required for a particular device 20 so as not to disrupt production. Because the controller 16 is not generally in continuous communication with the server 18, as explained in more detail below, before the controller 16 can obtain a key usage report from the server 18, the controller 16 may adjust its parameters to ensure that sufficient keying material is available to the device 20 through the server 18, while ensuring that no excess key data is released by the server 18.

The key agent 21 preferably includes an Application Program Interface (API) that runs on the device 20 to enable an operator of the device itself to request the key either manually or in an automated manner. The key proxy 21 is used to provide a level of protection for data transfer between the server 18 and the appliance and may be considered a simplified Secure Socket Layer (SSL) between the server 18 and the appliance 20. It should be understood that the key proxy 21 may also be implemented using an SSL connection between itself and the server 18 if resources allow it. The key broker 21 is also responsible for generating a reporting record when the key is used, the reporting record being sent back to the server 18 for reporting purposes.

Controller 16 is a command center for monitoring and metering key injection by manufacturer 14. To control the encryption keys from a remote location, the GUI 13 is used by an operator to monitor and configure the various manufacturers 14, servers 18, and devices 20 under the control of the controller 16. An example GUI 13 is shown in FIG. 2. The GUI 13 is divided into a server window 200, a controller window 204, and a device window 202. The server window 200 includes the list of manufacturers 14 controlled by the controller 16 and the server 18. A particular controller 16 is indicated in the controller window 204. The operator may select a particular manufacturer (e.g., manufacturer a shown in fig. 2) and the devices 20 associated with the manufacturer are displayed in the device window 202.

In the example shown in FIG. 2, the server at manufacturer A includes a window that provides information about server 1, server 2, and server 3. Each server has certain data associated with it. For example, as shown in FIG. 2, the various servers include process columns that show their available storage space, available credits, and the number of keys available for each of key type 1 and key type 2. Each tester window also displays log information such as the date the previous report was processed, the previously reported credits, the previous replenishment amount (refill account), and data regarding the missing log records. The server window also provides options 214 and 216 to the operator to remotely configure and disable the server 18 from the controller 16.

The controller 16 has the capability of remotely configuring the server 18. This allows the controller 16 to change key types, add or delete key types, and control other configuration options. This is preferably accomplished by sending a configuration message along the control channel 26 to the server HSM 28. HSM28 may evaluate the configuration messages, whereby some configuration messages change the behavior of HSM28 and other configuration messages are sent to server 18. Configuration messages sent to the server 18 via the HSM28 using this method may help ensure that the server 18 obtains configuration instructions that are trusted and known to be from the controller 16.

Controller 16 may remotely configure system 10 at the server or device level through key proxy 21. The controller 16 may also force polling of the servers 18 and may adjust the interval of regular polling. Typically, the servers 18 are polled at fixed intervals, and the controller 16 may use forced polling to obtain information between intervals, if desired. For example, at one day interval, the controller 16 may need data to report to the manager of the day, and may force polling of all servers to obtain such data. The GUI 13 may also include a controller email option that allows the controller 16 to automatically contact the manager in extreme circumstances such as decryption or distribution failure in critical production runs.

The individual keys distributed by the devices 20 to the servers 18 and injected into the appliances 22 trigger certain logging under certain events. The GUI 13 may be used to search, sort, edit, and analyze log records, and browse custom or standard reports 400 as shown in fig. 8. In this example, there are three primary log records that are generated. When the key is distributed by the producer 16 to the server 18, a key-to-server log 402 is generated, a key-to-proxy log 404 is generated by the HSM28 at the point that the HSM28 releases the key to the key proxy 21, and a key injection log 406 is generated by the key proxy 21 after the key is injected. Each log record may include any number of identifying information including ID type, timestamp, manufacturer, device, etc. In the example report shown in fig. 8, report 400 illustrates a key-to-server log 402, a key-to-proxy log 404, and a key injection log 406 for a key with a sequence ID of 001. These records can then be used to track the life cycle of a key with such a serial ID number. It should be appreciated that the report 400 may include any number of records and may be filtered based on any suitable fields. For example, a report 400 of all keys injected by tester 2 on day 5, month 3 at manufacturer a may be compiled accordingly by filtering the date field and the location field.

Referring now to fig. 3, using distribution image 40 to be sent to server 18, producer 16 may package a batch of group keys in a secure data transmission, preferably using encryption. Distribution image 40 enables the producer to include keys for multiple products assigned to multiple servers 18 in one transmission. But each server 18 is able to decrypt and obtain a certain number of keys only after the HSM28 has received authentication from the controller 16 via the control channel 26. The image 40 is a collection of data records, each record containing a type 58, an ID 60, a size 54, and a data 56 field, where the data 56 will generally contain key data of any size identified by the size 54. The type 58 and ID 60 fields are used by the HSM28 to identify key data, possibly used to filter certain keys, as previously indicated via the control channel 26, depending on the configuration of the HSM 28. The key may be encapsulated so that the implementation does not care what the target key actually looks like. This makes it flexible and extensible without the need to redesign for each new key type. The wrapper (wrapper) should contain type, size and unique ID, the body being abstract. The wrapper may also contain elements that support more advanced features, such as logs or variables that are assigned to abstract images.

The image 40 is encrypted with an image key 42. The image key 42 is used by the server 18 to decrypt the image 40 and obtain the key. The image key 42 is encrypted for each server 18 itself and stored as a server header 48. A set of server headers 48 is stored in the master header 46. To decrypt the image 40 and obtain the key, the header 48 is selected by the server 18 and decrypted by the HSM28 to obtain the image key 42. The image key 42 is then used to decrypt the image 40.

As previously mentioned, the distribution image 40 may be used to support multiple products. Referring additionally to FIG. 7, a mapping of product types and data chunks is shown. For example, producer 16 has three products, γ (gamma) with key 1 (with filter label 1), β (beta) with key 2 (with filter label 2) and accompanying configuration block (also with filter label 2), and α (alpha) with key 1, key 2 and configuration block. The image 40 may include a batch of key types 1 and 2, and gamma (gamma) and beta (beta) products may be less complex than alpha (alpha) products. Producer 16 may package a single image 40, e.g., 50 per piece, with data whereby a certain tester, e.g., tester 1, has a manufacturer-made license, thereby potentially obtaining fifty (50) filter labels 1 and 2 for producing fifty alpha (alpha) products. Another tester, such as tester 2, may have permission from the manufacturer to make at the same time, thus obtaining fifty (50) filter labels 1 from image 40 to produce fifty beta (beta) products, and fifty (50) filter labels 2 to produce gamma (gamma) products. The image 40 may contain all key data, possibly including multiple types of keys, to produce a single product of any product type. The tester identifies to the server 18 the product type or product model number being programmed. This model information is sent to the HSM28 along with the encrypted image 40 so that when the HSM28 decrypts the image 40, the key data 50 can be filtered and only the key data needed to program the identified product model is released by the HSM28 to the tester. Thus, producer 12 may support multiple products with a single image 40 while taking steps to ensure that manufacturers 14 can only manufacture the products they should manufacture.

Because the image 40 may support multiple products, the log record is used to track the actual key injection performed at the tester, as will be explained more fully below. By tracking the log records, producer 16 may attempt to detect, for example, whether manufacturer 14 returned 50 gamma products instead of 50 alpha products (which they have paid to produce), and thus they may have sold 50 beta products on the grey or black markets. Such differences may or may not be malicious, but in any case can be reasonably identified.

A typical life cycle of a key being reported to the controller 16 on the back channel 24 from its distribution on the distribution channel 25 to the HSM28 is shown in fig. 4. The blocks highlighted in fig. 4 represent those steps performed by the security modules, i.e. HSM11 and HSM 28. The controller 16 first obtains a batch of standard keys from an external provider. The controller 16 then passes the key to the HSM11 and the HSM11 encrypts a block of keys, each block containing a measured number of a certain key type. It should be understood that the keys may also be bulk encrypted into blocks having more than one key type. The controller 16 then stores the bulk encrypted key in the storage device 15 until it receives an indication or other command indicating that the key block is to be distributed.

When the producer 16 distributes the key block, it first obtains a block that is bulk encrypted and passes the block to the HSM 11. The HSM11 decrypts the block and re-encrypts the key block for transmission with the image key 42. Then, for each server 18, the image key 42 itself is encrypted to produce each header 48. These headers 48 are stored in the group 44 of main headers 46. Here, the HSM11 generates a key to the server log 402 for the key that has been re-encrypted for distribution. The log 402 is stored locally at the producer 12 for later analysis. The re-encrypted keyblob is then distributed to the server 18 over the distribution channel 25.

The server 18 passes the encrypted keyblob included in the image 40 to the HSM28, and the HSM28 then decrypts the image 40. The HSM28 first selects its particular header 48 from the set 44 and decrypts the image key 42. The image key 42 is then decrypted to obtain the key from the image 40. The image 40 is then preferably verified and filtered, for example using a secure hash algorithm, MAC or digital signature. The HSM28 then also re-encrypts the respective keys obtained from the image 40 for storage. The server 18 then stores the re-encrypted key locally for later use by the device 20. It should be understood that the authenticity of the image 40 is based on the unique symmetric distribution key K shared between the controller 16 and the server 18_s1And K_s2And is recognized. Once a successful plausibility check has been performed, e.g., after a sha-2 digest (digest) comparison, there betweenThe shared message may be considered trusted.

When controller 16 receives a request from device 20 for a certain number of keys (e.g., N keys), HSM28 is given N keys to decrypt. For each of the N keys decrypted by HSM28, a key-to-proxy log record 404 is generated and these keys are passed to device 20 for injection. Here, the key is "in the clear" and is thus ready for injection.

Device 20 injects each of the N keys and key agent 21 generates key injection log records 406 for each key that is injected. The HSM28 will continuously obtain keys to the proxy log record 404 and key injection log record 406 and preferably concatenate these records into a master log report R that is sent back to the controller 16 on the back channel 24.

The respective logs are preferably concatenated into a binary file that identifies the date on which the file was generated. Report R is preferably used by HSM28 with encryption key k₁Encrypted and returned to the application running on the server 18 to be sent over the back channel 24. The controller 16 may then decrypt the report R and validate the respective logs (e.g., 402, 404, 406). The logs may be tagged with a monotonic number of synchronizations. If all record ID values put together are not a continuous set, the operator of the controller 16 will know where to track the missing logs in the sequence.

As explained above, when N keys are distributed, the controller 16 has pre-stored a number of keys to the server log record 402 for them. Thus, the controller 16 expects to receive a report R of the completion of the life cycle for each key at some future time to indicate that the originally distributed key has been decrypted by the correct server 18 and injected into the correct device. Thus, the controller 16 can evaluate the log reports as they are provided. The controller 16 may then determine whether any action should be taken, such as intervening in the manufacturing operation (e.g., stopping distribution) or providing more keys. The controller 16 may also obtain further information before distributing further key blocks. In this manner, the controller 16 can measure the distribution and provide more keys only if the manufacturer operates with good credit and consistently provides accurate log reports.

Log reports, such as those shown in fig. 8, enable the producer to recognize discontinuities in the ID number sequence. For example, if a large number of keys have been distributed but have not reported to the agent or key injection log, the manufacturer may have lost the key. This may indicate grey or black market activity. In another case, report R may include a key-to-proxy log 404, but not a key injection log 406 for a particular key. This may indicate that the problem originated at the particular device requesting the key, rather than the manufacturer 14 itself. Thus, manufacturer 14 may also use log reports R for auditing purposes as well as to identify internal malicious activity to maintain its relationship with producer 12. The life cycle of each key requires a report record at each critical stage of key operation. Thus, the producer 12 has the necessary information to identify where the problem is present and will attempt to correct or eliminate the problem. Preferably, the log report includes not only information on the number of key sequences but also information on the type of key. In this manner, the producer 12 may also determine whether the alpha product is commissioned for manufacture, and whether the gamma and beta products may have been produced.

The log reports provide information to deter malicious or unscrupulous behavior of the manufacturer 14, while also providing a means of assessing the integrity of existing manufacturers 14 and a tool to provide evidence of any undesirable activity. The use of physical evidence in detecting undesirable activities allows the producer 12 to face the producer 14 more than just in a suspicious attitude, which may save an important relationship between the producer 12 and the producer 14 in the event that illegal activities occur at the level of the testing machine (e.g., caused by employees rather than the company itself).

In addition to distribution, the controller 16 also uses the control channel 26 to control the credit pool 30 to gauge the key injection phase. The credit indication process is shown in fig. 6. The HSM28 must consume credits from the credit pool 30 in decrypting the distribution image 40 and obtaining the key. Over time, the credit pool 30 will decrease, requiring replenishment with the credit indication file sent by the controller 16.

On the control channel 26, the controller 16 sends only one control message C at a time to the server 18. One of the preferably required files contained in the message is a credit indication file. The file may be an encrypted data set for a particular server 18 that is decrypted by the HSM28 into a credit indication. The credit indication includes, for example, a serial number of the HSM28 and/or the server 18, a token ID of the server, a sequence number, a new credit amount, and configuration data, all of which have been flagged by the controller 16.

Upon receiving control message C, HSM28 decrypts the credit indication data from control message C and verifies the signature. The HSM28 also verifies the serial number and token ID as it's own if applicable. Verification of the sequence number is then performed. The number of sequences should be greater than the sequences stored internally in the HSM 28. Once verified, the HSM28 will update its internal sequence number and set the value of the credit pool 30 to the credit value in the credit indication.

As explained previously in connection with GUI 13, HSM28 will then process any of the configuration messages in control message C to update its internal configuration, so that controller 16 can push configuration data to server 18, e.g., for updating of filtering rules, keying information, credit rules, etc. The configuration data may be intended for the HSM28, an application running on the server 18, or even the key agent 21. The HSM28 looks for configuration messages of the defined type to process them. Configuration messages are marked as private or public and access to them will then be controlled by the HSM 28.

Credit report C_rIs the server's response to the credit indication in the process control message C. Credit report C_rMay include the serial number and token ID of the HSM28, the current sequence value, the current value of the credit pool 30, and so onThe number of supplements so far and the error code, if no error occurred during the credit indication process, the error code is set to zero.

Its signing key k is preferably used by the HSM28₂To mark credit report C_r. Report C to controller 16_rThen used the public encryption key k of the controller₃To be encrypted. Report C_rAnd then sent to the controller 16 and stored with the log report R for auditing purposes as described above.

Before distributing the keys, the producer 12 and the manufacturer 14 may go through a preliminary process to initialize the HSM and the server 18. This preparatory process is shown in fig. 5. The HSM28 generates and sends a prepare request message P to the controller 16. Message P preferably contains the sequence number of the HSM28 being used by the server 18. HSM28 generates two cryptographic key pairs k₁、k₂(e.g., RSA key pair or preferably using Elliptic Curve Cryptography (ECC)), one (k)₁) For receiving an encrypted message, another (k)₂) For marking outgoing messages. Preferably, at key pair k₁And k₂During the exchange, the producer 14 is cryptographically booted (cryptographically bootstrapped) in the physically controlled environment.

When the controller 16 receives a prepare request from the server 18, it passes the request to the HSM11, and the HSM11 checks the authenticity of the message and then assigns a "token ID" to the manufacturer 14. Two keys, preferably a symmetric key k_s1And k_s2(e.g., an Advanced Encryption Standard (AES) key) is generated. As previously mentioned, these keys will be used by the controller 16 and server 18 to protect the distribution image 40 on the distribution channel 25 and the log report R on the back channel 24.

The HSM11 then generates a preliminary response message P' containing, for example, the assigned token ID, the HSM encrypted public key and the respective signing key pair k₃And k₄Distribution and backward channel symmetric key k_s1And k_s2Some initial configurationsData, and a hash digest (hash digest) for authenticity. Similar to the provisioning request message P, it is assumed that the provisioning response message P' is processed within the physically controllable environment (e.g., using HSM protection).

The provisioning response message P' may then be sent to the server 18, and the server 18 may perform initialization operations upon receiving its first provisioning request. The structure of the preliminary response may include a portion that is decrypted into a separate structure containing symmetric keys for forward and backward channel communications between the controller 16 and the server 18. It should be noted that these keys are different for each HSM28 (and thus for each server 18) and are not shared among a group of HSMs. When the preparation process is completed, the normal exchange between distribution image 40 and control message C may begin.

In another embodiment, as shown in FIG. 9, the system 10 may be retrofitted to existing solutions that have been implemented by the manufacturer 14 for protecting the key injection stage. In the embodiment shown in FIG. 9, like elements are indicated by like reference numerals followed by the suffix "a". For example, manufacturer 14 may have apparatus 20a, apparatus 20a already including scrambler 74 for transforming the string "BCA" into "ABC", where device 22 is wired to accept ABC as the key that is being implanted. In this manner, if the key "BCA" is stolen or misplaced, it will not work for device 22a, since scrambling has not yet occurred. These attempts at protecting keys, while easy to implement, are generally very naive and do not provide an adequate level of protection. By being compatible with such protection, the system 10 may then be retrofitted to the device 20a without undoing the existing solutions that have been implemented. Thus, additional costs to the manufacturer 14 for implementing the system 10 may be avoided. This modification can be implemented until a complete redesign is ensured, at which point the arrangement shown in fig. 1 can be used.

To accommodate existing solutions, the system 10 stores at the server 18a set of tagged objects 72, which are a collection of executables associated with a particular device 20a that execute the existing solution after the HSM28 a releases the key and before key injection. In this way, the key is changed to be compatible with existing solutions without the device 20a knowing it. As shown in fig. 9, the controller 16a will first need to access an executable file (exe)70 used by the device 20a to provide the existing solution. The controller 16a then passes the executable file 70 to the HSM11 a. HSM11 a then marks up executable 70 and passes the marked up executable 70 to HSM28 a, and HSM28 a then stores the marked up executable 70 as marked up object 72. In operation, when device 20a requests a new batch of keys, server 18a will verify the executable against the signature of the executable stored in HSM28 a. Once server 18a has authenticated executable 72, it will send the executable key to be scrambled.

For example, device 20a requests key BCA to feed scrambler 76 in device 22a so that key ABC is injected into product α (alpha). HSM28 a determines that product alpha has an object executable a marked for modifying key ABC. The marked object executable a is verified and applied to key ABC resulting in scrambled key BCA. The scrambled key BCA is then sent to device 20a, and the scrambler 76 modifies key BCA so that it injects key ABC. The device 20a is unaware that the key BCA (that it receives) is stored as ABC in protected form by the server 18 a. It should be appreciated that the key stored by server 18a may also be in a form such as CAB and then modified to read BCA for scrambling to be converted to ABC for injection. This situation may occur when: the key CAB is a standard form and must be modified to accommodate existing solutions where CAB is not acceptable as a key. Accordingly, the tagged object 72 will contain any programming necessary to accommodate the existing solution implemented by the device 20a, and the example provided above is for illustrative purposes only.

The tagged object 72 also prohibits malicious code from being loaded into the server 18a to modify the key prior to injection, since the tagged executable file is generally authenticated against the key to be released to the machine before it is used for the key. The system 10 may thus provide an increased level of security while being compatible with existing solutions.

Thus, by utilizing a remote system controller 16 separate from server 18, producer 12 is able to monitor manufacturer 14 activity and measure credits through HSM 28. Producer 16 is thus able to manage the injection of keying information on device 22 to ensure that manufacturer 14 correctly reports the identity and quantity of units manufactured by producer 12. This enables producer 12 to ensure that producer 14 does not produce and distribute gray or black market products or devices 22.

With the above process and system 10 in place, producer 12 may monitor production at manufacturer 14. Producer 12 may measure the production of device 22 by adding or removing available credits used by manufacturer 14 using the credit indication in control message C.

It should be understood that system 10 is not limited to one manufacturer 14 as shown in FIG. 1, nor are individual manufacturers 14 limited to a set of devices 20. Nor is the system 10 limited to the use of a single controller 16. The HSM28 is most preferably trusted hardware to protect the authenticity of the key values and the credit pool 30. Further, the encryption key information contained in the distribution image 40 does not necessarily have to be encryption key information, but may be any data element that requires confidentiality and authenticity. The requirement for keying data is typical of systems 10 that wish to enhance device activation granularity.

In an alternative arrangement, illustrated in fig. 10 through 14 and described in more detail below, overproduction may be inhibited by introducing a separation of responsibilities during the silicon wafer or device fabrication process. Typically, producer 12 will contract out different stages of manufacturing to multiple contractors. In general, separation of responsibilities involves purposefully separating manufacturing stages of silicon chips or other devices so that the end product must have been "touched" by the individual subcontractors in order for the end product to be fully functional. Because the grey market is typically provided by a single point of failure or a single non-credited contractor in the manufacturing chain, forcing a group of contractors to operate in sequence means that two or more subcontractors must conspire against the producer 12 in order to provide the grey market with non-defective sub-components or devices. The final product, and its subcomponents, should complete all stages of manufacture to be fully functional. In general, when multiple subcontractors need collusion for theft, the risk of attacking producer 12 is greatly reduced.

In the production of silicon wafers, several stages generally occur, which are often divided among several third party manufacturers. The producer 12 of the design chip will create the design in a data file or data files, often referred to as a "net list". The netlist contains a description language in the form of computer code for instructing a third party how to produce the mask to produce the silicon wafer from which the ICs are packaged and distributed.

For example, in an illustrative manufacturing process, masks may be sent by a manufacturer 12 to a silicon producer who manufactures silicon wafers from the masks. The wafer may then be sent to a wafer test facility where individual chips are tested directly on the wafer and electronically marked so that only the individual chips that pass through will be forwarded to the packaging facility when cut. The packaging equipment will bond and package the silicon into a chip package and test the final packaged chip again. The finished chip is then typically sent to the OEM, where the chip is mounted on a printed circuit board that is part of the finished interim product, and the finished device product is sent to a distribution channel, ultimately to the customer.

The illustrative manufacturing process described above generally includes multiple stages that occur between design and integration of a silicon chip into a device, namely fabrication, testing, packaging, and installation. It will be appreciated that all of these stages may alternatively occur at a single facility, and that there may also be more stages, up to any N stages. At each of these stages, overproduction or yield shrinkage can occur.

Referring now to FIG. 10, a manufacturer 12 designs a mask 90. Mask 90 is used to produce registration device 22, which in this example is an IC. Device 22 includes some form of sensitive or invariant information to be included in its design and preferably is not operable without such sensitive information. In this example, producer 12 establishes contracts with two or more third party manufacturing entities that perform particular stages in the overall manufacture of device 22. Fig. 10 shows a first manufacturing stage 100, a second manufacturing stage 102, up to an arbitrary nth manufacturing stage 104.

Producer manufacturer 12 dispenses mask 90 over product dispensing channel 80. The mask 90 is sent to a first manufacturing stage 100 where production of a portion of the manufacturing, such as a silicon wafer, occurs. When the first stage 100 is completed, the resulting partially completed product is sent to the second manufacturing stage 102 to complete a second partial manufacturing, such as testing of wafers. This is repeated for each stage up to any nth stage that ultimately ships a fully functional registration device 22 to the distribution entity 106.

In one of the manufacturing entities 100 to 104, in order to prevent incomplete products or sub-components from being diverted to the grey market 110, a "separation of responsibility" is applied. Separation of responsibilities is the separation of manufacturing and data programming responsibilities at various manufacturing stages such that all responsibilities must be performed by the intended contractor in the intended order, which is necessary to complete the production of non-defective devices. In this example, sensitive tasks such as cryptographic data injection are injected at multiple stages, each of which is implemented by a different manufacturing entity during a different manufacturing stage. To separate the sensitive task(s), producer 12 incorporates registration module 92 into the design defined in mask 90. The module 92 is used so that when the mask 90 is edited to produce the device 22, the mathematical transform intercepts critical signals and data streams within the silicon chip, such as enable signals, and the device 22 is defective if the mathematical transform is inoperable. For performance reasons, the mathematical transformation is preferably a cryptographic transformation that widely uses exclusive or (XOR) operations, but this is not a requirement. At various stages of the manufacturing process, in order for the mathematical transformation to operate, it is registered by incremental or incremental injection of critical data, such as part of the cryptographic keying data. In this manner, if the wafer produced in the first stage 100 is overproduced and supplied to grey market stages 2 through N, as shown at 110 in FIG. 10, then the product 112 is defective, generally because it has not yet received all of the cryptographic data necessary for normal operation.

Preferably, as shown by way of example in fig. 10, the key injection system 10 described above in fig. 1 to 9 may be used to distribute, measure and solicit a report of the key injection phase at various manufacturing steps. In this case, even if all entities collude to distribute gray market products, the producer 12 can detect this due to incomplete log reports and, if necessary, prohibit further distribution of the keyed data. It should be understood that system 10 may alternatively be used at any number of stages, and need not be used at all at each or any stage. For example, the second stage 102 may utilize the system 10 rather than any other stage. However, since it is preferred that various stages of manufacturing will include some form of testing process, it is beneficial to incorporate system 10 into such testing. The producer 12 in this case expects data at least during the second phase. It should be appreciated that the module 92 may be used independently of the system 10 and may rely on various manufacturing stages to implement a portion of the keying process. In either of these cases, by separating responsibilities, none of the entities themselves have the necessary information to successfully supply the product or sub-component to the gray market.

The mask 90 is shown in more detail in fig. 11. As discussed above, the registration module 92 may be incorporated into any mask design, and the mask 90 is then programmed to implement a set of instructions or lines of code, etc., the mask 90 will partially insert what is defined in the module 92 within a path (preferably one that is critical to device operation) between one portion of customer code 120 and another portion of customer code 122. Data entering module 92 along path 124 is applied to cryptographic transform 128 and output to portion 122 along path 126. Preferably, the output appearing at path 126 will only be available if the cryptographic transformation 128 was successfully applied to the data input at path 124. The cryptographic transform 128 preferably works in conjunction with the memory 130, the processor 132, and the cryptographic key 134 to perform its operations. Memory 130, processor 132 and cryptographic key 134 are configured, preferably using key injection system 10 that exists at various stages of manufacture. Memory 130 also includes another cryptographic key 131, cryptographic key 131 generally comprising keying material accumulated at various stages, preferably by injection using key injection system 10 shown in FIG. 10. Preferably, key 134 is used at the time of injection to ensure that the material accumulated in memory 130 that makes up key 131 is authentic. The key 134 may or may not be a public key. For example, module 92 may operate without key 134, potentially risking some attack that may or may not be related to a particular producer 12.

In general, the sensitive data used by module 92 is divided into portions, each of which is added to key 131 at various stages of the manufacturing process. For example, one technique is to inject digital signatures with message recovery at various stages in the manufacturing process. Key 134 may be used to verify a digital signature, in doing so, the verified digital signature produces a message that may be used in a key derivation scheme to derive cryptographic key 131 using data present in memory 130. Another example is the use of key-shading techniques, in which a plurality of cryptographic keys 131 are added to memory 130 at various stages of manufacture. When the final manufacturing stage has been completed, memory 130 contains enough data so that key masking techniques can be used to reconstitute cryptographic key 131.

An example of a first manufacturing stage 100 is shown in fig. 12. As previously mentioned, producer 12 preferably utilizes system 10 to distribute keying data and to monitor reports generated as the keying occurs. Key implantation into a silicon chip typically occurs at wafer test or at post-package test. In this example, stage 100 includes and testingThe device 20 operates together with a server 18 and a key agent 21. Stage 100 also includes production equipment 139, for example, to produce silicon wafers. Production equipment 139 uses mask 90 dispensed over channel 80 to produce partially fabricated devices₁140. The subscript 1 in this example is used to denote the first portion of sensitive data applied to device 22, which is preferably injected using key agent 21 of apparatus 20. Preferably here, the device₁It is not yet fully operational because the transform 128 does not yet have all the necessary information to perform its operations. Device with a metal layer₁And then available for distribution to the second manufacturing stage 102.

Fig. 13 provides a flow diagram illustrating an example manufacturing process including two different manufacturing stages (i.e., N-2). In step 500, the producer 12 determines the number of stages and thus the number of keyed data portions to be injected, N being 2 in this example. At step 502, producer 12 preferably establishes key injection system 10 that links the various manufacturing stages to itself over channels 24, 25, and 26. As previously discussed with reference to FIG. 1, a producer 12 may use a single controller 16 to communicate with multiple servers 18. In this example, the producer 12 will distribute, monitor and receive log records from two servers 18.

At step 504, the producer 12 incorporates the registration module 92 into its design, which is defined in the mask 90. Mask 90 is then distributed to first manufacturer 100 to implement stage 1 of the manufacturing process at step 506, and stage 1 is performed at step 508. For example, a first manufacturer would produce a wafer, create chips that fit into mask 90. During wafer testing, the manufacturer may then program some portion of the keying material into memory 130. This portion of sensitive data is inserted at step 510 and the server 18 will report to the producer at step 512, preferably using the mechanisms outlined above. Alternatively, phase 1 may not handle the injection of any sensitive data, and then the operation may be performed solely during phase 2.

When the first part of the encrypted key data is encryptedWhen programmed into a chip or device, the product contains only partial keying information and is not sufficient to operate properly. Pass device₁To figure 13, where subscript 1 represents the first part as described above. The partially produced, partially programmed device 1 is then distributed to phase 2 at step 514 for execution at step 516. The manufacturer 102 will then inject the second partial key data at step 518. For example, at step 518, the second manufacturer 102 may program additional keying information, or may derive cryptographic keying information using the partial key data stored in memory 130 during step 510 and using the new key data from system 10 at step 518. This derivation step may be based on hashing or possibly more complex key masking techniques. Preferably, at step 520, second manufacturer 102 reports back to producer 12 that the second key portion was successfully injected. The producer 12 may now have two log records indicating that the key data has been successfully inserted and may use this information to monitor its records.

Once the second partially-keyed data is inserted, in this example, device 22 is fully produced and fully registered (e.g., tested and packaged IC), and in FIG. 13 by the device₁₂Where the subscript 12 indicates the complete set of key data, i.e. data part 1 and data part 2. In step 522, the device₁₂And then proceeds to the distribution channel where the device, at step 524, is₁₂Eventually reaching the customer as a valid product.

As illustrated in FIG. 13, for example, if first manufacturer 100 or an employee thereof attempted to dispense gray market products at step 526, then the defective products would be provided to the customer at step 530 through an alternate dispensing channel at step 528 because the devices₁Only the first portion of key data is contained and thus the transform 128 cannot perform its operations. Thus, while testing, packaging, etc. may be performed in grey stage 2, additional keying data is not provided so product 530 is fully manufactured, but is not fully registered, rendering it defective. It should be understood that the module 92 is preferably implemented so as to be tamper-resistantMeans are considered and implemented.

Referring now to FIG. 14, there is shown a schematic example of a completed customer product 22a incorporating a module 92a, where the module 92a is a logical representation of the physical layout of the module 92 shown in FIG. 11. In fig. 14, like reference numerals may be given the suffix "a" for clarity. Product 22a using an implementation of module 92 (e.g., 92a) can apply cryptographic transformation 128a as part of implementing block 150 to the critical data path of the product between codes 120a and 122 a. By transforming 128a, the path is decoded so that the customer logic 122a can function properly. In this example, verification 132a is performed as an implementation of processor 132. The authentication 132a uses a one-time programmable (OTP) memory 130a and an identity portion 134a that is an implementation of the key 134 of fig. 11. Key 134a is injected with memory 130a and sensitive data using, for example, the process outlined in fig. 13. It should be understood that the article 22a is but one implementation that incorporates the logic provided by the module 92 (e.g., module 92a), and that the example shown in FIG. 14 is for illustration purposes only.

While the above has been described with reference to certain specific embodiments, various modifications thereof will be apparent to those skilled in the art.

Claims (61)

1. A method for controlling insertion of sensitive data into a device, the method comprising:

configuring a server to be communicatively connected to a controller responsible for distributing the sensitive data and a device responsible for injecting the sensitive data into the appliance, the server being remotely located with respect to the controller, the server including a security module for performing cryptographic operations;

the server receiving a password-protected data transmission from the controller including the sensitive data;

the server providing the data transmission to the security module;

the security module extracting the sensitive data from the data transmission;

the server storing a credit value provided by the controller, the credit value indicating a quantity of sensitive data that can be decrypted by the security module before requesting more of the sensitive data from the controller;

the server receiving a request from the appliance to inject the sensitive data into one or more of the devices;

the server providing to the device an amount of the sensitive data for injection into the one or more appliances;

the server receiving a credit indication from the controller indicating an update to the credit value and setting the credit value to a credit value in the credit indication;

the server receiving a device log report relating to insertion of the amount of sensitive data into the corresponding appliance; and

the server sends the device log report to the controller.

2. The method of claim 1, further comprising: the security module preparing a server log report indicating a distribution of the sensitive data to the device; and the server sending the server log report to the controller.

3. The method of claim 2, wherein the extracting comprises: the security module decrypts a header included in the data transmission to obtain a key, and uses the key to decrypt the transmission and extract the sensitive data therefrom.

4. The method of claim 1, further comprising: a provisioning process performed prior to receiving the sensitive data from the controller, the provisioning process to initialize the server and the security module.

5. The method of claim 1, comprising a plurality of servers, wherein the data transmission is sent to the plurality of servers.

6. The method of claim 1, further comprising: the server receiving an object from the controller for implementing an existing data injection scheme that modifies the sensitive data; the object has been signed, the signed object being provided to the security module; the security module storing the signed object, verifying the signed object, and if the signed object is verified, modifying the sensitive data according to the existing data injection scheme; and the server sending the modified sensitive data to the device for injection into the one or more appliances.

7. The method of claim 2, wherein the data transmission includes multiple types of sensitive data, the method further comprising: the security module obtains some of the types based on permissions established by the controller.

8. The method of claim 7, wherein the server log report includes an indication of which of the types the security module has provided to the device.

9. The method of claim 1, further comprising: the server receives a configuration message from the controller, the configuration message for modifying settings in the security module.

10. The method of claim 2, wherein the device log reports and server log reports are provided to the controller in response to polling initiated by one of the server and the controller.

11. The method of claim 2, wherein the device log report and server log report are provided to the controller to obtain additional sensitive data, wherein if the log report is favorable and additional sensitive data is required, receiving a further data transmission; if the log report is not favorable, the server receives an indication from the controller to inhibit further extraction of the data from any previous transmissions.

12. The method of claim 1, wherein the sensitive data is a plurality of keys, the data transmission including some of the keys encrypted by a security module of the controller; and said extracting said data comprises: decrypting a particular one of the keys as indicated by an indication previously provided by the controller.

13. The method of claim 12, wherein the security module, upon receiving the keys, decrypts them and re-encrypts each key separately; wherein upon a request by the device, some of the keys are decrypted for use by the device.

14. The method of claim 1, wherein the security module contains a symmetric key for communicating over forward and backward communication channels between the server and the controller.

15. A server for controlling insertion of sensitive data into an appliance, the server communicatively connected to a controller responsible for distributing the sensitive data and to a device responsible for injecting the sensitive data into the appliance, the server remotely located with respect to the controller, the server comprising a security module for performing cryptographic operations,

the server is configured to:

receiving a cryptographically secured data transmission from the controller including the sensitive data;

providing the data transmission to the security module;

the security module extracting the sensitive data from the data transmission;

storing a credit value provided by the controller, the credit value indicating a quantity of sensitive data that can be decrypted by the security module before requesting more of the sensitive data from the controller;

receiving a request from the device to inject the sensitive data into one or more of the devices;

providing to the apparatus an amount of the sensitive data for injection into the one or more devices;

receiving a credit indication from the controller indicating an update to the credit value and setting the credit value to a credit value in the credit indication;

receiving a device log report relating to the insertion of the amount of sensitive data into the corresponding appliance; and

sending the device log report to the controller.

16. The server of claim 15, wherein the security module is configured to prepare a server log report indicating distribution of the sensitive data to the device and provide the server log report to the controller.

17. The server of claim 15, wherein the header of the data transmission encrypts a data key using an encryption key; the security module comprises a decryption key for decrypting the data key; and the security module is configured to decrypt the transmission using the data key to extract the sensitive data therefrom.

18. The server of claim 16, wherein the server further comprises: a data storage device to store the data transfer prior to extracting the sensitive data from the data transfer.

19. The server of claim 15, wherein the server is further configured to: participating in a provisioning process prior to receiving the data transmission, the provisioning process for initializing the server and the security module.

20. The server of claim 15, comprising a plurality of servers, wherein the data transmission is sent to the plurality of servers.

21. The server of claim 18, further configured to: receiving an object from the controller for implementing an existing data injection scheme that modifies the sensitive data; the object has been signed, the signed object being provided to the security module; wherein the security module is configured to store the signed object, verify the signed object, modify the sensitive data according to the existing data injection scheme if the signed object is verified, and send the modified sensitive data to the device for injection into the one or more appliances.

22. The server of claim 16, wherein the data transmission includes multiple types of sensitive data, some of the types being obtained by the security module in accordance with permissions established by the controller.

23. The server of claim 22, wherein the server log report includes an indication of which of the types the security module has provided to the device.

24. The server of claim 15, further configured to: receiving a configuration message from the controller, the configuration message for modifying settings in the security module.

25. The server of claim 16, wherein the device log reports and server log reports are provided to the controller in response to polling initiated by one of the server and the controller.

26. The server of claim 16, wherein the device log report and server log report are provided to the controller to obtain additional sensitive data, wherein if the log report is favorable and additional sensitive data is required, a further data transmission is received; if the log report is not favorable, the server receives an indication from the controller to inhibit further extraction of the data from any previous transmissions.

27. The server of claim 15, wherein the sensitive data is a plurality of keys, the data transmission including some of the keys encrypted by a security module of the controller; and said extracting said data comprises: decrypting a particular one of the keys as indicated by an indication previously provided by the controller.

28. The server of claim 27, wherein the security module, upon receiving the keys, decrypts them and re-encrypts each key separately; wherein upon a request by the device, some of the keys are decrypted for use by the device.

29. The server of claim 15, wherein the security module contains a symmetric key for communicating over forward and backward communication channels between the server and the controller.

30. A method for controlling insertion of sensitive data into a device, the method comprising:

configuring a controller to be communicatively connected to a server, the server being remotely located with respect to the controller and configured to be communicatively connected to a device responsible for injecting the sensitive data into the appliance, the controller being configured to distribute the sensitive data to the server to enable the server to provide the sensitive data to the device, the controller including a security module for performing cryptographic operations;

the controller cryptographically protecting the sensitive data using the security module;

the controller sending a password-protected data transmission including the sensitive data to the server to enable the server to extract the sensitive data therefrom;

the controller providing a credit value to the server, the credit value indicating a quantity of sensitive data that can be decrypted by the server before requesting more of the sensitive data from the controller;

the controller receives a device log report from the server, the device log report relating to the device inserting the amount of the sensitive data into a corresponding appliance after the device obtains the amount of the sensitive data from the server by the request, the device log report obtained by the server from the device.

31. The method of claim 30, further comprising: a request for further sensitive data is received from the server and the further sensitive data is provided to the server.

32. The method of claim 30, further comprising: receiving a server log report, the server log report prepared by the server and indicating distribution of the sensitive data to the device.

33. The method of claim 30, wherein the security module encrypts a header included in the data transmission to protect a key that enables the server to decrypt the transmission and extract the sensitive data therefrom.

34. The method of claim 30, further comprising: initiating a provisioning process performed prior to sending the sensitive data to the server, the provisioning process to initialize the server and the security module.

35. The method of claim 30, comprising: sending the data transmission to a plurality of servers.

36. The method of claim 30, further comprising: the controller sends a credit indication to the server indicating an update to the credit value.

37. The method of claim 30, further comprising: the controller sending an object to the server for implementing an existing data injection scheme that modifies the sensitive data; the object is signed to be provided to a security module of the server to store the signed object, the signed object is verified, and if the signed object is verified, the sensitive data is modified according to the existing data injection scheme.

38. The method of claim 32, wherein the data transmission includes multiple types of sensitive data, the method further comprising: the security module transmits some of the types in accordance with permissions established by the controller.

39. The method of claim 38, wherein the server log report includes an indication of which of the types the security module has provided to the device.

40. The method of claim 30, further comprising: the controller sends a configuration message to the server, the configuration message for modifying settings in a security module at the server.

41. The method of claim 32, the device log report and server log report being received by the controller in response to a poll initiated by one of the server and the controller.

42. The method of claim 32, wherein the device log report and server log report are received by the controller to obtain additional sensitive data, wherein if the log report is favorable and additional sensitive data is required, sending a further data transmission to the server; if the log report is not favorable, the controller sends an indication to the server to inhibit further extraction of the data from any previous transmission.

43. The method of claim 30, wherein the sensitive data includes a plurality of keys, the data transmission including some of the keys encrypted by the security module to enable the server to decrypt a particular one of the keys as indicated by an indication previously provided by the controller.

44. The method of claim 43, wherein the security module encrypts the number of keys to enable the server to re-encrypt each key separately; wherein upon a request by the device, some of the keys are decrypted for use by the device.

45. The method of claim 30, wherein the security module contains a symmetric key for communicating over forward and backward communication channels between the server and the controller.

46. A controller device for controlling insertion of sensitive data into an appliance, the controller device communicatively connected to a server remotely located with respect to the controller device and configured to communicatively connect to a device responsible for injecting the sensitive data into the appliance, the controller device configured to distribute the sensitive data to the server to enable the server to provide the sensitive data to the device, the controller device comprising a security module for performing cryptographic operations;

the controller device is configured to:

cryptographically protecting the sensitive data using the security module;

sending a password-protected data transmission including the sensitive data to the server to enable the server to extract the sensitive data therefrom;

providing a credit value to the server, the credit value indicating a quantity of sensitive data that can be decrypted by the server before requesting more of the sensitive data from the controller device; and

receiving, from the server, a device log report relating to the number of sensitive data inserted by the device into a corresponding appliance after the number of sensitive data is obtained by the request from the server, the device log report obtained by the server from the device.

47. The controller device of claim 46, wherein the controller device is further configured to: a request for further sensitive data is received from the server and the further sensitive data is provided to the server.

48. The controller device of claim 46, wherein the controller device is further configured to: receiving a server log report, the server log report prepared by the server and indicating receipt of the sensitive data from the controller.

49. The controller device of claim 46, wherein the security module encrypts a header included in the data transmission to protect a key that enables the server to decrypt the transmission and extract the sensitive data therefrom.

50. The controller device of claim 46, wherein the controller device is further configured to: initiating a provisioning process performed prior to sending the sensitive data to the server, the provisioning process to initialize the server and the security module.

51. The controller device of claim 46, wherein the controller device is further configured to: sending the data transmission to a plurality of servers.

52. The controller device of claim 46, wherein the controller device is further configured to: sending a credit indication to the server indicating an update to the credit value.

53. The controller device of claim 46, wherein the controller device is further configured to: sending an object to the server for implementing an existing data injection scheme that modifies the sensitive data; the object is signed to be provided to a security module of the server to store the signed object, the signed object is verified, and if the signed object is verified, the sensitive data is modified according to the existing data injection scheme.

54. The controller device of claim 48, wherein the data transmission comprises multiple types of sensitive data, wherein the controller device is further configured to: some of the types are sent according to permissions established by the controller device.

55. The controller device of claim 54, wherein the server log report includes an indication of which of the types the security module has provided to the device.

56. The controller device of claim 46, wherein the controller device is further configured to: sending a configuration message to the server, the configuration message to modify a setting in a security module at the server.

57. The controller device of claim 48, wherein the device log reports and server log reports are received by the controller device in response to a poll initiated by one of the server and the controller.

58. The controller device of claim 48, wherein the device log report and server log report are received by the controller to obtain additional sensitive data, wherein if the log report is favorable and requires additional sensitive data, a further data transmission is sent to the server; if the log report is not favorable, the controller sends an indication to the server to inhibit further extraction of the data from any previous transmission.

59. The controller device of claim 46, wherein the sensitive data includes a plurality of keys, the data transmission including some of the keys encrypted by the security module to enable the server to decrypt a particular one of the keys as indicated by an indication previously provided by the controller device.

60. The controller device of claim 59, wherein the security module encrypts the some keys to enable the server to re-encrypt each key separately; wherein upon a request by the device, some of the keys are decrypted for use by the device.

61. The controller device of claim 46, wherein the security module contains a symmetric key for communicating over forward and backward communication channels between the server and the controller.