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

Abstract

PROBLEM TO BE SOLVED: To provide a system and method for remote device registration to monitor and measure the injection of keying or other confidential information onto a device.SOLUTION: 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 the 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, thereby enabling the producer to monitor and measure production at the manufacturer. In an alternative arrangement, overproduction may be inhibited by introducing a separation of duties within a manufacturing process.

Description

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

  A device involved in a cryptographically secure communication system typically has some type of unique and invariant information that is injected into the device at the time of manufacture. This information may be an encryption key, a shared secret, or other data that can be cryptographically tied to an inherently unique attribute of the device. Such information is commonly referred to as a “key” and the injection of information is generally referred to as “keying” or “key injection” to the device.

The purpose of injecting the key is to ensure that at some point in the future after the device has been delivered, it will be accepted as a legitimate participant in the safety communication system. However, device producers will often want to ensure that the device is legally manufactured, and therefore want to protect the keys injected into the device. Producers typically attempt to protect keys to protect future interests because key authentication provides conditional access to the safety system and its contents and the like. The injected key is also important because it allows the customer or user of the device to avoid the redundant procedures required to register the device.

The device is granted such conditional access to the system based on cryptographic authentication that the key is trusted. This trust is based on the fact that it is very difficult to replicate trusted data outside the manufacturing process. Systems that provide conditional access, such as satellite television and radio, continuously broadcast information, but benefit from controlling access to its content and thereby providing such content. The system that wants to control is included. These systems can provide a foundation of trust for the equipment and ultimately for the overall safety communication system by relying on the manufacturing process and original equipment manufacturer (OEM), especially key injection.

The key injected into the device may be in a standard format, for example, HDCP (High Definition Content Protection) key used to protect data, especially when sent from the user's PC to the monitor via cable. Can be purchased from government agencies. Government agencies are thus interested in ensuring that the key delivered to the producer of the device is protected and not lost. This puts responsibility on the producer and increases the importance of protecting the injected key. In some cases, producers may be fined for loss of keys or duplication of keys, and when it is popular that they ignore them when dealing with keys, agencies can restrict or It may be strict. Maintaining this relationship is often important for producers, especially when the key is the standard format required for the device to be compatible with other devices and / or infrastructure. In this case, if a special key cannot be used, the device will not work as intended.

In today's increasingly complex and sophisticated business environments, it is common for individual parts to be manufactured and keyed by one manufacturer, while another manufacturer is responsible for later assembly. . In such a situation, there is a security implication that the device producer or communication system owner is not the device manufacturer. Thus, for the producer of a device, it can be of utmost importance to ensure the integrity of the manufacturing system that is responsible for the integrity of the producer's device.

When considering the integrity of the manufacturing process, it is of particular interest to be used to manufacture the equipment, along with ensuring that the manufacturer accurately reports the identity and number of units manufactured to the producer. This is a problem related to the confidentiality of confidential information. Ideally, the device producer should attempt to obtain assurance that the manufacturer has not created and delivered a “gray” or “black” market part or device. For example, a number of keyed products have been sent back to the producer, but a manufacturer who still has the remaining keys can manufacture and sell the device with those extra keys. This means that the producer has lost profit because the manufacturer is the one who profits from sales. Cloning keys or stealing keys can also occur, which is difficult to detect or control when the keying process is outsourced. In some cases, keys are issued on the Internet, and users may gain access to the conditional access system without paying for such services.

Traditionally, producers interested in the safety of the information injection phase at the manufacturing site implicitly imply that the manufacturer is working in such a way as to give due consideration to the safety of the producer's equipment and its system. There is almost no choice but to trust. The protection mechanism is generally simple, as keying information is typically encrypted in bulk and sent to the manufacturer, where it arrives, all keying information is immediately decrypted, and the manufacturer Because it is a trusted mechanism that does not spoil a large amount of information.

One way to restrict access to keying information is to use an online client-server mechanism. If such a mechanism is in place, the client at the manufacturer's facility will request per-device keying information from a remote key serving server connected to the network and under the control of the producer.

There are a number of problems with implementing an off-site, remotely networked server-based manufacturing system that provides keying information in such a just-in-time manner. The most important problem is that the offsite server cannot guarantee the lowest service level or response time for the production line if it uses a public packet switched network. To avoid problems in the production line, a certain level of service in terms of latency and throughput is optimal. Given the modern manufacturing reality that the production line is in remote jurisdiction to the producer, the availability of such a guaranteed network can be prohibitively expensive.

Manufacturing equipment typically does not begin production operations unless all necessary materials are available, including data materials. Otherwise, the risk of production line delays is too high. Any keying system used by the manufacturer must be able to substantially guarantee service availability and provide an appropriate response. This requires local availability of all data resources and keying information before the start of production operation.

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

Sufficient data must be available locally to the manufacturer in order to start and end the production run. When a producer discovers an act that is not authorized by the manufacturer and violates the contract, the producer will prevent such a bad manufacturer from producing gray or black market products after the contract expires. You must think about.

Another problem with duplication is due to overproduction, a special type of duplication operation, which is of special interest for silicon chip producers. Overproduction can occur when integrated circuit (IC) producers outsource the manufacture of their IC designs to one or more third-party manufacturing companies. 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 cost for performing certain special steps in the manufacturing process. For example, a design office that does not own equipment (eg, a producer) may wish to contract with an overseas manufacturing facility for the production of chips they have designed. Such overseas manufacturing facilities are often selected because they can produce electronic equipment at a relatively low price.

However, outsourcing generally increases the risk that a special contractor will overproduce the products that are contracted for production to supply to the gray market. For example, if a contractor betrays trust and overproduces an IC from a design provided by the producer and does not report to the producer that such overproduction, then the excess It will be sold in the Gray Market Channel as a “replica” IC. This allows third party manufacturers to realize special benefits and savings at the expense of future product demand and benefits for customers, producers / designers.

This is because in such situations, the producer often does not handle any product other than receiving a technical sample at the beginning of the production phase. Thus, at each stage of the manufacturing process, there is an opportunity to steal parts and products following design. In some cases, a faithful contract manufacturer employee may be a thief. “Production reduction” can also occur because employees steal products directly from the production line. This is not only detrimental to producers and contract manufacturers due to lost profits, but also to the relationship between producers and manufacturers in doing their future work.

The object of the present invention is therefore to eliminate or alleviate the above disadvantages.

The present invention provides a system and method that allows producers who wish to use another entity for at least a portion of the manufacturing process to monitor and protect the production of the device from a remote location.

The present invention also provides a means for separating the addition of sensitive data to products between different entities to avoid gray market products due to overproduction and yield reduction.

In one form, the present invention provides a method for remotely controlling the injection of sensitive data into a device during the production of the device. In the method, the controller prepares confidential data and encrypts and protects the confidential data in data transmission, and the controller sends the data transmission to a server having a secure module that performs an encryption operation. And the secure module extracts the sensitive data from the data transmission and the server provides the sensitive data to equipment for injection into the device, the controller being located remotely from the server.

In another form, the present invention provides a system for remotely controlling the injection of sensitive data into a device during the production of the device. The system includes a controller having a first secure module that performs cryptographic operations and a server located away from the controller and connected to the controller by a forward channel and a reverse channel, wherein the forward direction The channel is used by the controller to provide a data transmission to the server's second secure module, the data transmission cryptographically protects sensitive data, and the second secure module extracts data from the transmission with the server Extracting data from the transmission comprises an agent that operates with the equipment used to inject the data and obtains data from the second secure module.

In yet another form, a module is provided for controlling the insertion of sensitive data into the device at multiple stages. This module is an encryption transform that intercepts and converts the data flow in the device and the encryption key stored in the memory. At each stage, a part of the confidential data is added to the encryption key, and the encryption key Includes a transform that is used by the transform for its operation, and the cryptographic transform changes the data flow correctly upon successful insertion of sensitive data.

In yet another form, a method is provided for controlling the insertion of sensitive data into a device. The method includes the step of including in the device a module having a cryptographic transform for intercepting and transforming the data flow in the device, and a cryptographic key stored in the memory of the module at each of a plurality of stages in the production of the device Including the step of adding a portion of the sensitive data, the cryptographic transform changes the data flow correctly upon successful insertion of the sensitive data.
For example, the present invention provides the following items.
(Item 1)
A method for remotely controlling the injection of sensitive data into a device during production of the device, comprising:
The controller preparing the confidential data and cryptographically protecting it in data transmission;
The controller sending the data transmission to a server having a secure module that performs cryptographic operations;
The secure module extracting the confidential data from the data transmission;
The server providing the confidential data to equipment for injection into the device;
The controller is located away from the server.
(Item 2)
The method of item 1, further comprising the step of the secure module providing a log report regarding the use of the confidential data to the controller.
(Item 3)
The extraction step includes the secure module decrypting the header included in the data transmission to obtain a key, and using the key to decrypt the transmission and extracting the data therefrom. The method described in 1.
(Item 4)
When the controller sends the data transmission, it generates a first log record, the first log record is stored by the controller for comparison with the log report, and the secure module sends the data to the device Providing a second log record indicating delivery of the data to the device, wherein the second log record is included in the log report.
(Item 5)
5. The method of item 4, further comprising the step of the server receiving a third log record included in the log report indicating the injection of the data from the device into the device.
(Item 6)
The method of item 1, further comprising a provisioning procedure that is executed prior to the controller preparing and protecting the data and used to initialize the server and the secure module.
(Item 7)
The method of item 1, comprising a plurality of servers, wherein said step of sending said data transmission comprises sending said data transmission to said plurality of servers.
(Item 8)
In order for the controller to update the value of the credit pool, a credit command indicating a credit value representing the number of data elements of the data transmission from which the secure module can extract the confidential data is sent to the server. The method of item 1, further comprising the step of providing.
(Item 9)
7. The method of item 6, wherein the secure module consumes credits from the credit pool when extracting the data from the data transmission, thereby reducing the value of the credit pool.
(Item 10)
Prior to the preparing step, the method includes: the controller receiving an object for implementing an existing data injection solution that modifies the data; the controller signing the object and the signed object. To the secure module, the secure module stores the signed object, verifies the signed object, and if the signed object is verified, modifies the data according to the existing solution; The method of item 1, further comprising the step of sending the modified data to the device for injection into the device.
(Item 11)
3. The method of item 2, wherein the data transmission includes a plurality of types of confidential data, and the secure module obtains some of the types according to permissions established by the controller.
(Item 12)
The method according to item 11, wherein the log report includes an indication of which of the types is provided to the device by the secure module.
(Item 13)
The method of item 1, further comprising the step of the controller sending a configuration message to the secure module for use when modifying settings of the secure module.
(Item 14)
The method of item 1, wherein the log report is obtained by the controller using polling initiated by the server or the controller.
(Item 15)
The controller compares the first log record with the log report, and if the log report is appropriate and additional data is requested, the controller sends further data and the log report is appropriate. If not, the method according to item 4, wherein a command prohibiting further extraction of the data from any of the previous transmissions.
(Item 16)
The confidential data is a plurality of keys, and the transmission includes a large amount of the key encrypted by the secure module of the controller, and the step of extracting the data is performed in accordance with a command provided by the controller. 3. The method of item 2, comprising decrypting a special one of the keys as indicated.
(Item 17)
A system for remotely controlling the injection of sensitive data into a device during the production of the device,
A controller having a secure module for performing cryptographic operations;
A server located away from the controller and connected to the controller by a forward channel and a reverse channel, wherein the forward channel is configured to provide data transmission to a second secure module of the server. Used by the controller, the data transmission cryptographically protects the confidential data, and the second secure module extracts a server from the transmission;
A system that operates with a device used to inject the data when the data is extracted from the transmission and obtains the data from the second secure module.
(Item 18)
The system according to item 17, wherein the second secure module prepares a log report regarding the use of the confidential data, and provides the log report to the controller via the reverse channel.
(Item 19)
19. The system of item 18, wherein the controller constitutes itself and the server and further comprises a graphical user interface (GUI) for monitoring the log report.
(Item 20)
The first secure module includes an encryption key for encrypting a data key in the header of the data transmission, and the second secure module includes a decryption key for decrypting the data key, and the second secure module The system of item 17, wherein the module uses the data key to decrypt the transmission and extract the data from the transmission.
(Item 21)
The controller further comprises a first data storage device for storing the data stored in a secure manner before preparing the data transmission, the server before extracting the data from the transmission The system of item 18, further comprising a second data storage device for storing the data transmission.
(Item 22)
Upon sending the data transmission, the controller generates a first log record, stores the first log record in the first storage device for later comparison with the log report, and stores the data in the device. The second secure module generates a second log record indicating delivery of the data to the device and includes the second log record in the second storage device for inclusion in the log report. The system according to item 21 to be stored.
(Item 23)
The agent generates a third log record indicating the injection of the data into the device, and the agent sends the third log record to the second secure module for inclusion in the log report in item 22 The described system.
(Item 24)
The controller performs a supply procedure before preparing and protecting the data, wherein the supply procedure is used to initialize the server and the first and second secure modules. system.
(Item 25)
18. The system according to item 17, comprising a plurality of servers, wherein the controller sends the data transmission by sending the data transmission to the plurality of servers.
(Item 26)
A credit command indicating a credit value for updating a value of a credit pool generated by the controller and stored safely by the second secure module; and the controller sends the credit command to the second secure module. The system according to item 17, wherein the sent credit value represents the number of data elements of data transmission from which the second secure module can extract the confidential data.
(Item 27)
27. The system according to item 26, wherein when the data is extracted from the data transmission, the second secure module consumes credit from the credit pool, thereby reducing the value of the credit pool.
(Item 28)
The second secure module further comprises at least one signed object stored in the second storage device, the signed object signing an object for the controller to execute an existing data injection solution; Created by sending the signed object to the second secure module, the existing solution modifies the data, the second secure module validates the signed object, and the signed object validates 24. The system of item 21, wherein the system modifies the data according to the existing solution and sends the modified data to the device for injecting into the device.
(Item 29)
The data transmission is prepared by the first secure module including a plurality of different types of sensitive data, and the second secure module obtains some of the types according to the permissions established by the controller Item 19. The system according to Item 18.
(Item 30)
30. A system according to item 29, wherein the log report includes an indication indicating which of the types is provided to the device by the second secure module.
(Item 31)
The system according to item 17, which is used when the controller generates a configuration message, sends the configuration message to the secure module, and corrects the setting of the secure module.
(Item 32)
The system according to item 18, wherein the log report is obtained by the controller using polling initiated by the server or the controller.
(Item 33)
The controller compares the first log record and the log report, and if the log report is appropriate and additional data is requested by the agent, further data transmission is performed and the controller The system according to item 22, wherein if the log report is not appropriate, a command prohibiting further extraction of the data from any of the previous transmissions.
(Item 34)
The confidential data is a plurality of keys, and the transmission includes a large amount of the key encrypted by the first secure module, and a special one of the keys is a priori according to a command provided by the controller. The system according to item 18, wherein the system is decrypted by the second secure module, as indicated.
(Item 35)
When the second secure module receives the block of keys, it decrypts them and re-encrypts each key individually, and some of the keys are decrypted and sent to the device when requested by the agent. 35. System according to item 34 to be used.
(Item 36)
18. The system of item 17, wherein the first and second secure modules include symmetric keys for communicating via forward and reverse communication channels.
(Item 37)
A module for controlling the insertion of confidential data into a device in a plurality of stages, comprising: an encryption transform for intercepting and converting a data flow in the device; and an encryption key stored in a memory. Is added to the encryption key at each stage, activation of the encryption key is required for the operation of the encryption transform to be successful, and the device functions when the operation of the encryption transform is successful. Module that comes to be.
(Item 38)
A method for controlling the insertion of confidential data into a device comprising the step of including in the device a module having a cryptographic transform for intercepting and transforming the data flow in the device; Each adding a portion of the sensitive data to an encryption key stored in a memory within the module, wherein the operation of the encryption key is required for the operation of the encryption transform to be successful. And the device becomes functional upon successful operation of the cryptographic transform.

It is a schematic block diagram of a remote device registration system. 2 is a schematic representation of the graphical user interface (GUI) shown in FIG. It is a schematic representation of a delivery image. It is a flowchart which shows a key injection | pouring and a reporting procedure. It is a flowchart which shows a supply procedure. It is a flowchart which shows a credit instruction | command procedure. FIG. 6 illustrates a mapping scheme for another embodiment that supports multiple products. FIG. An example of a filtered log report is shown. FIG. 6 is a block diagram illustrating another embodiment of a remote device registration system. FIG. 6 is a schematic block diagram of an embodiment for key injection using multiple stages in the manufacturing process. FIG. 11 is a schematic representation of a mask incorporating a registration module for isolating the key injection stage using the embodiment of FIG. 11 is a schematic representation of the stages shown in the embodiment of FIG. FIG. 11 is a flowchart illustrating steps performed when producing an apparatus using the embodiment of FIG. It is a schematic block diagram of the example of a product produced from the mask shown by FIG.

Referring to FIG. 1, the entire remote device registration or trusted key injection system is indicated by reference numeral 10. The producer 12 of the device 22 uses the services of another entity, in this case an external manufacturer 14, to inject unique and unchanged information into the device 22. This information may be an encryption key, a shared secret, or other data that can be cryptographically tied to an inherently unique attribute of the device 22 and is hereinafter referred to as a “key”. Injecting this key into the device 22 is hereinafter referred to as “keying” or “key injection”.

The producer 12 utilizes a controller 16 which is a computer system remote from the manufacturer's equipment. The controller 16 includes a hardware security module (HSM) 11. The HSM 11 is a protected device used by the controller 16 to perform cryptographically secure operations such as encryption, decryption, or signature. The HSM 11 is resistant to tampering (eg, physically difficult to access) or can react to tampering (eg, erase data when tampered). The controller 16 is responsible for monitoring the delivery and use of keys by the manufacturer 14 and packaging and transporting keys and other information to the manufacturer 14. Producer 12 typically obtains a large number of keys (not shown) from an external source, such as an administrative agency that is the producer of HDCP keys, for example. The key is stored in the data storage device 15 until it is distributed to a special manufacturer 14. The controller 12 and its operation can be monitored and modified so that an operator can control it using a graphical user interface (GUI) 13. The GUI 13 is typically a software application that is displayed and interacts using a personal computer (not shown).

The controller 16 is connected via a pipeline 23 to a server 18 present at the manufacturer 14. Pipeline 23 includes two forward communication channels: a control channel 26, a distribution channel 25, and a reverse channel 24. The control channel 26 is used by the controller 16 to meter the number of keys available to the manufacturer 14 by sending a credit command. Distribution channel 25 is used by controller 16 to distribute a block of protected keys to manufacturer 14. The reverse channel 24 is used by the system 10 to inform the controller 16 of key usage for reporting and auditing purposes. Channels 24, 25, and 26 may be any communication channel and are not required to be reliable or secure. Reliability and safety for channels 24, 25, and 26 is provided using a combination of technical mechanisms and processes / procedures. For example, if a message sent to module 18 using forward channel 26 has been tampered with and cannot be decoded, the user can call the operator of system controller module 16 to send the message again.

The manufacturer 14 is local to the manufacturer's equipment, and its operation includes one or more servers 18, which are computer systems that are monitored and metered via messages sent from the controller 16. Use. Server 18 also sends a report back to controller 16 via reverse channel 24. Server 18 includes an HSM 28 similar to HSM 11 utilized by controller 16. The HSM 28 stores a protected credit pool 30 that determines how many keys the manufacturer 14 can use. Key usage is metered by the controller 16 by monitoring the data reported from the server 18 and adding or subtracting from the credit pool 30 accordingly. The credit pool 30 is an abstraction that represents the number of keys that can be decrypted by the HSM 28 before the server 18 has to request and obtain more keys from the controller 16. The controller 16 distributes the key to the server 18 via the distribution channel 25, and the server 18 stores the key in the local data store 17 as will be described in more detail below.

The manufacturer 14 utilizes one or more devices 20 that are used to inject the cryptographic key into the device 22. Typically, keying occurs during the testing phase of the manufacturing process, so equipment 20 is often a testing machine on the assembly line. The device 20 includes a key agent 21, which is typically a software program or toolkit loaded on the device 20 that is used to manage key injection on the application side. The key agent 21 communicates with the server 18 to request and obtain a key when it is needed. Typically, the server 18 provides sufficient keys to the key agent 21 so as not to interfere with the timing of the production process. However, server 18 does not provide an unnecessary number of keys to limit key usage until keying approval is provided by controller 16 as metered through credit pool 30.

Typically, the key agent 21 has a threshold level that indicates when a new bundle of keys is required by the special equipment 20 so as not to interfere with production. Since the controller 16 is typically not always in communication with the server 18, the controller 16 adjusts its parameters so that the device 20 can utilize sufficient keying material through the server 18. While ensuring that the controller 16 does not release too much key data before the controller 16 can obtain a key usage report from the server 18, as will be described in more detail below. Guarantee.

The key agent 21 preferably includes an application program interface (API) that is activated on the device 20 to allow the operator of the device itself to request keys in a manual or automated manner. The key agent 21 is used to provide a level of protection against data passing between the server 18 and the device, and is considered a simple secure socket layer (SSL) between the server 18 and the device. It will be appreciated that the key agent 21 can also be implemented using an SSL connection between itself and the server 18 if resources are available. The key agent 21 is also responsible for generating a report record when the key is used, and that record is sent back to the server 18 for reporting purposes.

The controller 16 is a command center for monitoring and metering key injections by the manufacturer 14. In order to control keying from a remote location, the GUI 13 is used by an operator to monitor and configure each of the manufacturer 14, server 18, and equipment 20 under the control of the controller 16. An exemplary GUI 13 is shown in FIG. The GUI 13 is divided into a server window 200, a controller window 204, and a device window 202. Server window 200 includes a list of manufacturers 14 and servers 18 controlled by controller 16. A special controller 16 is shown in the controller window 204. The operator can select a special manufacturer (e.g., manufacturer A shown in FIG. 2), and the device 20 associated with that manufacturer is displayed in the device window 202.

In the example shown in FIG. 2, the server at manufacturer A includes a window for providing information regarding server 1, server 2, and server 3. Each server has some data associated with it. For example, as shown in FIG. 2, each server has a progress bar that indicates their available storage space, available credits, and the number of keys available for each of Key Type 1 and Key Type 2. including. Each tester window also displays log information such as the date the last report was processed, the last reported credit, the last replenishment amount, and data about lost log records. The server window also provides the operator with options 214 and 216 to configure the server 18 remotely from the controller 16 and disable it.

The controller 16 has a function that allows the server 18 to be configured remotely. 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 to server HSM 28 via control channel 26. The HSM 28 can evaluate configuration messages so that some configuration messages modify the operation of the HSM 28 and other configuration messages are sent to the server 18. Using this method, configuration messages sent to the server 18 via the HSM 28 are used to help ensure that the server 18 obtains a configuration command that is known to be reliable and originated from the controller 16. it can.

The controller 16 can remotely configure the system 10 at the server level or device level via the key agent 21. The controller 16 can force the server 18 to poll and adjust the periodic polling interval. Typically, the server 18 is polled at fixed intervals, and the controller 16 can utilize forced polling to obtain information during those intervals, if necessary. For example, in the case of one day intervals, the controller 16 may need data for reporting to the administrator during the day. In that case, you can force polling of all servers to get such data. The GUI 13 can also include a controller email option so that the controller 16 can automatically contact the administrator in extreme situations, such as decryption or delivery failures in critical production operations.

Each key delivered to the server 18 and injected by the device 20 into the device 22 triggers a log record at an event. The GUI 13 can be used to search, categorize, compile, and analyze log records to examine custom or standard reports 400 as shown in FIG. In this example, there are three main log records generated. The key-to-server log 402 is generated when the key is delivered by the producer 16 to the server 18, and the key-to-agent log 404 is generated by the HSM 28 when it releases the key to the key agent 21. The key injection log 406 is generated by the key agent 21 at the time of key injection. Each log record can contain any number of identification information, including ID type, date stamp, manufacturer, equipment, etc. In the example report shown in FIG. 8, report 400 shows a key-to-server log 402, a key-to-agent log 404, and a key injection log 406 for a key with sequence ID = 001. Yes. These records can be used to track the life cycle of keys having such sequence ID numbers. It will be appreciated that the report 400 can include any number of records and can be filtered based on any suitable field. For example, a report 400 showing all keys injected by tester 2 at manufacturer A on May 3 can be compiled by filtering the date and location fields.

Referring now to FIG. 3, the producer 16 can package a large set of keys in a secure data transmission, preferably using encryption, using the distribution image 40. The distribution image 40 allows the producer to include keys for multiple products destined for multiple servers 18 in a single transmission. Each server 18 can then decrypt and obtain a certain number of keys after authentication by the HSM 28 from the controller 16 via the control channel 26. This image 40 is a collection of data records, each record including type 58, ID 60, size 54, and data 56 fields. Data 56 typically includes key data of any size identified by size 54. Type 58 and ID 60 fields are used by HSM 28 to identify key data that may be used to filter certain keys, depending on the configuration of HSM 28, as previously commanded through control channel 26. To do. Keys can be encapsulated so that you don't have to worry about what the keys actually look like to the target when you implement them. This gives the keys flexibility and extensibility without having to redesign each new key type. The wrapper should be abstract in its body and include type, size and unique ID. The wrapper can also include elements to support more advanced features such as logging into the abstract image or variable assignment.

The image 40 is encrypted with the 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 itself is encrypted for each server 18 and stored as a server header 48. A collection 44 of server headers 48 is stored in the main header 46. In order to decrypt the image 40 and obtain the key, the header 48 is selected by the server 18 and decrypted by the HSM 28 to obtain the image key 42. The image key 42 is used to decrypt the image 40.

As described above, the distribution image 40 can be used to support a plurality of products. Referring also to FIG. 7, the mapping of product types and data blocks is shown. For example, producer 16 has three products: gamma that utilizes key 1 (having filter tag 1), key 2 (having filter tag 2), and accompanying building blocks (also having filter tag 2). And beta using key 1, key 2, and alpha using building blocks. The image 40 can include a large amount of key type 1 and key type 2, and the gamma and beta products are not as complex as the alpha product. Producer 16 can package a single image 40 with, for example, 50 data for each block, so that one tester (eg, Tester 1) can obtain 50 product alphas with manufacturing permission. 50 filter tags 1 and 2 are obtained for production. Another tester (e.g., tester 2) can be authorized to manufacture at the same time, obtaining 50 filter tags 1 from images 40 to produce 50 product betas, 50 filter tags 2 to obtain products Can produce gamma. The image 40 can include multiple types of keys, can include all of the keying data, and can produce a single product of any product type. The tester identifies to the server 18 the type of product or product model being programmed. This model information is sent to the HSM 28 along with the encrypted image 40 so that when the HSM 28 decrypts the image 40, the key data 50 is filtered and needed to program the identified product model. Only the key data is released by the HSM 28 to the tester. Thus, the producer 12 can support multiple products with a single image 40, while the manufacturer 14 can take measures to ensure that only products that are considered to be manufactured can be manufactured.

Since image 40 can support multiple products, logging is used to track the actual key injection performed in the tester, which will be described in more detail below. By tracking the log records, producer 16 can, for example, have manufacturer 14 send product gamma instead of 50 product alpha (they are paid for the production of this product). , Thereby attempting to detect whether 50 product betas could be sold to the gray or black market. Whether such inconsistency is malicious or not, it can be reasonably identified anyway.

A typical life cycle of keys from delivery via delivery channel 25 to HSM 28 reporting to controller 16 via reverse channel 24 is shown in FIG. The blocks highlighted in FIG. 4 represent steps performed by the secure modules, ie HSM 11 and HSM 28. The controller 16 first obtains a large number of standard keys from an external supplier. The key is then passed to the HSM 11, which encrypts the block of keys, including a key type with a measured amount of each block. It will be appreciated that the key can be encrypted in large quantities into blocks having more than one key type. The controller 16 then stores the massively encrypted key in the storage device 15 until it receives an instruction or other command indicating delivery of a block of keys.

When the producer 16 delivers a block of keys, it first obtains a large amount of encrypted blocks and passes this block to the HSM 11. The HSM 11 decrypts this block and re-encrypts the key block for transmission with the image key 42. The image key 42 is itself encrypted for each server 18 to produce an individual header 48. These headers 48 are stored in a group 44 of main headers 46. At this point, the HSM 11 generates a key-to-server log 402 for the re-encrypted key for distribution. Log 402 is stored locally at producer 12 for later analysis. Then, the re-encryption key block is distributed to the server 18 via the distribution channel 25.

The server 18 passes the encryption key block included in the image 40 to the HSM 28, and the HSM 28 decrypts the image 40. The HSM 28 first selects the special header 48 from the group 44 and decrypts the image key 42. Then, the image key 42 is decrypted, and the key is acquired from the image 40. The image 40 is then preferably validated and filtered using, for example, a secure hash algorithm, MAC, or digital signature. The HSM 28 also re-encrypts each key obtained from the image 40 for storage. Server 18 stores the re-encryption key locally for later use by device 20. It will be appreciated that the validity of the image 40 is assumed based on the unique symmetric delivery keys K _s1 and K _s2 shared between the controller 16 and the server 18. Messages shared between them can be considered legitimate if the integrity check is performed successfully, eg, after a sha-2 digest comparison.

When the controller 16 receives a request for a certain number of keys (eg, N keys) from the device 20, the HSM 28 is given N keys for decryption. A key-to-agent log record 404 is then generated for each of the N keys decrypted by the HSM 28 and the key is passed to the device 20 for injection. At this point, the key is in the “clear state” and is ready for injection.

The device 20 injects each of the N keys, and the key agent 21 generates a key injection log record 406 for each injected key. The HSM 28 continuously obtains the key-to-agent log record 404 and the key injection log record 406 and preferably concatenates these records into a master log report R through the reverse channel 24. Send back to the controller 16.

Each log is preferably concatenated into a binary file that identifies the date that the file was generated. The report R is preferably encrypted by the HSM 28 using the encryption key K ₁ and returned to the application running on the server 18 and sent over the reverse channel 24. Then, the controller 16 can decrypt the report R, and can confirm the validity of each log (for example, 402, 404, 406). Each log is tagged with a monotonic synchronization number. If all the collected record ID values are not a continuous set of values, the operator of the controller 16 can know where to track unknown logs in the sequence.

As described above, the controller 16 previously has multiple key-to-server log records 402 for N keys when it was delivered. Thus, at some point in the future, the controller 16 receives a report R that completes the life cycle for each key indicating that the first delivered key has been decrypted and injected by the correct server 18 into the correct device. Expect. Controller 16 can thus evaluate the log report as it is provided. Then, the controller 16 can determine whether it is necessary to take action such as intervention in the manufacturing operation (for example, stop of distribution) and further providing a key. The controller 16 can also request further information before delivering further key blocks. In this way, the controller 16 can meter the delivery and can provide more keys only when the manufacturer is working faithfully and consistently providing accurate log records.

Logging (eg, as shown in FIG. 8) allows producers to locate discontinuities in the sequence of ID numbers. For example, if a large number of keys have been delivered but have not reported a key-to-agent log or key injection log, the manufacturer may have lost that key. This indicates the potential for gray or black market activity. In another situation, the report R may include a key to agent log 404 for a special key, but may not include a key injection log. This indicates that the problem may have occurred in the special equipment that requested the key, not the manufacturer 14 itself. Thus, the manufacturer 14 can use the log R to identify internal malicious behavior and maintain a relationship with the producer 12 for audit purposes. The life cycle of each key requires a report record at each critical stage where an operation is performed on the key. Thus, the producer 12 has the information necessary to identify where problems have occurred and to direct efforts to correct or eliminate such problems. Preferably, the log record includes information related to the key type as well as the sequence number for the key. In this way, the producer 12 can determine whether the alpha product has been commissioned since the gamma and beta products have been produced.

The log report provides information that provides a means to prevent malicious or ethical behavior by the manufacturer 14 and to assess the integrity of the existing manufacturer 14 and tools to provide evidence of any undesirable behavior. I will provide a. By using unequivocal evidence in detecting unwanted behavior, producer 12 can confront manufacturer 14 with greater confidence than suspicion, and forbidden behavior occurred at the tester level (E.g., if you are an employee, not the company itself) can restore important relationships between producer 12 and manufacturer 14.

In addition to delivery, controller 16 uses control channel 26 to control credit pool 30, thereby metering the key injection phase. The credit command procedure is shown in FIG. When the HSM 28 decrypts the distribution image 40 and obtains a key, the HSM 28 must consume credits from the credit pool 30. Over time, the credit pool 30 decreases and needs to be replenished with a credit command file sent from the controller 16.

The controller 16 sends only one control message C at a time via the control channel 26. One of the required files included in this message is preferably a credit command file. This file may be a set of encrypted data for the special server 18 and is decrypted by the HSM 28 into a credit command. The credit command includes, for example, the HSM 28 and / or server 18 serial number, server token ID, sequence number, new credit amount, and configuration data, all of which are signed by the controller 16.

When receiving the control message C, the HSM 28 decrypts the credit command data from the control message C and confirms the validity of the signature. HSM 28 also validates its own serial number and token ID if possible. Then, the validity of the sequence number is confirmed. The sequence number must be larger than the sequence stored inside the HSM 28. Once the validity is confirmed, the HSM 28 updates the internal sequence number and sets the value of the credit pool 30 to the credit value in the credit command.

The HSM 28 then processes any configuration message in the control message C and updates its internal configuration so that the controller 16 can update the filtering rules, keying information, credit rules, etc. in relation to the GUI 13 above. The configuration data described in (1) can be sent to the server 18. The configuration data may also be intended for the HSM 28, applications running on the server 18, or the key agent 21. HSM 28 looks for defined types of configuration messages and processes them. The configuration data can be marked as private or public, and access to it is controlled by the HSM 28.

The credit report Cr is a response to the credit command processing of the control message C. Credit report Cr is serial number and token ID of HSM28, current sequence value, current value of credit pool 30, replenishment count so far, and error set to zero if no error occurs during credit command processing Can contain code.

Credit report Cr is preferably, HSM28 is signed using the signature key k _2. And report Cr is encrypted to the controller 16 using the public encryption key k ₃ of the controller. The report Cr is then sent to the controller 16 and stored with the log report R for audit purposes described above.

Prior to key distribution, producer 12 and manufacturer 14 can experience a supply procedure for initializing HSM and server 18. The supply procedure is shown in FIG. The HSM 28 generates a supply request message P and sends it to the controller 16. This message P preferably includes the serial number of the HSM 28 being used by the server 18. HSM 28 generates _two encryption key pairs k ₁ , k ₂ (eg, using an RSA key pair, or preferably elliptic curve cryptography (ECC)), one (k ₁ ) is an encrypted message. The other one (k ₂ ) is for signing the message to be sent. Preferably, manufacturer 14 is cryptographically bootstrapped into a physically controlled environment during this exchange of key pairs k ₁ and k ₂ .

When the controller 16 receives a supply request from the server 18, it passes the request to the HSM 11, which checks the integrity of the message and assigns a “token ID” to the manufacturer 14. Two keys are generated, preferably symmetric keys k _s1 and k _s2 (eg AES (Advanced Encryption Standard) key). These keys are 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 reverse channel 24 as described above.

The HSM 11 then, for example, is assigned token ID, HSM cipher public key and signature key pair k ₃ and k ₁ respectively, distribution and reverse channel symmetric keys k _s1 and k _s2 , some initial configuration data, and integrity. A supply response message P ′ including a hash digest for is generated. Similar to the supply request message P, the supply response message P ′ is handled in a physically controlled environment (eg, using HSM protection).

Then, the supply response message P 'is sent to the server 18, and the server 18 can execute the initialization operation when receiving the first supply request. The feed response structure can include members that decrypt into a separate structure that includes a symmetric key for forward and reverse channel communication between the controller 16 and the server 18. These keys are distinct for each HSM 28 (and each server 18) and are not shared between groups of HSMs. Once the supply procedure is complete, a normal exchange of delivery image 40 and control message C can begin.

In another embodiment shown in FIG. 9, the system 10 can be retrofitted to an existing solution implemented by the manufacturer 14 to protect the key injection phase. In the embodiment shown in FIG. 9, the same components are suffixed with the same reference number “a”. For example, the manufacturer 14 may have a device 20a that already includes a scrambler 74 that converts the string “BCA” to “ABC”, and the device 22 is connected to accept ABC as an injected key. ing. Thus, if the key “BCA” is stolen or placed in a different location, scrambling will not occur and will not work for the device 22a. These attempts to protect the keys are easy to implement, but are typically simple and do not provide an appropriate level of protection. By incorporating such a protection mechanism, the system 10 can be retrofitted to the device 20a without reverting existing solutions that have already been implemented. Thus, additional costs to the manufacturer 14 due to the implementation of the system 10 can be avoided. The retrofit can be implemented until a complete redesign is guaranteed, where the arrangement shown in FIG. 1 can be used.

To capture an existing solution, the system 10 is a collection of executable files associated with a special device 20a at the server 18, after the HSM 28 releases the key and before the key injection. A set 72 of signed objects to be executed is stored. In this way, the key is changed to capture the existing solution without being known to the device 20a. As shown in FIG. 9, the controller 16 first needs to access an executable file (exe) that is used by the device 20a to provide an existing solution. Then, the controller 16a passes the exe 70 to the HSM 11a. The HSM 11a signs the exe 70 and passes the signed exe 70 to the HSM 28a. The HSM 28a stores the signed exe 70 as the signed object 72. In operation, when the device 20a requests a new bundle of keys, the server 18a verifies the validity of the exe against the signature of the exe stored in the HSM 28a. Once the server 18a confirms the validity of the exe 72, it sends the exe key for scrambling.

For example, device 20a supplies key BCA to scrambler 76 of device 22a to request that key ABC be injected into product alpha. The HSM 28a determines that the product alpha has a signed object exeA for modifying the key ABC. The signed object exe A is verified and applied to the key ABC, resulting in a scrambled key BCA. The scrambled key BCA is then sent to the device 20a, and the scrambler 76 modifies the key BCA so that it injects the key ABC. The device 20a does not recognize that the key BCA (received) is stored by the server 18a in a protected form ABC. It will be appreciated that the key stored by server 18a may be in a CAB-like format, modified to be read as BCA for scrambling, and converted to ABC for injection. . Such happens when the key CAB is a standard format and the CAB must be modified to fit into an existing solution that is not acceptable as a key. Accordingly, the signed object 72 includes any program required to capture an existing solution implemented by the device 20a, and the above example is for illustrative purposes only.

The signed object 72 is loaded and injected into the server 18a because the signed executable is typically verified against the key that is released to the machine before it is applied to the key. It also prevents the key from being modified before. The system 10 can thus provide an increased level of security while incorporating existing solutions.

Thus, by utilizing the remote system controller 16 that is separate from the server 18, the producer 12 can monitor the behavior of the manufacturer 14 and can credit the HSM 28. The producer 16 can thus manage to inject keying information into the device 22 and can ensure that the manufacturer 14 correctly reports the identity and the number of units produced to the producer 12. This allows producer 12 to have a guarantee that manufacturer 14 has not created and distributed a gray or black market product or device 22.

With the above procedure and properly positioned system 10, producer 12 can monitor production at manufacturer 14. Producer 12 can use the credit command in control message C to meter the manufacture of device 22 by adding or removing credits that can be used by manufacturer 14.

It will be appreciated that the system 10 is not limited to a single manufacturer 14 as shown in FIG. 1 and that each manufacturer 14 is not limited to a set of equipment 20. I will. System 10 is not limited to the use of a single controller 16. The HSM 28 is the most preferred reliable hardware for protecting the key value and the integrity of the credit pool 30. Furthermore, the keying information included in the distribution image 40 is not necessarily keying information, and may be any data element that requires confidentiality and authentication. The keying data requirement is typical for systems 10 that desire to reinforce the accuracy of device activation.

In the alternative mechanism illustrated in FIGS. 10-14 and described in more detail below, overproduction can be prevented by introducing separation of duties within the silicon or device manufacturing process. Typically, producer 12 outsources various stages of manufacturing to multiple subscribers. In general, the separation of responsibilities relates to the intentional separation of the manufacturing stage for silicon chips or other equipment, whereby the final product must be “contacted” by each subcontractor, This ensures that the final product is fully functional. Because gray markets are typically supplied from a single default in the manufacturing chain or by a single betrayal contractor, it is important to force multiple contractors to work sequentially. This means that two or more subcontractors must conspire to the producer 12 to supply normal subcomponents or equipment. The final product and its subcomponents must complete all manufacturing steps in order to be fully functional. In general, the risk of attack on producer 12 is greatly reduced when multiple subcontractors are required to conspire for theft.

In the production of silicon wafers, there are typically several stages that are often divided into several third party manufacturers. The producer 12 that designs the chip creates the design in a data file or data files, often referred to as a “netlist”. The netlist includes a description language in the form of computer code that instructs the third party how to produce a mask and, consequently, a silicon wafer from which the IC is packaged and delivered.

For example, in an exemplary manufacturing process, a mask is sent from producer 12 to a silicon producer, who produces a silicon wafer from the mask. Wafers are sent to a wafer testing facility where individual chips are tested directly on the wafer, electronically scored, and cut, so only those individual chips that pass are transferred to the packaging facility. The The packaging facility combines silicon and packages it into a chip package, and again tests the final packaged chip. The finished chip is typically sent to an OEM where the chip is mounted on a printed circuit board that is part of the finished equipment product, and the finished equipment product is sent to a distribution channel and ultimately the customer. Sent to.

The manufacturing process illustrated above generally includes multiple stages, which are the stages that occur during the design and integration of the silicon chip into the device, ie, production, testing, packaging, and installation. . It will be appreciated that all of these stages occur in a single facility and there may be more stages, up to any number N stages. In each of these stages, there is an opportunity for overproduction and yield reduction.

Referring now to FIG. 10, the producer 12 designs a mask 90. The mask 90 is used to produce a registered device 22, in this example an IC. Device 22 includes some form of sensitive or invariant information included in its design and preferably cannot operate without such sensitive information. Producer 12 in this example contracts with two or more third-party manufacturing entities that perform special steps in the overall manufacturing of device 22. FIG. 10 shows a first manufacturing stage 100, a second manufacturing stage 102, and an optional Nth manufacturing stage 104.

The producer 12 distributes the mask 90 via the product distribution channel 80. The mask 90 is sent to the first manufacturing stage 100 where a part of the manufacturing is performed, such as the production of a silicon wafer. When the first stage 100 is completed, the resulting partially completed product is sent to a second manufacturing stage 102 where a second part of manufacturing, such as wafer testing, is performed. This is repeated at each stage up to the Nth stage, and finally the fully functional registered device 22 is shipped to the delivery entity 106.

In order to prevent incomplete products or subcomponents from being diverted to the gray market 110 in one of the manufacturing entities 100-104, “separation of duties” is applied. Separation of responsibilities is to divide the manufacturing and data programming responsibilities at each manufacturing stage, so that all responsibilities were intended, in the intended order required to complete a normal equipment product. Must be executed by the contractor. In this example, confidential work such as injection of cryptographic data is performed in multiple stages, each stage being performed in a separate manufacturing stage by a separate manufacturing entity. To separate confidential work, producer 12 incorporates registration module 92 into the design defined in mask 90. When the mask 90 is compiled to produce the device 22, the module 92 intercepts important signals and data flows in the silicon chip, such as the boot signal, by mathematical transformations, and the mathematical transformations are activated. If this is not possible, the device 22 is used in an abnormal manner. The mathematical transformation is preferably a cryptographic transformation that makes extensive use of exclusive OR (XOR) operations for performance reasons, but this is not a requirement. In order to enable the mathematical transformation to work, it is registered at each stage of the manufacturing process by adding or adding incremental data, such as cryptographic keying data parts, in stages. In this way, if the wafer produced in the first stage 100 is over-produced and supplied to the gray market stage 2 via N110 as shown in FIG. 10, the product 112 is typically It is not normal because it has not received all of the cryptographic data necessary for it to work properly.

Preferably, as shown by way of example in FIG. 10, the key injection system 10 shown in FIGS. 1-9 above is required to request delivery, metering, and key injection phase reporting at each manufacturing step. Can be used for In this case, even if all entities conspire to deliver the gray market product, producer 12 can detect this behavior with an incomplete log report and, if necessary, prevent further keying data delivery. . Alternatively, it will be appreciated that the system 10 need not be used at each stage, or need not be used at any stage, and can be used in any number of stages. For example, the second stage 102 utilizes the system 10, but other stages may not be used. However, as each manufacturing stage preferably includes some form of testing procedure, it is useful to incorporate the system 10 into such testing. In this situation, the producer 12 at least predicts data during the second phase. It will be appreciated that the module 92 can be used to implement part of the keying process depending on each manufacturing step, without depending on the system 10. In either of these situations, by dividing responsibility, no entity can successfully supply the gray market with a product or sub-component, having the necessary information on its own.

The mask 90 is shown in more detail in FIG. As discussed above, the registration module 92 can be incorporated into any mask design, and the mask 90 is programmed to execute a set of instructions or code lines, and in part, a portion of the customer code 120; Insert the content defined in module 92 in the path (preferably important for the operation of the device) into one between the different parts of customer code 122. Data input to module 92 via path 124 is applied to cryptographic transform 128 and output to customer code portion 122 via path 126. The output present in path 126 is preferably usable only if the cryptographic transform 128 is successfully applied to the data input in path 124. Cryptographic transform 128 preferably functions with memory 130, processor 132, and cryptographic key 134 to perform its operations. The memory 130, processor 132, and cryptographic key 134 are preferably configured using the key injection system 10 present at each manufacturing stage. The memory 130 also includes another cryptographic key 131, which typically includes keying material accumulated at each stage, preferably via injection using the key injection system 10 as shown in FIG. Preferably, key 134 is used at the time of injection to ensure that the material making up key 131 accumulated in memory 130 is legitimate. Key 134 may be a public key or may or may not be necessary. For example, the module 92 can function without the key 134, but with the potential risk of a class of attacks that are appropriate or inappropriate for the particular producer 12.

Generally, the confidential data used by the module 92 is divided into a plurality of parts, each part being added to the key 131 at each stage of the manufacturing process. For example, one technique is to inject a digital signature with message recovery at each stage in the manufacturing process. The key 134 can be used to confirm the validity of the digital signature. When the key 134 is used, the digital signature whose validity is confirmed is a key derivation method in which the encryption key 131 is derived from the existing data in the memory 130. Generate a usable message. Another example is employing key shadowing techniques, where individual portions of the cryptographic key 131 are added to the memory 130 at various manufacturing stages. When the final manufacturing phase is complete, the memory 130 contains sufficient data so that the key shadow technique can be used to reconstruct the encryption key 131.

An example of the first manufacturing stage 100 is shown schematically in FIG. As indicated above, producer 12 preferably utilizes system 10 for the distribution of keying data and monitoring of reports generated when keying occurs. Key implantation into silicon chips typically occurs during wafer testing or later package testing. In this example, stage 100 includes a server 18 and a key agent 21 that operate with the testing device 20. Stage 100 also includes production equipment 139 for producing silicon wafers, for example. The production equipment 139 produces a partially manufactured device ₁ 140 using the mask 90 delivered via the channel 80. The subscript “1” in this example is used to represent the first part of the sensitive data applied to the device 22, where preferably the first part of the sensitive data is the key agent 21 of the device 20. Is injected using. Preferably, at this point, the device ₁ is not yet fully functional because the transform 128 does not have all the data necessary to perform the operation. The device ₁ can then be delivered to the second manufacturing stage 102.

FIG. 13 provides a flowchart illustrating an example manufacturing process that includes two distinct manufacturing stages (ie, N = 2). In step 500, the producer 12 determines the number of stages, thereby determining the number of portions of keying data to be injected, in this example N = 2. In step 502, producer 12 preferably establishes key injection system 10 that couples each manufacturing stage to itself via channels 24, 25, and 26. As discussed above with reference to FIG. 1, the producer 12 communicates with multiple servers 18 using a single controller 16. In this example, producer 12 distributes, monitors, and receives log records from two servers 18.

In step 504, producer 12 incorporates registration module 92 into its design defined by mask 90. The mask 90 is delivered to the first manufacturer 100 to perform stage 1 of the manufacturing process at step 506, which is performed at step 508. For example, the first manufacturer produces a wafer and creates a chip that fits the mask 90. During the wafer test, the manufacturer then programs some partial keying material into the memory 139. This portion of the sensitive data is inserted at step 510 and server 18 preferably reports to the producer at step 512 using the mechanism outlined above. Alternatively, stage 1 does not handle any confidential data injection, and this operation can be performed only in stage 2.

Once the first part of the keying data is programmed into the chip or device, the product will contain only partial keying information and not enough to operate properly. FIG. 13 is represented by the device ₁ , where the subscript number 1 represents the first part as described above. The partially produced and partially programmed device ₁ is delivered to stage 2 at step 514 and executed at step 516. The manufacturer 102 then injects a second portion of key data at step 518. For example, at step 518, the second manufacturer 102 can program additional keying information, or the partial key data stored in memory 130 during step 510 and the new from system 10 used at step 518. Encryption keying information can be derived using key data. This derivation step can be based on hashing or possibly more advanced key shadowing techniques. Preferably, at step 520, the second manufacturer 102 reports back to the producer 12 that the second key portion has been successfully injected. At this stage, the producer 12 has two log records indicating that the key data has been successfully inserted, and this information can be used to monitor the record.

When the second portion of the keying data is inserted, device 22, in this example, is completely produced, is fully registered (e.g., tested, packaged IC), the device ₁₂ in FIG. 13 Where subscript 12 represents a complete set of key data, ie, data portion 1 and data portion 2. The device ₁₂ continues to the delivery channel in step 522 and finally reaches the customer as a functioning product in step 524.

As also shown in FIG. 13, for example, if first manufacturer 100 or its employees attempt to deliver a gray market product at step 526 via an alternative delivery channel at step 528, device ₁ Contains only the first part of its key data, so the transform 128 cannot perform the operation, so an incorrect product will be provided to the customer at step 530. Therefore, even if testing, packaging, etc. are performed in the gray market stage 2, no additional keying data is provided, so the product 530 is fully manufactured, but not fully registered. Therefore, the product is not normal. It will be appreciated that module 92 is preferably implemented such that anti-tampering means are considered and implemented.

Referring now to FIG. 14, there is shown a schematic example of a completed customer product 22a that incorporates a module 92a, where the module 92a logically maps the physical layout for the module 92 shown in FIG. It is specified in In FIG. 14, for the sake of clarity, similar reference numbers are given the subscript “a”. A product 22a using an implementation of module 92 (eg, 92a) may apply cryptographic transform 128a, which is part of enforcement block 150, to the product's critical data path between codes 120a and 122a. it can. The path is decrypted via transform 128a so that customer logic 122a functions properly. In this example, verification 132a, which is an implementation of processor 132, is performed. Verification 132a uses a one-time programmable (OTP) memory 130a and an identity portion 134a that is an implementation of key 134 of FIG. For example, confidential data is injected into the key 134a and the memory 130a using the procedure outlined in FIG. Product 22a is just one implementation that incorporates the logic provided by module 92 (eg, module 92a), and the example shown in FIG. 14 is for illustrative purposes only. It will be understood.

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

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

Claims (32)

A method for controlling the insertion of confidential data into a plurality of devices, comprising:
The method
Positioning the controller so that it can be communicatively connected to a server, the server being located remotely from the controller and capable of communicating with equipment responsible for injecting the sensitive data into the plurality of devices And the controller is configured to deliver the sensitive data to the server and to allow the server to provide the sensitive data to the device. The controller comprises a secure module for performing cryptographic operations;
The controller uses the secure module to cryptographically protect the sensitive data;
The controller sends a cryptographically protected data transmission including the confidential data to the server, whereby the server extracts the confidential data from the data transmission;
The controller provides a credit value to the server, the credit value indicating a number of times sensitive data is inserted before requesting further sensitive data from the controller; Enabling the server to update the credit value according to the amount of the sensitive data provided to
The controller receives a device log from the server, the device log being a certain amount by the device when the device obtains a certain amount of sensitive data from the server when a request occurs; Inserting the confidential data into each device, wherein the device log is obtained from the device by the server; and
Including a method. The method of claim 1, further comprising: receiving a request from the server for additional sensitive data; and providing the additional sensitive data and a new credit value to the server. The method of claim 1, further comprising receiving a server log report, wherein the server log report is provided by the server and indicates receipt of the sensitive data from the controller. The secure module encrypts a header included in the data transmission to protect the key, and the key enables the server to decrypt the transmission and extract the sensitive data from the transmission The method of claim 1. The method of claim 1, further comprising initiating a provisioning procedure that is performed prior to sending the confidential data to the server, wherein the provisioning procedure is used to initialize the server and the secure module. the method of. The method of claim 1, comprising sending the data transmission to a plurality of servers. The method of claim 1, further comprising the controller sending a credit command to the server, wherein the credit command indicates an update to the credit value. The controller further includes sending an object to implement an existing data injection solution to the server, wherein the existing solution modifies the data and the object is signed for provision to a secure module. The server according to claim 1, wherein the server stores the signed object, verifies the signed object, and modifies the sensitive data according to the existing solution if the signed object is verified. Method. The data transmission includes a plurality of types of sensitive data, and the method further includes the secure module sending some of the plurality of types according to permissions established by the controller. The method of claim 3. The method of claim 9, wherein the server log report includes an indication indicating which of the plurality of types was provided to the device by the secure module. The method of claim 1, further comprising the controller sending a configuration message to the server for use at the server to modify settings in a secure module. The method of claim 3, wherein the device log report and the server log report are received by the controller in response to polling initiated by one of the server and the controller. The equipment log report and the server log report are received by the controller to obtain additional sensitive data, and further data transmission is preferred for the log report and additional sensitive data is required. The controller sends to the server an instruction to suppress further extraction of the data from any previous transmission, if the log report is not suitable. The method described. The sensitive data includes a plurality of keys, and the data transmission includes a large number of the keys encrypted by the secure module, thereby indicating the server a priori by a command provided by the controller. The method of claim 1, enabling one or more of the keys to be decrypted. The secure module encrypts the large number of keys, allowing the server to re-encrypt each key individually, and some of the keys are requested by the device. The method of claim 14, wherein the method is decrypted for use by the device when disconnected. The secure module includes a symmetric key for communicating via a forward communication channel between the server and the controller and a reverse communication channel between the server and the controller. Method. A system for controlling the insertion of confidential data into multiple devices,
The system
A controller device communicably connectable to a server, wherein the server is communicably connectable to a device located remotely from the controller and responsible for injecting the sensitive data into the plurality of devices The controller device is configured to deliver the confidential data to the server, and to allow the server to provide the confidential data to the device, the controller device comprising: With a secure module that performs cryptographic operations,
The controller device includes:
Using the secure module to cryptographically protect the sensitive data;
Sending the server a cryptographically protected data transmission that includes the sensitive data, so that the server extracts the sensitive data from the data transmission;
Providing a credit value to the server, the credit value indicating the number of times sensitive data is inserted before requesting further sensitive data from the controller and provided to the device Allowing the server to update the credit value according to the amount of the sensitive data;
Receiving a device log from the server, wherein the device log obtains a certain amount of the sensitive data by the device when a request occurs, and when the device obtains a certain amount of the sensitive data by each device. The device log is obtained from the device by the server; and
Configured to do the system. The controller device is further configured to receive a request from the server for additional sensitive data and to provide the additional sensitive data and a new credit value to the server. 18. The system according to 17. The system of claim 17, wherein the controller device is further configured to receive a server log report, the server log report being provided by the server and indicating receipt of the sensitive data from the controller. The secure module encrypts a header included in the data transmission to protect the key, and the key enables the server to decrypt the transmission and extract the sensitive data from the transmission The system of claim 17. The controller device is further configured to initiate a provisioning procedure that is performed prior to sending the confidential data to the server, the provisioning procedure being used to initialize the server and the secure module. The system of claim 17. The system of claim 17, wherein the controller device is further configured to send the data transmission to a plurality of servers. The system of claim 17, wherein the controller device is further configured to send a credit command to the server, the credit command indicating an update to the credit value. The controller device is further configured to send an object to implement an existing data injection solution to the server, the existing solution modifies the data, and the object is signed to be provided to a secure module. 18. The server of claim 17, wherein the server stores the signed object, verifies the signed object, and modifies the sensitive data according to the existing solution if the signed object is verified. The described system. The data transmission includes a plurality of types of sensitive data, and the controller device is further configured to send some of the plurality of types according to permissions established by the controller. Item 20. The system according to Item 19. 26. The system of claim 25, wherein the server log report includes an indication that which of the plurality of types is provided to the device by the secure module. The system of claim 17, wherein the controller device is further configured to send a configuration message to the server that is used when modifying settings in a secure module at the server. The system of claim 19, wherein the equipment log report and the server log report are received by the controller device in response to polling initiated by one of the server and the controller. The equipment log report and the server log report are received by the controller to obtain additional sensitive data, and further data transmission is preferred for the log report and additional sensitive data is required. The controller sends to the server an instruction to suppress further extraction of the data from any previous transmissions, if the log report is not suitable. The described system. The sensitive data includes a plurality of keys, and the data transmission includes a large number of the keys encrypted by the secure module, thereby indicating the server a priori by a command provided by the controller. 18. The system of claim 17, enabling one or more of the keys to be decrypted. The secure module encrypts the large number of keys, allowing the server to re-encrypt each key individually, and some of the keys are requested by the device. 32. The system of claim 30, wherein the system is decrypted for use by the device when disconnected. 18. The secure module of claim 17, wherein the secure module includes a symmetric key for communicating via a forward communication channel between the server and the controller and a reverse communication channel between the server and the controller. system.

Images