CA2611818C - System and method for remote device registration - Google Patents
System and method for remote device registration Download PDFInfo
- Publication number
- CA2611818C CA2611818C CA2611818A CA2611818A CA2611818C CA 2611818 C CA2611818 C CA 2611818C CA 2611818 A CA2611818 A CA 2611818A CA 2611818 A CA2611818 A CA 2611818A CA 2611818 C CA2611818 C CA 2611818C
- Authority
- CA
- Canada
- Prior art keywords
- server
- sensitive data
- controller
- equipment
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
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
2
3
4 FIELD OF THE INVENTION:
6 [00011 The present invention relates generally to the manufacture of devices having 7 sensitive data therein, and particularly to remotely controlling and monitoring the injection of 8 such sensitive data into such devices.
DESCRIPTION OF THE PRIOR ART
12 [0002] A device that participates in a cryptographically secure communication system, 13 will typically have some type of unique and immutable information that was injected into the 14 device at the time of manufacturing. This information could be a cryptographic key, a shared secret or some other data that may be cryptographically bound to an inherently unique 16 attribute of the device. Such information may be generally referred to as a "key", and the 17 injection of information may be generally referred to as "keying" the device or "key 18 injection".
19 100031 The purpose of injecting the keys is to ensure that the device is accepted as an authentic participant of a secured communication system at some point in the future, after the 21 device has been distributed. However, the producer of the device will often wish to ensure 22 that devices are manufactured legitimately and thus wishes to protect the keys that are 23 injected into the devices. The producer will typically aim to protect the keys in order to 24 protect future revenue, since authentication of the kevs may be used to provide conditional access to the secure system and its content etc. The injected key is also important as it 26 enables a customer or user of the device to avoid tedious procedures required to register the 27 device.
28 100041 The device may be granted such conditional access to the system based on 29 cryptographic authentication that the key is trusted. This trust is based on the fact that it is exceptionally difficult to reproduce the trusted data outside of the manufacturing process.
31 S_ystems that provide conditional access include, e.g., satellite television and radio, those 32 systems that continuously broadcast information but wish to control access to their content 21534179.1
6 [00011 The present invention relates generally to the manufacture of devices having 7 sensitive data therein, and particularly to remotely controlling and monitoring the injection of 8 such sensitive data into such devices.
DESCRIPTION OF THE PRIOR ART
12 [0002] A device that participates in a cryptographically secure communication system, 13 will typically have some type of unique and immutable information that was injected into the 14 device at the time of manufacturing. This information could be a cryptographic key, a shared secret or some other data that may be cryptographically bound to an inherently unique 16 attribute of the device. Such information may be generally referred to as a "key", and the 17 injection of information may be generally referred to as "keying" the device or "key 18 injection".
19 100031 The purpose of injecting the keys is to ensure that the device is accepted as an authentic participant of a secured communication system at some point in the future, after the 21 device has been distributed. However, the producer of the device will often wish to ensure 22 that devices are manufactured legitimately and thus wishes to protect the keys that are 23 injected into the devices. The producer will typically aim to protect the keys in order to 24 protect future revenue, since authentication of the kevs may be used to provide conditional access to the secure system and its content etc. The injected key is also important as it 26 enables a customer or user of the device to avoid tedious procedures required to register the 27 device.
28 100041 The device may be granted such conditional access to the system based on 29 cryptographic authentication that the key is trusted. This trust is based on the fact that it is exceptionally difficult to reproduce the trusted data outside of the manufacturing process.
31 S_ystems that provide conditional access include, e.g., satellite television and radio, those 32 systems that continuously broadcast information but wish to control access to their content 21534179.1
5 PCT/CA2006/000944 1 and thus revenue for providing such content. These systems rely on the manufacturing 2 process and the Original Equipment Manufacturer (OEM), in particular, key injection, to 3 provide a root of trust for the devices, and ultimately for the entire secure communication 4 system.
[00051 Keys that are injected into the devices are sometimes of a standard format and
[00051 Keys that are injected into the devices are sometimes of a standard format and
6 purchased from a governing body, for example, High Definition Content Protection (HDCP)
7 keys, which are used to protect data as it is sent over a cable from your PC
to your monitor
to your monitor
8 among other things. The governing body thus also has an interest in ensuring that the keys
9 distributed to the device's producer are protected and not lost. This creates a liability for the producer, thus increasing the importance for protecting the injected keys. In some cases, the 11 producer can be fined for losing or copying keys and if they acquire a reputation for 12 negligence when handling keys, the governing body may restrict or severe the distribution of 13 the keys. Maintaining this relationship is often important to the producer, especially when 14 the keys are of a standard format needed for the device to be compatible with other devices and/or infrastructure. In this case, without being able to use a particular key, the device will 16 not work as intended.
17 100061 In a modem business climate comprising ever-increasing device complexity and 18 sophistication, it is common for individual parts to be manufactured and keyed by one 19 manufacturer for later assembly by another manufacturer. In such a situation there exists certain security implications when the producer of the device or the owner of the 21 communication svstem is not the device manufacturer. It can therefore be paramount for a 22 device producer to ensure the integrity of the manufacturing systems that are responsible for 23 the integrity of the producer's device.
24 [0007] When considering the integrity of the manufacturing process, of particular concern are issues related to the confidentiality of secret information that is used to 26 manufacture the device, as well as ensuring that the manufacturer correctly reports the 27 identities and the number of units manufactured to the producer. Ideally, the producer of the 28 device should try to obtain assurances that a manufacturer is not creating and distributing 29 "grey" or "black" market parts or devices. For example, a manufacturer that ships a certain number of keyed products back to the producer, but still has leftover keys, may then 31 manufacture and sell devices with those extra keys. The producer has thus lost revenue since 21534179.1 1 the manufacturer is the one who profits from the sale. Other actions such as cloning or theft 2 of keys may also arise, which is difficult to detect and control when the keying process is 3 outsourced. In some cases, keys could be published on the Internet to enable users to gain 4 access to a conditional access system without paying for such a service.
[0008] Traditionally, a producer that is concerned about securing the information 6 injection stage at a manufacturing site has little choice but to implicitly trust that a 7 manufacturer is operating in a manner that gives due consideration to the producer's device 8 and system security. Protective mechanisms are generally naive, in that keying information is 9 typically bulk encrypted and sent to the manufacturer, where, upon arrival, all of the keying information is decrypted at once, and the manufacturer is then trusted not to compromise the 11 bulk of information.
12 [0009] One method to restrict access to keying information is to use an on-line client-13 server mechanism. With such a mechanism in place, the client at the manufacturer's facility 14 would be connected to a network, and would make requests for keying information on a per-device basis, to a remote key-providing server under the control of the producer.
16 [0010] There are a number of problems with implementing a manufacturing system that 17 relies on an off-site, remotel_v networked server, that provides keying information on such a 18 just-in-time basis. The foremost problem is that an off-site server can not guarantee a 19 minimal service level or response time to the manufacturing line if it uses a public shared packet-switched network. To prevent problems in the manufacturing line, a certain level of 21 service in terms of latency and through-put is optimal. Given modem manufacturing 22 realities, where production lines exist in remote jurisdictions relative to the producer, such 23 guaranteed network availability can be prohibitively expensive.
24 [0011] A manufacturing facility will typically not begin a production run without all of the necessary materials on hand, including data materials. Otherwise, the risk to production 26 line delays would be too high. Any keying system used by a manufacturer, should be able to 27 substantially guarantee service availability and provide a suitable response. This requires 28 local availability of all data resources and keying information before commencement of a 29 production run.
21534179.1 1 [0012] Given that all data resources must be locally available to a production line, 2 possibly existing on computer systems, and media that is not under direct control of the 3 producer; the producer must consider how to ensure the confidentiality of any secret keying 4 information.
100131 Enough data should be locally available to the manufacturer, in order to 6 commence and complete a production run. In the event that the producer discovers 7 unauthorised and contractually objectionable behaviour by the manufacturer, the producer 8 should also consider how to prevent such a rogue manufacturer from producing grey or black 9 market product, after the termination of a contract.
100141 Another problem related to cloning stems from overproduction, a specific type of 11 cloning operation, which is of particular concern to producers of silicon chips.
12 Overproduction can occur when the producer of an integrated circuit (IC) outsources 13 manufacturing of their IC designs to one or more third party manufacturing companies. The 14 purpose of outsourcing certain or all manufacturing steps is to lower production costs by selecting a third party that can offer the best price for performing a particular stage in the 16 manufacturing process. For example, a fabless design house (e.g. a producer) may wish to 17 contract overseas manufacturing facilities to build chips that they have designed. Such 18 overseas manufacturing facilities are often chosen as they are able to produce electronic 19 components relatively inexpensively.
100151 However, outsourcing generally increases the risk that a particular contractor may 21 overproduce product, that they have been contracted to build, in order to supply a grey 22 market. For example, if the contracted manufacturer acts in bad faith and over produces ICs 23 from the design provided by the producer, but does not inform the producer that such 24 overproduction occurs, the extra product is available to be sold in a grey market channel as "counterfeit" or "cloned" ICs. This allows the third party manufacturers to realize extra 26 revenues and earnings at the expense of future product demand and revenues for their 27 customer, namely the producer/designer.
28 [0016] The above may occur because, in such scenarios, often the producer does not ever 29 handle the product aside from receiving engineering samples at the beginning of the production phase. Accordingly, at each stage of the manufacturing process, subsequent to 21534179.1 1 design, there is an opportunit_y to steal parts and product. In some cases, employees of a good 2 faith contract manufacturer may be thieves. "Yield shrinkage" may occur, where an 3 employee steals product right off of the manufacturing line. This can be detrimental to not 4 only the producer and contract manufacturer, due to lost revenue, but also to the relationship between the producer and the manufacturer for conducting future business.
6 [0017] It is therefore an object of the present invention, to obviate or mitigate the above-7 described disadvantages.
9 [0018] The present invention provides a system and method that enables a producer who wishes to use a separate entity for at least a portion of the manufacturing process, to monitor 11 and protect production of devices from a remote location.
12 [0019] The present invention also provides a means for separating the addition of 13 sensitive data to a product between separate entities for inhibiting grey market product due to 14 overproduction and yield shrinkage.
[0020] In one aspect, the present invention provides a method for remotely controlling 16 the injection of sensitive data into a device during production thereof.
The method comprises 17 the steps of a controller preparing and cryptographically protecting the sensitive data in a data 18 transmission; the controller sending the data transmission to a server, the server having a 19 secure module for performing cryptographic operations; the secure module extracting the sensitive data from the data transmission; and the server providing the sensitive data to 21 equipment for injection into the device; wherein the controller is located remote from the 22 server.
23 [0021] In another aspect, the present invention provides a system for remotely controlling 24 the injection of sensitive data into a device during production thereof.
The system comprises a controller having a first secure module for perfornling cryptographic operations; a server 26 located remote from the controller and connected thereto by a forward channel and a back 27 channel, the forward channel used by the controller for providing a data transmission to a 28 second secure module of the server, the data transmission cryptographically protecting the 29 sensitive data, the second secure module extracting the data from the transmission; and an 21534179.1 1 agent operating with equipment used for injecting the data upon extraction from the 2 transmission, the agent obtaining the data from the second secure module.
3 [0022] In yet another aspect, a module for controlling the insertion of sensitive data into a 4 device at a plurality of stages is provided. The module includes a cryptographic transform that intercepts and transforms data flow in the device and a cryptographic key stored in a 6 memory, a portion of the sensitive data being added to the cryptographic key at each stage, 7 the cryptographic key being used by the transform for operation thereof, wherein the 8 cryptographic transform correctly alters the data flow upon successful insertion of the 9 sensitive data.
[0023] In yet another aspect, a method is provided for controlling the insertion of 11 sensitive data into a device. The method comprises the steps of including a module in the 12 device, the module having a cryptographic transform for intercepting and transforming data 13 flow in the device; and adding a portion of the sensitive data to a crvptographic key stored in 14 memory in the module at each of a plurality of stages in production of the device; wherein the cryptographic transform correctl_y alters the data flow upon successful insertion of the 16 sensitive data.
18 [0024] An embodiment of the invention will now be described by way of example only 19 with reference to the appended drawings wherein:
[0025] Figure 1 is a schematic block diagram of a remote device registration system;
21 [0026] Figure 2 is a schematic representation of the graphical user interface (GUI) 22 illustrated in Figure 1;
23 [0027] Figure 3 is a schematic representation of a distribution image;
24 [0028] Figure 4 is a flow chart illustrating a key injection and reporting procedure;
[0029] Figure 5 is a flow chart illustrating a provisioning procedure;
26 [0030] Figure 6 is a flow chart depicting a credit instruction procedure;
21534179.1 1 [0031] Figure 7 illustrates a mapping scheme for another embodiment supporting 2 multiple products;
3 100321 Figure 8 illustrates an example of a filtered log report; and 4 [0033] Figure 9 is a block diagram illustrating another embodiment of a remote device registration system.
6 [0034] Figure 10 is a schematic block diagram of an embodiment for key injection using 7 multiple stages in a manufacturing process.
8 [0035] Figure 11 is a schematic representation of a mask incorporating a registration 9 module for separating key injection stages using the embodiment of Figure
17 100061 In a modem business climate comprising ever-increasing device complexity and 18 sophistication, it is common for individual parts to be manufactured and keyed by one 19 manufacturer for later assembly by another manufacturer. In such a situation there exists certain security implications when the producer of the device or the owner of the 21 communication svstem is not the device manufacturer. It can therefore be paramount for a 22 device producer to ensure the integrity of the manufacturing systems that are responsible for 23 the integrity of the producer's device.
24 [0007] When considering the integrity of the manufacturing process, of particular concern are issues related to the confidentiality of secret information that is used to 26 manufacture the device, as well as ensuring that the manufacturer correctly reports the 27 identities and the number of units manufactured to the producer. Ideally, the producer of the 28 device should try to obtain assurances that a manufacturer is not creating and distributing 29 "grey" or "black" market parts or devices. For example, a manufacturer that ships a certain number of keyed products back to the producer, but still has leftover keys, may then 31 manufacture and sell devices with those extra keys. The producer has thus lost revenue since 21534179.1 1 the manufacturer is the one who profits from the sale. Other actions such as cloning or theft 2 of keys may also arise, which is difficult to detect and control when the keying process is 3 outsourced. In some cases, keys could be published on the Internet to enable users to gain 4 access to a conditional access system without paying for such a service.
[0008] Traditionally, a producer that is concerned about securing the information 6 injection stage at a manufacturing site has little choice but to implicitly trust that a 7 manufacturer is operating in a manner that gives due consideration to the producer's device 8 and system security. Protective mechanisms are generally naive, in that keying information is 9 typically bulk encrypted and sent to the manufacturer, where, upon arrival, all of the keying information is decrypted at once, and the manufacturer is then trusted not to compromise the 11 bulk of information.
12 [0009] One method to restrict access to keying information is to use an on-line client-13 server mechanism. With such a mechanism in place, the client at the manufacturer's facility 14 would be connected to a network, and would make requests for keying information on a per-device basis, to a remote key-providing server under the control of the producer.
16 [0010] There are a number of problems with implementing a manufacturing system that 17 relies on an off-site, remotel_v networked server, that provides keying information on such a 18 just-in-time basis. The foremost problem is that an off-site server can not guarantee a 19 minimal service level or response time to the manufacturing line if it uses a public shared packet-switched network. To prevent problems in the manufacturing line, a certain level of 21 service in terms of latency and through-put is optimal. Given modem manufacturing 22 realities, where production lines exist in remote jurisdictions relative to the producer, such 23 guaranteed network availability can be prohibitively expensive.
24 [0011] A manufacturing facility will typically not begin a production run without all of the necessary materials on hand, including data materials. Otherwise, the risk to production 26 line delays would be too high. Any keying system used by a manufacturer, should be able to 27 substantially guarantee service availability and provide a suitable response. This requires 28 local availability of all data resources and keying information before commencement of a 29 production run.
21534179.1 1 [0012] Given that all data resources must be locally available to a production line, 2 possibly existing on computer systems, and media that is not under direct control of the 3 producer; the producer must consider how to ensure the confidentiality of any secret keying 4 information.
100131 Enough data should be locally available to the manufacturer, in order to 6 commence and complete a production run. In the event that the producer discovers 7 unauthorised and contractually objectionable behaviour by the manufacturer, the producer 8 should also consider how to prevent such a rogue manufacturer from producing grey or black 9 market product, after the termination of a contract.
100141 Another problem related to cloning stems from overproduction, a specific type of 11 cloning operation, which is of particular concern to producers of silicon chips.
12 Overproduction can occur when the producer of an integrated circuit (IC) outsources 13 manufacturing of their IC designs to one or more third party manufacturing companies. The 14 purpose of outsourcing certain or all manufacturing steps is to lower production costs by selecting a third party that can offer the best price for performing a particular stage in the 16 manufacturing process. For example, a fabless design house (e.g. a producer) may wish to 17 contract overseas manufacturing facilities to build chips that they have designed. Such 18 overseas manufacturing facilities are often chosen as they are able to produce electronic 19 components relatively inexpensively.
100151 However, outsourcing generally increases the risk that a particular contractor may 21 overproduce product, that they have been contracted to build, in order to supply a grey 22 market. For example, if the contracted manufacturer acts in bad faith and over produces ICs 23 from the design provided by the producer, but does not inform the producer that such 24 overproduction occurs, the extra product is available to be sold in a grey market channel as "counterfeit" or "cloned" ICs. This allows the third party manufacturers to realize extra 26 revenues and earnings at the expense of future product demand and revenues for their 27 customer, namely the producer/designer.
28 [0016] The above may occur because, in such scenarios, often the producer does not ever 29 handle the product aside from receiving engineering samples at the beginning of the production phase. Accordingly, at each stage of the manufacturing process, subsequent to 21534179.1 1 design, there is an opportunit_y to steal parts and product. In some cases, employees of a good 2 faith contract manufacturer may be thieves. "Yield shrinkage" may occur, where an 3 employee steals product right off of the manufacturing line. This can be detrimental to not 4 only the producer and contract manufacturer, due to lost revenue, but also to the relationship between the producer and the manufacturer for conducting future business.
6 [0017] It is therefore an object of the present invention, to obviate or mitigate the above-7 described disadvantages.
9 [0018] The present invention provides a system and method that enables a producer who wishes to use a separate entity for at least a portion of the manufacturing process, to monitor 11 and protect production of devices from a remote location.
12 [0019] The present invention also provides a means for separating the addition of 13 sensitive data to a product between separate entities for inhibiting grey market product due to 14 overproduction and yield shrinkage.
[0020] In one aspect, the present invention provides a method for remotely controlling 16 the injection of sensitive data into a device during production thereof.
The method comprises 17 the steps of a controller preparing and cryptographically protecting the sensitive data in a data 18 transmission; the controller sending the data transmission to a server, the server having a 19 secure module for performing cryptographic operations; the secure module extracting the sensitive data from the data transmission; and the server providing the sensitive data to 21 equipment for injection into the device; wherein the controller is located remote from the 22 server.
23 [0021] In another aspect, the present invention provides a system for remotely controlling 24 the injection of sensitive data into a device during production thereof.
The system comprises a controller having a first secure module for perfornling cryptographic operations; a server 26 located remote from the controller and connected thereto by a forward channel and a back 27 channel, the forward channel used by the controller for providing a data transmission to a 28 second secure module of the server, the data transmission cryptographically protecting the 29 sensitive data, the second secure module extracting the data from the transmission; and an 21534179.1 1 agent operating with equipment used for injecting the data upon extraction from the 2 transmission, the agent obtaining the data from the second secure module.
3 [0022] In yet another aspect, a module for controlling the insertion of sensitive data into a 4 device at a plurality of stages is provided. The module includes a cryptographic transform that intercepts and transforms data flow in the device and a cryptographic key stored in a 6 memory, a portion of the sensitive data being added to the cryptographic key at each stage, 7 the cryptographic key being used by the transform for operation thereof, wherein the 8 cryptographic transform correctly alters the data flow upon successful insertion of the 9 sensitive data.
[0023] In yet another aspect, a method is provided for controlling the insertion of 11 sensitive data into a device. The method comprises the steps of including a module in the 12 device, the module having a cryptographic transform for intercepting and transforming data 13 flow in the device; and adding a portion of the sensitive data to a crvptographic key stored in 14 memory in the module at each of a plurality of stages in production of the device; wherein the cryptographic transform correctl_y alters the data flow upon successful insertion of the 16 sensitive data.
18 [0024] An embodiment of the invention will now be described by way of example only 19 with reference to the appended drawings wherein:
[0025] Figure 1 is a schematic block diagram of a remote device registration system;
21 [0026] Figure 2 is a schematic representation of the graphical user interface (GUI) 22 illustrated in Figure 1;
23 [0027] Figure 3 is a schematic representation of a distribution image;
24 [0028] Figure 4 is a flow chart illustrating a key injection and reporting procedure;
[0029] Figure 5 is a flow chart illustrating a provisioning procedure;
26 [0030] Figure 6 is a flow chart depicting a credit instruction procedure;
21534179.1 1 [0031] Figure 7 illustrates a mapping scheme for another embodiment supporting 2 multiple products;
3 100321 Figure 8 illustrates an example of a filtered log report; and 4 [0033] Figure 9 is a block diagram illustrating another embodiment of a remote device registration system.
6 [0034] Figure 10 is a schematic block diagram of an embodiment for key injection using 7 multiple stages in a manufacturing process.
8 [0035] Figure 11 is a schematic representation of a mask incorporating a registration 9 module for separating key injection stages using the embodiment of Figure
10.
[0036] Figure 12 is a schematic representation of a stage shown in the embodiment of
[0036] Figure 12 is a schematic representation of a stage shown in the embodiment of
11 Figure 10.
12 [0037] Figure 13 is a flowchart showing steps taken in producing a device using the
13 embodiment of Figure 10.
14 100381 Figure 14 is a schematic block diagram of an example product produced from the mask shown in Figure 11.
17 [0039] Referring to Figure 1, a remote device registration or trusted key injection system 18 is generally denoted by numeral 10. A producer 12 of a device 22 utilizes the services of a 19 separate entity, in this case an outside manufacturer 14, for the injection of unique and immutable information into the devices 22. The information may be a cryptographic key, a 21 shared secret, or some other data that may be cryptographically bound to an inherently unique 22 attribute of the device 22 and will hereinafter be referred to as a"key".
The step of injecting 23 the key into a device 22 will hereinafter be referred to as "keying" or "key injection".
24 100401 The producer 12 utilizes a controller 16, which is a computer system that is remote to the manufacturer's facility. The controller 16 includes a hardware security module 26 (HSM) 11. The HSM 11 is a protected device used by the controller 16 to perform 27 cryptographically secure operations, such as encryption, decryption and signing. The HSM
21534179.1 1 11 may be tamper resistant (e.g. physically difficult to access) or may be tamper reactive (e.g.
2 erases data if tampered with). The controller 16 is responsible for packaging and conveying 3 kevs and other information to the manufacturer 14 as well as for monitoring the distribution 4 and usage of the keys by the manufacturer 14. The producer 12 typically obtains bulk quantities of keys (not shown) from an outside source such as a governing body, e.g.
6 producer of HDCP keys. The keys are stored in a data storage device 15 until they are to be 7 distributed to a particular manufacturer 14. The controller 12 and its operations can be 8 monitored, modified and thus controlled by an operator using a graphical user interface (GUI) 9 13. The GUI 13 is typically a software application that is displayed and interacted with using a personal computer (not shown).
11 [00411 The controller 16 is connected to a server 18 residing at the manufacturer 14 12 through a pipeline 23. The pipeline 23 includes two forward communication channels, 13 namely a control channe126 and a distribution channe125, and a backward channel 24. The 14 control channe126 is used by the controller 16 to meter the number of keys that the manufacturer 14 may use by sending credit instructions. The distribution channel 25 is used 16 by the controller 16 to distribute protected blocks of keys to the manufacturer 14. The back 17 channe124 is used by the system 10 to make the controller 16 aware of key usage for 18 reporting and auditing purposes. The channels 24, 25 and 26 may be arbitrary communication 19 channels and are not required to be either reliable or secure. Reliability and security over the channels 24, 25 and 26 are provided using a combination of technical mechanisms and 21 processes/procedures. For example, if a message sent over the forward channe126 to the 22 module 18 does not decrypt because it is corrupt, a user may phone an operator of the system 23 controller module 16, and have them send the message again.
24 100421 The manufacturer 14 utilizes one or more server 18, which is a computer system that is local to the manufacturer's facility and whose activities are monitored and metered 26 through messages sent by the controller 16. The server 18 also reports back to the controller 27 16 over the back channel 24. The server 18 includes an HSM 28 that is similar to the HSM
28 11 utilized by the controller 16. The HSM 28 stores a protected credit pool 30 which dictates 29 how many keys the manufacturer 14 may use. Use of the keys is metered by the controller 16 by monitoring data reported by the server 18, and adding or subtracting from the credit pool 31 30 accordingly. The credit pool 30 is an abstract concept representing the number of keys 21534179.1 I that may be decrypted by the HSM 28 before the server 18 must request and obtain more 2 keys from the controller 16. The controller 16 distributes keys to the server 18 over the 3 distribution channel 25, and the server 18 will store the keys in a local data storage device 17 4 as will be explained more fully below. 5 [00431 The manufacturer 14 utilizes one or more equipment 20 used to inject the 6 cryptographic keys into the devices 22. Tvpically keying occurs during a testing phase of the 7 manufacturing process, and thus the equipment 20 is often a testing machine on an assembly 8 line. The equipment 20 includes a key agent 21 which is typically a software program or 9 toolkit that is loaded into the equipment 20 used to administer key injection at the application side. The key agent 21 communicates with the server 18 to request and obtain keys as they 11 are needed. Typically, the server 18 will provide enough keys to the key agent 21 so as to not 12 disrupt the timing of the production process. However, the server 18 will not provide an 13 unnecessary number of keys so as to restrict the usage of the keys until keying approval is 14 provided by the controller 16 as metered through the credit pool 30.
100441 Typically, the key agent 21 will have threshold levels that indicate when a new 16 batch of keys are needed by that particular equipment 20, so as to not disrupt production.
17 Since the controller 16 is typically not in constant communication with the server 18, the 18 controller 16 may adjust its parameters to ensure that enough keying material is made 19 available to the equipment 20 through the server 18, while ensuring that not too much key data is released by the server 18, before the controller 16 can obtain key usage reports from 21 the server 18 as will be explained in greater detail below.
22 100451 The key agent 21 will preferably include an application program interface (API) 23 that runs on the equipment 20 to enable an operator of the equipment itself to request keys, 24 either manually or in an automated fashion. The key agent 21 is used to provide a level of protection for data passing between the server 18 and the equipment, and may be thought of 26 as a simplified secure sockets layer (SSL) connection between the server 18 and equipment 27 20. It will be appreciated that resources permitting, the key agent 21 may also be 28 implemented using an SSL connection between itself and the server 18. The ke_y agent 21 is 29 also responsible for generating report records as keys are used, that are sent back to the server 18 for reporting purposes.
21534179.1 1 100461 The controller 16 is the command center for monitoring and metering key 2 injection by the manufacturer 14. In order to control keying from a remote location, the GUI
3 13 is used by an operator to monitor and configure each manufacturer 14, server 18, and 4 equipment 20 that is under the control of the controller 16. An example GUI
13 is shown in Figure 2. The GUI 13 is divided into a server window 200, a controller window 204 and an 6 equipment window 202. The server window 200 includes a list of the manufacturers 14 and 7 thus the servers 18 that are controlled by the controller 16. The particular controller 16 is 8 indicated in the controller window 204. The operator can select a particular manufacturer 9 (e.g. manufacturer A as shown in Figure 2), and the equipment 20 that is associated with the manufacturer is displayed in the equipment window 202.
11 100471 In the example shown in Figure 2, the server at manufacturer A
comprises a 12 window offering information regarding server 1, server 2 and server 3. Each server has 13 certain data associated with it. For instance, as shown in Figure 2, each server includes a 14 progress bar showing their available storage space, available credit and number of keys available for each of keytype 1 and keytype 2. Each tester window also displays log 16 information, such as dates on which previous reports were processed, previously reported 17 credit, previous refill amount, and data regarding missing log records. The server windows 18 also provide the operator with options 214 and 216 for remotely configuring and disabling 19 the server 18 from the controller 16.
100481 The controller 16 has the capability of remotely configuring the servers 18. This 21 allows the controller 16 to change key types, add or delete key types and control other 22 configuration options. This is preferably accomplished by sending configuration messages, 23 along the control channe126, to the server HSM 28. The HSM 28 may evaluate the 24 configuration messages, whereby some configuration messages alter the behaviour of the HSM 28, and other configuration messages are sent to the server 18.
Configuration messages 26 sent to the server 18 via the HSM 28, using this method, can help to ensure that the server 18 27 attains configuration instructions that are trusted and known to originate from the controller 28 16.
29 100491 The controller 16 may remotely configure the system 10 at the server level or the equipment level through the key agent 21. The controller 16 can also force polls of the 31 servers 18 and can adjust the intervals for regular polling. Typically, the servers 18 are 21534179.1 1 polled at a fixed interval, and the controller 16 can use a forced poll to obtain information 2 between the intervals as needed. For example, with a one day interval, the controller 16 may 3 need data to report to an administrator intraday, and thus can force a poll of all servers to 4 obtain such data. The GUI 13 may also include a controller email option allowing the controller 16 to automatically contact an administrator in extreme circumstances, such as 6 decryption or distribution failure at critical production runs.
7 [0050] Each key that is distributed to the server 18 and injected by equipment 20 into 8 device 22 triggers certain log records at certain events. The GUI 13 can be used to search, 9 sort, compile and analyze the log records and to view a custom or standard report 400 as shown in Figure 8. In this example, there are three primary log records that are generated. A
11 key to server log 402 is generated when a key is distributed by the producer 16 to a server 18, 12 a key to agent log 404 is generated by the HSM 28 at the point where it releases a key to the 13 key agent 21, and a key injection log 406 will be generated by the key agent 21 upon 14 injection of the key. Each log record may include any number of identifying information, including ID types, time stamps, manufacturer, equipment etc. In the example report shown 16 in Figure 8 the report 400 illustrates a key to server log 402, key to agent log 404 and key 17 injection log 406 for a key having a sequence ID = 001. These records may then be used to 18 track the life cycle of the key having such a sequence ID number. It will be appreciated that 19 the report 400 may include any number of records and may be filtered based on any suitable field. For example, a report 400 showing all keys injected on May 3'd by tester 2 at 21 manufacturer A could be compiled by filtering accordingly, a date field and a location field.
22 [0051) Referring now to Figure 3, the producer 16 may package a bulk set of keys in a 23 secure data transmission using a distribution image 40 that is to be sent to the server 18, 24 preferably using encryption. The distribution image 40 enables the producer to include keys for multiple products destined for multiple servers 18 in one transmission.
Each server 18 is 26 then able to decrypt and obtain a certain number of keys, but only after authorization has 27 been received by the HSM 28, from the controller 16 via the control channe126. The image 28 40 is a collection of data records, each record contains a type 58, ID 60, size 54 and data 56 29 field. Where data 56 will typically contain the key data of an arbitrary size identified by size 54. Type 58 and ID 60 fields are used by the HSM 28 to identify the key data, possibly being 31 used to filter certain keys, depending on the HSM's 28 configuration, as previously instructed 21534179.1 I via the control channel 26. Keys may be encapsulated such that the implementation does not 2 care what a key really looks like to the target. This makes it flexible and extensible without 3 requiring a redesign for each new key type. The wrapper should contain a type, size and 4 unique ID, the body is abstract. The wrapper may also contain elements to support more advanced features like logging or variable assignment into the abstracted image.
6 [0052] The image 40 is encrypted with an image key 42. The image key 42 is used by 7 the server 18 to decrypt the image 40 and obtain the keys. The image key 42 is itself 8 encrypted for each server 18 and stored as a server header 48. A collection 44 of server 9 headers 48 are stored in a main header 46. To decrypt the image 40 and obtain the keys, the header 48 is chosen by the server 18 and is decrypted by the HSM 28 to obtain the image key 11 42. The image key 42 is then used to decrypt the image 40.
12 [0053] As noted earlier, the distribution images 40 may be used to support multiple 13 products. Referring also to Figure 7 a mapping of product types and data blocks is shown.
14 For example, the producer 16 has three products, namely gamma utilizing key 1(having filter tag 1), beta utilizing key 2 (having filter tag 2) and an accompanying configuration block 16 (also having filter tag 2), and alpha utilizing key 1, key 2 and the configuration block. The 17 image 40 may include bulk quantities of keytype I and keytype 2, and the gamma and beta 18 products may be less sophisticated than the alpha product. Producer 16 can package a single 19 image 40 with data for, e.g. fifty (50) of each block, whereby a certain tester (e.g. tester 1) has permission to manufacture, and thus may obtain fifty (50) of filter tags 1 and 2 for 21 producing fifty of product alpha. Another tester (e.g. tester 2) may at the same time have 22 permission to manufacture and thus obtain fifty (50) of filter tag 1 from the image 40, to 23 produce fifty of product beta, and fifty (50) of filter tag 2 to produce product gamma. An 24 image 40 may contain all of the keying data, possibly including multiple type of keys, to produce a single product of any product type. A tester identifies to the server 18 the type of 26 product, or product model, that it is being programmed. This model information is sent to the 27 HSM 28 with the encrypted image 40, so that when the HSM 28 decrypts the image 40, the 28 key data 50, can be filtered and only the key data needed to program the identified product 29 model is ever release by the HSM 28 to the tester. Therefore, the producer 12 can support multiple products with a single image 40 whilst taking steps to ensure that the manufacturer 31 14 can only manufacture the products that they are supposed to be manufacturing.
21534179.1 1 [0054] Since the image 40 can support multiple products, the log records are used to track 2 the actual key injection performed at the tester, which will be explain more fully below. By 3 tracking the log records, a producer 16 can attempt to detect if, e.g., a manufacturer 14 4 returns 50 of product gamma instead of 50 of product alpha (which they have been paid to produce) whereby they could also have sold 50 of product beta on a grey or black market.
6 Such a discrepancy may or may not be malicious but in any case can be reasonably identified.
7 [0055] A typical life cycle of a key from its distribution over distribution channe125 until 8 the HSM 28 reports to the controller 16 over back channel 24, is shown in Figure 4. The 9 highlighted blocks in Figure 4 represent those steps performed by secure modules, namely the HSM 11 and the HSM 28. The controller 16 first obtains a bulk quantity of standard keys 11 from an outside supplier. The controller 16 then passes the keys to the HSM
11, and the 12 HSM 11 encrypts blocks of keys, each block containing a measured quantity of a certain 13 keytype. It will be appreciated that the keys may also be bulk encrypted into blocks having 14 more than one key type. The controller 16 then stores the bulk encrypted keys in the storage device 15 until it receives an order or other command indicating that a block of keys is to be 16 distributed.
17 [0056] When the producer 16 distributes a block of keys, it first obtains a bulk encrypted 18 block and passes this block to the HSM 11. The HSM 11 decrypts the block and re-encrypts 19 the block of keys for transmission with the image key 42. The image key 42 is then itself encrypted for each server 18 to producer the individual headers 48. These headers 48 are 21 stored in the group 44 of the main header 46. At this point, the HSM 11 generates a key to 22 server log 402 for the keys that have been re-encrvpted for distribution.
The log 402 is stored 23 locally at the producer 12 for later analysis. The re-encrypted block of keys is then 24 distributed over the distribution channel 25 to the server 18.
100571 The server 18 passes the encrypted block of keys that are included in the image 40 26 to the HSM 28, and the HSM 28 then decrypts the image 40. The HSM 28 first selects its 27 particular header 48 from the group 44 and decrypts the image key 42. The image key 42 is 28 then decrypted to obtain the keys from the image 40. The image 40 is then preferably 29 validated, e.g., using a secure hashing algorithm, MAC, or digital signature, and filtered. The HSM 28 also then re-encrypts each key that is obtained from the image 40 for storage. The 31 server 18 then stores the re-encrypted keys locally for later use by the equipment 20. It will 21534179.1 1 be appreciated that authenticity of the images 40 is assumed based on the unique symmetric 2 distribution keys ksl and k$2 shared between the controller 16 and server 18. The messages 3 shared therebetween, can be considered authentic once a successful integrity check is 4 performed, e.g. after a sha-2 digest compare.
100581 When the controller 16 receives a request from the equipment 20 for a certain 6 number of keys (e.g. N keys), the HSM 28 is given N keys to decrypt. A key to agent log 7 record 404 is then generated for each of the N keys that is decrypted by the HSM 28 and the 8 keys are passed to the equipment 20 for injection. At this point, the keys are "in the clear"
9 and are thus ready for inj ection.
[0059] The equipment 20 injects each of the N keys and the key agent 21 generates a key 11 injection log record 406 for each key that is injected. The HSM 28 will continually obtain the 12 key to agent log records 404 and key injection log records 406 and preferably concatenates 13 these records into a master log report R that is sent back to the controller 16 over the back 14 channe124.
[0060] The individual logs are preferably concatenated into a binary file, that identifies 16 the date that the file was produced. The reports R are preferably encrypted by the HSM 28 17 with encryption kev kl and returned to an application running on the server 18 to be sent 18 over the back channe124. The controller 16 may then decrypt the report R
and validate the 19 individual logs (e.g. 402, 404, 406). Each log may be tagged with a monotonically synchronous number. If all the record ID values, put together, are not a contiguous set, then 21 the operator of the controller 16 will know where to track the missing logs in the sequence.
22 [0061] As explained above, the controller 16 had previously stored a number of key to 23 server log records 402 for the N keys when they were distributed.
Therefore, the controller 24 16 expects at some time in the future to receive the report R that completes the lifecycle for each key to indicate that the keys that were originally distributed have been decrypted and 26 injected into the correct device, by the correct server 18. The controller 16 is thus able to 27 evaluate log reports as they are provided. The controller 16 can then determine if any action 28 should be taken, such as intervening in the manufacturing operation (e.g.
stop distribution), or 29 providing more keys. The controller 16 may also require further information before distributing a further block of keys. In this way, the controller 16 can meter the distribution 21534179.1 I and only provide more ke-ys if the manufacturer is operating in good faith and has 2 consistently provided accurate log reports.
3 [0062] The log records (e.g. those shown in Figure 8) enable a producer to spot 4 discontinuities in the sequence of ID numbers. For instance, if a number of keys have been distributed but have not reported a key to agent or key to injection log, the manufacturer may 6 have lost that key. This could indicate grey or black market activity. In another scenario, the 7 report R may include a key to agent log 404 but not a key injection log 406 for a particular 8 key. This may indicate that the problem originated at the particular equipment requesting the 9 key rather than the manufacturer 14 itself. Therefore, the manufacturer 14 may also use the log reports R for auditing purposes and to identify internal malicious activity so as to 11 maintain its relationship with the producer 12. The life cycle of each key requires a report 12 record at each critical stage where the key is operated on. Therefore, the producer 12 has the 13 necessary information to identify where problems have arisen and to direct efforts towards 14 correcting or eliminating such problems. Preferably, the log records include information pertaining to not only a sequence number for the key, but also the key type.
In this manner, 16 the producer 12 can also determine if alpha products were commissioned, yet gamma and 17 beta products may have been produced.
18 100631 The log reports provide the information to both deter malicious or unethical acts 19 by the manufacturer 14 and provide the means to evaluate the integrity of the existing manufacturers 14 and tools to provide evidence of any undesirable activity.
The use of 21 tangible evidence in detecting undesirable activity allows the producer 12 to confront the 22 manufacturer 14 with something more than a suspicion, which, in a case where the illicit 23 activity is occurring at the tester level (e.g. by an employee and not the company itself), may 24 salvage an important relationship between the producer 12 and the manufacturer 14.
[0064] In addition to distribution, the controller 16 uses the control channel 26 to control 26 the credit pool 30 and thus meter the key injection stage. A credit instruction procedure is 27 shown in Figure 6. The HSM 28 must consume credit from the credit pool 30 when 28 decrypting a distribution image 40 and obtaining keys. Over time, the credit pool 30 will 29 diminish and need to be replenished with a credit instruction file sent by the controller 16.
21534179.1
17 [0039] Referring to Figure 1, a remote device registration or trusted key injection system 18 is generally denoted by numeral 10. A producer 12 of a device 22 utilizes the services of a 19 separate entity, in this case an outside manufacturer 14, for the injection of unique and immutable information into the devices 22. The information may be a cryptographic key, a 21 shared secret, or some other data that may be cryptographically bound to an inherently unique 22 attribute of the device 22 and will hereinafter be referred to as a"key".
The step of injecting 23 the key into a device 22 will hereinafter be referred to as "keying" or "key injection".
24 100401 The producer 12 utilizes a controller 16, which is a computer system that is remote to the manufacturer's facility. The controller 16 includes a hardware security module 26 (HSM) 11. The HSM 11 is a protected device used by the controller 16 to perform 27 cryptographically secure operations, such as encryption, decryption and signing. The HSM
21534179.1 1 11 may be tamper resistant (e.g. physically difficult to access) or may be tamper reactive (e.g.
2 erases data if tampered with). The controller 16 is responsible for packaging and conveying 3 kevs and other information to the manufacturer 14 as well as for monitoring the distribution 4 and usage of the keys by the manufacturer 14. The producer 12 typically obtains bulk quantities of keys (not shown) from an outside source such as a governing body, e.g.
6 producer of HDCP keys. The keys are stored in a data storage device 15 until they are to be 7 distributed to a particular manufacturer 14. The controller 12 and its operations can be 8 monitored, modified and thus controlled by an operator using a graphical user interface (GUI) 9 13. The GUI 13 is typically a software application that is displayed and interacted with using a personal computer (not shown).
11 [00411 The controller 16 is connected to a server 18 residing at the manufacturer 14 12 through a pipeline 23. The pipeline 23 includes two forward communication channels, 13 namely a control channe126 and a distribution channe125, and a backward channel 24. The 14 control channe126 is used by the controller 16 to meter the number of keys that the manufacturer 14 may use by sending credit instructions. The distribution channel 25 is used 16 by the controller 16 to distribute protected blocks of keys to the manufacturer 14. The back 17 channe124 is used by the system 10 to make the controller 16 aware of key usage for 18 reporting and auditing purposes. The channels 24, 25 and 26 may be arbitrary communication 19 channels and are not required to be either reliable or secure. Reliability and security over the channels 24, 25 and 26 are provided using a combination of technical mechanisms and 21 processes/procedures. For example, if a message sent over the forward channe126 to the 22 module 18 does not decrypt because it is corrupt, a user may phone an operator of the system 23 controller module 16, and have them send the message again.
24 100421 The manufacturer 14 utilizes one or more server 18, which is a computer system that is local to the manufacturer's facility and whose activities are monitored and metered 26 through messages sent by the controller 16. The server 18 also reports back to the controller 27 16 over the back channel 24. The server 18 includes an HSM 28 that is similar to the HSM
28 11 utilized by the controller 16. The HSM 28 stores a protected credit pool 30 which dictates 29 how many keys the manufacturer 14 may use. Use of the keys is metered by the controller 16 by monitoring data reported by the server 18, and adding or subtracting from the credit pool 31 30 accordingly. The credit pool 30 is an abstract concept representing the number of keys 21534179.1 I that may be decrypted by the HSM 28 before the server 18 must request and obtain more 2 keys from the controller 16. The controller 16 distributes keys to the server 18 over the 3 distribution channel 25, and the server 18 will store the keys in a local data storage device 17 4 as will be explained more fully below. 5 [00431 The manufacturer 14 utilizes one or more equipment 20 used to inject the 6 cryptographic keys into the devices 22. Tvpically keying occurs during a testing phase of the 7 manufacturing process, and thus the equipment 20 is often a testing machine on an assembly 8 line. The equipment 20 includes a key agent 21 which is typically a software program or 9 toolkit that is loaded into the equipment 20 used to administer key injection at the application side. The key agent 21 communicates with the server 18 to request and obtain keys as they 11 are needed. Typically, the server 18 will provide enough keys to the key agent 21 so as to not 12 disrupt the timing of the production process. However, the server 18 will not provide an 13 unnecessary number of keys so as to restrict the usage of the keys until keying approval is 14 provided by the controller 16 as metered through the credit pool 30.
100441 Typically, the key agent 21 will have threshold levels that indicate when a new 16 batch of keys are needed by that particular equipment 20, so as to not disrupt production.
17 Since the controller 16 is typically not in constant communication with the server 18, the 18 controller 16 may adjust its parameters to ensure that enough keying material is made 19 available to the equipment 20 through the server 18, while ensuring that not too much key data is released by the server 18, before the controller 16 can obtain key usage reports from 21 the server 18 as will be explained in greater detail below.
22 100451 The key agent 21 will preferably include an application program interface (API) 23 that runs on the equipment 20 to enable an operator of the equipment itself to request keys, 24 either manually or in an automated fashion. The key agent 21 is used to provide a level of protection for data passing between the server 18 and the equipment, and may be thought of 26 as a simplified secure sockets layer (SSL) connection between the server 18 and equipment 27 20. It will be appreciated that resources permitting, the key agent 21 may also be 28 implemented using an SSL connection between itself and the server 18. The ke_y agent 21 is 29 also responsible for generating report records as keys are used, that are sent back to the server 18 for reporting purposes.
21534179.1 1 100461 The controller 16 is the command center for monitoring and metering key 2 injection by the manufacturer 14. In order to control keying from a remote location, the GUI
3 13 is used by an operator to monitor and configure each manufacturer 14, server 18, and 4 equipment 20 that is under the control of the controller 16. An example GUI
13 is shown in Figure 2. The GUI 13 is divided into a server window 200, a controller window 204 and an 6 equipment window 202. The server window 200 includes a list of the manufacturers 14 and 7 thus the servers 18 that are controlled by the controller 16. The particular controller 16 is 8 indicated in the controller window 204. The operator can select a particular manufacturer 9 (e.g. manufacturer A as shown in Figure 2), and the equipment 20 that is associated with the manufacturer is displayed in the equipment window 202.
11 100471 In the example shown in Figure 2, the server at manufacturer A
comprises a 12 window offering information regarding server 1, server 2 and server 3. Each server has 13 certain data associated with it. For instance, as shown in Figure 2, each server includes a 14 progress bar showing their available storage space, available credit and number of keys available for each of keytype 1 and keytype 2. Each tester window also displays log 16 information, such as dates on which previous reports were processed, previously reported 17 credit, previous refill amount, and data regarding missing log records. The server windows 18 also provide the operator with options 214 and 216 for remotely configuring and disabling 19 the server 18 from the controller 16.
100481 The controller 16 has the capability of remotely configuring the servers 18. This 21 allows the controller 16 to change key types, add or delete key types and control other 22 configuration options. This is preferably accomplished by sending configuration messages, 23 along the control channe126, to the server HSM 28. The HSM 28 may evaluate the 24 configuration messages, whereby some configuration messages alter the behaviour of the HSM 28, and other configuration messages are sent to the server 18.
Configuration messages 26 sent to the server 18 via the HSM 28, using this method, can help to ensure that the server 18 27 attains configuration instructions that are trusted and known to originate from the controller 28 16.
29 100491 The controller 16 may remotely configure the system 10 at the server level or the equipment level through the key agent 21. The controller 16 can also force polls of the 31 servers 18 and can adjust the intervals for regular polling. Typically, the servers 18 are 21534179.1 1 polled at a fixed interval, and the controller 16 can use a forced poll to obtain information 2 between the intervals as needed. For example, with a one day interval, the controller 16 may 3 need data to report to an administrator intraday, and thus can force a poll of all servers to 4 obtain such data. The GUI 13 may also include a controller email option allowing the controller 16 to automatically contact an administrator in extreme circumstances, such as 6 decryption or distribution failure at critical production runs.
7 [0050] Each key that is distributed to the server 18 and injected by equipment 20 into 8 device 22 triggers certain log records at certain events. The GUI 13 can be used to search, 9 sort, compile and analyze the log records and to view a custom or standard report 400 as shown in Figure 8. In this example, there are three primary log records that are generated. A
11 key to server log 402 is generated when a key is distributed by the producer 16 to a server 18, 12 a key to agent log 404 is generated by the HSM 28 at the point where it releases a key to the 13 key agent 21, and a key injection log 406 will be generated by the key agent 21 upon 14 injection of the key. Each log record may include any number of identifying information, including ID types, time stamps, manufacturer, equipment etc. In the example report shown 16 in Figure 8 the report 400 illustrates a key to server log 402, key to agent log 404 and key 17 injection log 406 for a key having a sequence ID = 001. These records may then be used to 18 track the life cycle of the key having such a sequence ID number. It will be appreciated that 19 the report 400 may include any number of records and may be filtered based on any suitable field. For example, a report 400 showing all keys injected on May 3'd by tester 2 at 21 manufacturer A could be compiled by filtering accordingly, a date field and a location field.
22 [0051) Referring now to Figure 3, the producer 16 may package a bulk set of keys in a 23 secure data transmission using a distribution image 40 that is to be sent to the server 18, 24 preferably using encryption. The distribution image 40 enables the producer to include keys for multiple products destined for multiple servers 18 in one transmission.
Each server 18 is 26 then able to decrypt and obtain a certain number of keys, but only after authorization has 27 been received by the HSM 28, from the controller 16 via the control channe126. The image 28 40 is a collection of data records, each record contains a type 58, ID 60, size 54 and data 56 29 field. Where data 56 will typically contain the key data of an arbitrary size identified by size 54. Type 58 and ID 60 fields are used by the HSM 28 to identify the key data, possibly being 31 used to filter certain keys, depending on the HSM's 28 configuration, as previously instructed 21534179.1 I via the control channel 26. Keys may be encapsulated such that the implementation does not 2 care what a key really looks like to the target. This makes it flexible and extensible without 3 requiring a redesign for each new key type. The wrapper should contain a type, size and 4 unique ID, the body is abstract. The wrapper may also contain elements to support more advanced features like logging or variable assignment into the abstracted image.
6 [0052] The image 40 is encrypted with an image key 42. The image key 42 is used by 7 the server 18 to decrypt the image 40 and obtain the keys. The image key 42 is itself 8 encrypted for each server 18 and stored as a server header 48. A collection 44 of server 9 headers 48 are stored in a main header 46. To decrypt the image 40 and obtain the keys, the header 48 is chosen by the server 18 and is decrypted by the HSM 28 to obtain the image key 11 42. The image key 42 is then used to decrypt the image 40.
12 [0053] As noted earlier, the distribution images 40 may be used to support multiple 13 products. Referring also to Figure 7 a mapping of product types and data blocks is shown.
14 For example, the producer 16 has three products, namely gamma utilizing key 1(having filter tag 1), beta utilizing key 2 (having filter tag 2) and an accompanying configuration block 16 (also having filter tag 2), and alpha utilizing key 1, key 2 and the configuration block. The 17 image 40 may include bulk quantities of keytype I and keytype 2, and the gamma and beta 18 products may be less sophisticated than the alpha product. Producer 16 can package a single 19 image 40 with data for, e.g. fifty (50) of each block, whereby a certain tester (e.g. tester 1) has permission to manufacture, and thus may obtain fifty (50) of filter tags 1 and 2 for 21 producing fifty of product alpha. Another tester (e.g. tester 2) may at the same time have 22 permission to manufacture and thus obtain fifty (50) of filter tag 1 from the image 40, to 23 produce fifty of product beta, and fifty (50) of filter tag 2 to produce product gamma. An 24 image 40 may contain all of the keying data, possibly including multiple type of keys, to produce a single product of any product type. A tester identifies to the server 18 the type of 26 product, or product model, that it is being programmed. This model information is sent to the 27 HSM 28 with the encrypted image 40, so that when the HSM 28 decrypts the image 40, the 28 key data 50, can be filtered and only the key data needed to program the identified product 29 model is ever release by the HSM 28 to the tester. Therefore, the producer 12 can support multiple products with a single image 40 whilst taking steps to ensure that the manufacturer 31 14 can only manufacture the products that they are supposed to be manufacturing.
21534179.1 1 [0054] Since the image 40 can support multiple products, the log records are used to track 2 the actual key injection performed at the tester, which will be explain more fully below. By 3 tracking the log records, a producer 16 can attempt to detect if, e.g., a manufacturer 14 4 returns 50 of product gamma instead of 50 of product alpha (which they have been paid to produce) whereby they could also have sold 50 of product beta on a grey or black market.
6 Such a discrepancy may or may not be malicious but in any case can be reasonably identified.
7 [0055] A typical life cycle of a key from its distribution over distribution channe125 until 8 the HSM 28 reports to the controller 16 over back channel 24, is shown in Figure 4. The 9 highlighted blocks in Figure 4 represent those steps performed by secure modules, namely the HSM 11 and the HSM 28. The controller 16 first obtains a bulk quantity of standard keys 11 from an outside supplier. The controller 16 then passes the keys to the HSM
11, and the 12 HSM 11 encrypts blocks of keys, each block containing a measured quantity of a certain 13 keytype. It will be appreciated that the keys may also be bulk encrypted into blocks having 14 more than one key type. The controller 16 then stores the bulk encrypted keys in the storage device 15 until it receives an order or other command indicating that a block of keys is to be 16 distributed.
17 [0056] When the producer 16 distributes a block of keys, it first obtains a bulk encrypted 18 block and passes this block to the HSM 11. The HSM 11 decrypts the block and re-encrypts 19 the block of keys for transmission with the image key 42. The image key 42 is then itself encrypted for each server 18 to producer the individual headers 48. These headers 48 are 21 stored in the group 44 of the main header 46. At this point, the HSM 11 generates a key to 22 server log 402 for the keys that have been re-encrvpted for distribution.
The log 402 is stored 23 locally at the producer 12 for later analysis. The re-encrypted block of keys is then 24 distributed over the distribution channel 25 to the server 18.
100571 The server 18 passes the encrypted block of keys that are included in the image 40 26 to the HSM 28, and the HSM 28 then decrypts the image 40. The HSM 28 first selects its 27 particular header 48 from the group 44 and decrypts the image key 42. The image key 42 is 28 then decrypted to obtain the keys from the image 40. The image 40 is then preferably 29 validated, e.g., using a secure hashing algorithm, MAC, or digital signature, and filtered. The HSM 28 also then re-encrypts each key that is obtained from the image 40 for storage. The 31 server 18 then stores the re-encrypted keys locally for later use by the equipment 20. It will 21534179.1 1 be appreciated that authenticity of the images 40 is assumed based on the unique symmetric 2 distribution keys ksl and k$2 shared between the controller 16 and server 18. The messages 3 shared therebetween, can be considered authentic once a successful integrity check is 4 performed, e.g. after a sha-2 digest compare.
100581 When the controller 16 receives a request from the equipment 20 for a certain 6 number of keys (e.g. N keys), the HSM 28 is given N keys to decrypt. A key to agent log 7 record 404 is then generated for each of the N keys that is decrypted by the HSM 28 and the 8 keys are passed to the equipment 20 for injection. At this point, the keys are "in the clear"
9 and are thus ready for inj ection.
[0059] The equipment 20 injects each of the N keys and the key agent 21 generates a key 11 injection log record 406 for each key that is injected. The HSM 28 will continually obtain the 12 key to agent log records 404 and key injection log records 406 and preferably concatenates 13 these records into a master log report R that is sent back to the controller 16 over the back 14 channe124.
[0060] The individual logs are preferably concatenated into a binary file, that identifies 16 the date that the file was produced. The reports R are preferably encrypted by the HSM 28 17 with encryption kev kl and returned to an application running on the server 18 to be sent 18 over the back channe124. The controller 16 may then decrypt the report R
and validate the 19 individual logs (e.g. 402, 404, 406). Each log may be tagged with a monotonically synchronous number. If all the record ID values, put together, are not a contiguous set, then 21 the operator of the controller 16 will know where to track the missing logs in the sequence.
22 [0061] As explained above, the controller 16 had previously stored a number of key to 23 server log records 402 for the N keys when they were distributed.
Therefore, the controller 24 16 expects at some time in the future to receive the report R that completes the lifecycle for each key to indicate that the keys that were originally distributed have been decrypted and 26 injected into the correct device, by the correct server 18. The controller 16 is thus able to 27 evaluate log reports as they are provided. The controller 16 can then determine if any action 28 should be taken, such as intervening in the manufacturing operation (e.g.
stop distribution), or 29 providing more keys. The controller 16 may also require further information before distributing a further block of keys. In this way, the controller 16 can meter the distribution 21534179.1 I and only provide more ke-ys if the manufacturer is operating in good faith and has 2 consistently provided accurate log reports.
3 [0062] The log records (e.g. those shown in Figure 8) enable a producer to spot 4 discontinuities in the sequence of ID numbers. For instance, if a number of keys have been distributed but have not reported a key to agent or key to injection log, the manufacturer may 6 have lost that key. This could indicate grey or black market activity. In another scenario, the 7 report R may include a key to agent log 404 but not a key injection log 406 for a particular 8 key. This may indicate that the problem originated at the particular equipment requesting the 9 key rather than the manufacturer 14 itself. Therefore, the manufacturer 14 may also use the log reports R for auditing purposes and to identify internal malicious activity so as to 11 maintain its relationship with the producer 12. The life cycle of each key requires a report 12 record at each critical stage where the key is operated on. Therefore, the producer 12 has the 13 necessary information to identify where problems have arisen and to direct efforts towards 14 correcting or eliminating such problems. Preferably, the log records include information pertaining to not only a sequence number for the key, but also the key type.
In this manner, 16 the producer 12 can also determine if alpha products were commissioned, yet gamma and 17 beta products may have been produced.
18 100631 The log reports provide the information to both deter malicious or unethical acts 19 by the manufacturer 14 and provide the means to evaluate the integrity of the existing manufacturers 14 and tools to provide evidence of any undesirable activity.
The use of 21 tangible evidence in detecting undesirable activity allows the producer 12 to confront the 22 manufacturer 14 with something more than a suspicion, which, in a case where the illicit 23 activity is occurring at the tester level (e.g. by an employee and not the company itself), may 24 salvage an important relationship between the producer 12 and the manufacturer 14.
[0064] In addition to distribution, the controller 16 uses the control channel 26 to control 26 the credit pool 30 and thus meter the key injection stage. A credit instruction procedure is 27 shown in Figure 6. The HSM 28 must consume credit from the credit pool 30 when 28 decrypting a distribution image 40 and obtaining keys. Over time, the credit pool 30 will 29 diminish and need to be replenished with a credit instruction file sent by the controller 16.
21534179.1
-15-1 [0065] The controller 16 only sends one control message C to the server 18 at a time over 2 control channel 26. One of the preferably required files contained in this message is a credit 3 instruction file. The file can be an encrypted set of data for a specific server 18 that is 4 decrypted by the HSM 28, to a credit instruction. The credit instruction contains, e.g., the serial number of the HSM 28 and/or server 18, the server's token ID, a sequence number, 6 new credit amount, and configuration data, that has all been signed by the controller 16.
7 [0066] Upon receiving the control message C, the HSM 28 decrypts the credit instruction 8 data from the control message C, and validates the signature. The HSM 28 also validates the 9 serial number and token ID as its own, if applicable. A validation of the sequence number is then performed. The sequence number should be greater than the sequence internally stored 11 in the HSM 28. Once validated, the HSM 28 will update its internal sequence number and set 12 the value of the credit pool 30 to the credit value in the credit instruction.
13 [0067] The HSM 28 will then process any configuration messages in the control message 14 C to update its intemal configuration, in order to enable the controller 16 to push configuration data to the server 18, such as updates for filtering rules, keying information,
7 [0066] Upon receiving the control message C, the HSM 28 decrypts the credit instruction 8 data from the control message C, and validates the signature. The HSM 28 also validates the 9 serial number and token ID as its own, if applicable. A validation of the sequence number is then performed. The sequence number should be greater than the sequence internally stored 11 in the HSM 28. Once validated, the HSM 28 will update its internal sequence number and set 12 the value of the credit pool 30 to the credit value in the credit instruction.
13 [0067] The HSM 28 will then process any configuration messages in the control message 14 C to update its intemal configuration, in order to enable the controller 16 to push configuration data to the server 18, such as updates for filtering rules, keying information,
16 credit rules etc., as explained above in relation to the GUI 13.
Configuration data can be
Configuration data can be
17 intended for the HSM 28, an application running on the server 18 or even the key agent 21.
18 The HSM 281ooks for configuration messages of a defined type to process them.
19 Configuration messages can be marked as private or public, and access thereto would then be controlled by the HSM 28.
21 100681 A credit report Cr is the server's response to processing a credit instruction in a 22 control message C. The credit report Cr may contain the serial number and token ID of the 23 HSM 28, the current sequence value, the current value of the credit pool 30, number of refills 24 to date, and an error code that is set to zero if no errors occurred during credit instruction processing.
26 [00691 The credit report Cr is preferably signed by the HSM 28 using its signing key k2.
27 The report Cr is then encrypted for the controller 16 using the controller's public encryption 28 kev k3. The report Cr is then sent to the controller 16 and stored with the log reports R for the 29 above described auditing purposes.
21534179.1 1 100701 Prior to distributing keys, the producer 12 and the manufacturer 14 may undergo a 2 provisioning procedure to initialize the HSMs and the server 18. The provisioning procedure 3 is shown in Figure 5. The HSM 28 produces and sends a provisioning request message P to 4 the controller 16. This message P preferably contains the serial number of the HSM 28 being used by the server 18. The HSM 28 generates the two cryptographic key pairs kl, k2 (e.g.
6 RSA key pairs or preferably using elliptic curve cryptography (ECC)), one (kl) for receiving 7 encrypted messages and another (k2) for signing outgoing messages.
Preferably, the 8 manufacturer 14 is cryptographically bootstrapped in a physically controlled environment 9 during this exchange of key pairs kl and k2.
100711 When the controller 16 receives the provisioning request from the server 18, it 11 passes the request to the HSM 11 who checks the integrity of the message and then assigns 12 the manufacturer 14 a "token ID". Two keys, preferably symmetric keys ksl and ks2 (e.g.
13 Advanced Encryption Standard (AES) keys), are generated. These keys are to be used by the 14 controller 16 and server 18 to protect the distribution images 40 on the distribution channel 25 and the log reports R on the backward channel 24 as mentioned above.
16 [0072] The HSM 11 then generates a provisioning response message P' that, for example, 17 contains the assigned token ID, public keys of the HSM's encryption and signing key pairs k;
18 and k4 respectively, the distribution and backward channel symmetric kevs ksl and ks2, some 19 initial configuration data, and a hash digest for integrity. Similar to the provisioning request message P. it is assumed that the provisioning response message P' is handled within a 21 physically controlled environment (e.g. using HSM protection).
22 [0073] The provisioning response message P' may then be sent to the server 18, and the 23 server 18 may then perform initialization operations upon receiving its first provisioning 24 request. The structure of the provisioning response may contain a member that decrypts to a separate structure that contains symmetric keys for the forward and backward channel 26 communications between the controller 16 and server 18. It shall be noted that these keys are 27 distinct for each HSM 28 (and thus each server 18), and are not shared amongst a group of 28 HSMs. Once the provisioning procedure is complete, a normal exchange of distribution 29 images 40 and control messages C may commence.
21534179.1 1 100741 In another embodiment, shown in Figure 9, the system 10 may be retrofitted to 2 existing solutions that have been implemented by the manufacturer 14 for protecting the key 3 injection stage. In the embodiment shown in Figure 9, like elements are given like numerals 4 with the suffix "a". For example, a manufacturer 14, may have equipment 20a that already includes a scrambler 74 for converting a string "BCA" to "ABC", where the device 22 is 6 wired to accept ABC as the injected key. In this manner, if the key "BCA" is stolen or 7 misplaced, it will not work for the device 22a because the scrambling has not occurred.
8 These attempts at protecting a key, although easy to implement, are typically naive and may 9 not provide a suitable level of protection. By accommodating for such protection, the system 10 may then be retrofitted to the equipment 20a without undoing an existing solution that has 11 already been implemented. Accordingly, additional cost to manufacturer 14 for 12 implementing system 10 can be avoided. The retrofit may be implemented until a complete 13 redesign is warranted, at which time the arrangement shown in Figure 1 may be used.
14 [0075] In order to accommodate existing solutions, the system 10 stores a set of signed objects 72 at the server 18, which are a collection of executable files that are associated with 16 particular equipment 20a and perform the existing solution subsequent to the HSM 28a 17 releasing a key, and prior to key injection. In this way, the key is altered to accommodate the 18 existing solution without the equipment 20a being aware. As shown in Figure 9, the 19 controller 16a would first need access to the executable file (exe) 70 that is used by the equipment 20a to provide the existing solution. The controller 16a would then pass the exe 21 70 to the HSM 11 a. The HSM 11 a would then sign the exe 70 and pass the signed exe 70 to 22 the HSM 28a, and the HSM 28a may then store the signed exe 70 as a signed object 72. In 23 operation, when the equipment 20a requests a new batch of keys, the server 18a will validate 24 the exe against the exe's signature, that is stored in the HSM 28a. Once the server 18a has verified the exe 72, it will send the exe keys to be scrambled.
26 100761 For example, equipment 20a requires a key BCA to feed to scrambler 76 in device 27 22a so that the key ABC is injected to product alpha. The HSM 28a determines that product 28 alpha has a signed object exe A. for modifying key ABC. The signed object exe A is 29 verified, and applied to key ABC resulting in scrambled key BCA. The scrambled key BCA
is then sent to equipment 20a, and the scrambler 76 modifies key BCA so that it injects key 31 ABC. The equipment 20a does not realize that the key BCA (that it received) was stored by 21534179.1 1 the server 18a in a protected form as ABC. It will be appreciated that the key stored by the 2 server 18a may also be in a form such as CAB, which is then modified to read BCA for 3 scrambling to then be converted to ABC for injection. Such a case may arise when key CAB
4 is the standard form and must be modified to suit an existing solution where CAB would not be accepted as the key. Therefore, the signed objects 72 will contain any program required to 6 accommodate the existing solution implemented by equipment 20a, and the example 7 provided above is solely for illustrative purposes.
8 [0077] The signed objects 72 also inhibit malicious code from being loaded into the 9 server 18a for modifying the keys prior to injection, since the signed executables are typically verified for the keys to be released to the machine prior to being applied to a key. The system 11 10 can thus provide an increased level of security whilst accommodating an existing solution.
12 [0078] Therefore, by utilizing a remote system controller 16 separate from the server 18, 13 the producer 12 is able to monitor the activities of the manufacturer 14, and meter credit 14 through the HSM 28. The producer 16 is thus able to govern the injection of keying information on the devices 22, in order to ensure that the manufacturer 14 correctly reports 16 the identities and the number of units manufactured for the producer 12.
This enables the 17 producer 12 to have assurances that a manufacturer 14 is not creating and distributing grey or 18 black market products or devices 22.
19 [0079] With the above procedures and system 10 in place, a producer 12 can monitor production at a manufacturer 14. The producer 12, using the credit instructions in the control 21 messages C, can meter the production of devices 22 by adding or removing available credit 22 for use by the manufacturer 14.
23 [0080] It will be appreciated that the s_ystem 10 is not limited to one manufacturer 14 as 24 shown in Figure 1, nor is each manufacturer 14 limited to one set of equipment 20. The system 10 is also not to be limited to the use of a single controller 16. The HSM 28 is most 26 preferably trusted hardware in order to protect key values and the integrity of the credit pool 27 30. Moreover, keying information contained in the distribution image 40 does not 28 necessarily have to be keying information, but can also be any data element that requires 29 confidentiality and authenticity. A requirement for keying data is typical of a system 10 which wishes to enforce granularity of device activation.
21534179.1 1 100811 In an alternative arrangement, exemplified in Figures 10-14 and described in 2 greater detail below, overproduction may be inhibited by introducing a separation of duties 3 within the silicon or device manufacturing process. Typically a producer 12 will contract out 4 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 6 that the end product must have been "touched", by each subcontractor, in order for the end 7 product to be fully functional. Since grey markets are typically supplied by a single point of 8 failure, or a single bad-faith contractor in the manufacturing chain, forcing a set of 9 contractors to operate in sequence implies that two or more subcontractors must collude against the producer 12, in order to supply a grey market with non-crippled sub-components 11 or devices. The end product, and it's sub-components, should complete all manufacturing 12 stages to be fully functional. In general, the risk of attack against the producer 12 is 13 drastically reduced when multiple sub-contractors are required to collude in order to steal.
14 100821 In the production of silicon wafers, several stages typically occur, that are often divided amongst several third party manufacturers. A producer 12 that designs a chip, will 16 create the design in a data file or multiple data files, often referred to as a "net list". The net 17 list contains description language in the form of computer code for instructing a third party 18 how to produce a mask for in turn producing a wafer of silicon, from which an IC is 19 packaged and distributed.
100831 For example, in an illustrative manufacturing process, the mask may be sent by 21 the producer 12 to a silicon fabricator who manufactures the silicon wafers from the masks.
22 The wafers may then be sent to a wafer testing facility where individual chips are tested 23 directly on the wafer, and electronically marked so that, when cut, only the individual chips 24 that passed will be forwarded to the packaging facility. The packaging facility will bond and package the silicon into a chip package, and again test the final packaged chip. The finished 26 chips are then typically sent to an OEM, where the chips are mounted on a printed circuit 27 board, which is part of a finished device product, and the finished device product is sent to 28 the distribution channel, and eventually a customer.
29 [0084) The above illustrative manufacturing process generally comprises multiple stages that occur between design and integration of silicon chips into devices, namely fabrication, 31 testing, packaging and installation. It will be appreciated that all of these stages may 21534179.1
21 100681 A credit report Cr is the server's response to processing a credit instruction in a 22 control message C. The credit report Cr may contain the serial number and token ID of the 23 HSM 28, the current sequence value, the current value of the credit pool 30, number of refills 24 to date, and an error code that is set to zero if no errors occurred during credit instruction processing.
26 [00691 The credit report Cr is preferably signed by the HSM 28 using its signing key k2.
27 The report Cr is then encrypted for the controller 16 using the controller's public encryption 28 kev k3. The report Cr is then sent to the controller 16 and stored with the log reports R for the 29 above described auditing purposes.
21534179.1 1 100701 Prior to distributing keys, the producer 12 and the manufacturer 14 may undergo a 2 provisioning procedure to initialize the HSMs and the server 18. The provisioning procedure 3 is shown in Figure 5. The HSM 28 produces and sends a provisioning request message P to 4 the controller 16. This message P preferably contains the serial number of the HSM 28 being used by the server 18. The HSM 28 generates the two cryptographic key pairs kl, k2 (e.g.
6 RSA key pairs or preferably using elliptic curve cryptography (ECC)), one (kl) for receiving 7 encrypted messages and another (k2) for signing outgoing messages.
Preferably, the 8 manufacturer 14 is cryptographically bootstrapped in a physically controlled environment 9 during this exchange of key pairs kl and k2.
100711 When the controller 16 receives the provisioning request from the server 18, it 11 passes the request to the HSM 11 who checks the integrity of the message and then assigns 12 the manufacturer 14 a "token ID". Two keys, preferably symmetric keys ksl and ks2 (e.g.
13 Advanced Encryption Standard (AES) keys), are generated. These keys are to be used by the 14 controller 16 and server 18 to protect the distribution images 40 on the distribution channel 25 and the log reports R on the backward channel 24 as mentioned above.
16 [0072] The HSM 11 then generates a provisioning response message P' that, for example, 17 contains the assigned token ID, public keys of the HSM's encryption and signing key pairs k;
18 and k4 respectively, the distribution and backward channel symmetric kevs ksl and ks2, some 19 initial configuration data, and a hash digest for integrity. Similar to the provisioning request message P. it is assumed that the provisioning response message P' is handled within a 21 physically controlled environment (e.g. using HSM protection).
22 [0073] The provisioning response message P' may then be sent to the server 18, and the 23 server 18 may then perform initialization operations upon receiving its first provisioning 24 request. The structure of the provisioning response may contain a member that decrypts to a separate structure that contains symmetric keys for the forward and backward channel 26 communications between the controller 16 and server 18. It shall be noted that these keys are 27 distinct for each HSM 28 (and thus each server 18), and are not shared amongst a group of 28 HSMs. Once the provisioning procedure is complete, a normal exchange of distribution 29 images 40 and control messages C may commence.
21534179.1 1 100741 In another embodiment, shown in Figure 9, the system 10 may be retrofitted to 2 existing solutions that have been implemented by the manufacturer 14 for protecting the key 3 injection stage. In the embodiment shown in Figure 9, like elements are given like numerals 4 with the suffix "a". For example, a manufacturer 14, may have equipment 20a that already includes a scrambler 74 for converting a string "BCA" to "ABC", where the device 22 is 6 wired to accept ABC as the injected key. In this manner, if the key "BCA" is stolen or 7 misplaced, it will not work for the device 22a because the scrambling has not occurred.
8 These attempts at protecting a key, although easy to implement, are typically naive and may 9 not provide a suitable level of protection. By accommodating for such protection, the system 10 may then be retrofitted to the equipment 20a without undoing an existing solution that has 11 already been implemented. Accordingly, additional cost to manufacturer 14 for 12 implementing system 10 can be avoided. The retrofit may be implemented until a complete 13 redesign is warranted, at which time the arrangement shown in Figure 1 may be used.
14 [0075] In order to accommodate existing solutions, the system 10 stores a set of signed objects 72 at the server 18, which are a collection of executable files that are associated with 16 particular equipment 20a and perform the existing solution subsequent to the HSM 28a 17 releasing a key, and prior to key injection. In this way, the key is altered to accommodate the 18 existing solution without the equipment 20a being aware. As shown in Figure 9, the 19 controller 16a would first need access to the executable file (exe) 70 that is used by the equipment 20a to provide the existing solution. The controller 16a would then pass the exe 21 70 to the HSM 11 a. The HSM 11 a would then sign the exe 70 and pass the signed exe 70 to 22 the HSM 28a, and the HSM 28a may then store the signed exe 70 as a signed object 72. In 23 operation, when the equipment 20a requests a new batch of keys, the server 18a will validate 24 the exe against the exe's signature, that is stored in the HSM 28a. Once the server 18a has verified the exe 72, it will send the exe keys to be scrambled.
26 100761 For example, equipment 20a requires a key BCA to feed to scrambler 76 in device 27 22a so that the key ABC is injected to product alpha. The HSM 28a determines that product 28 alpha has a signed object exe A. for modifying key ABC. The signed object exe A is 29 verified, and applied to key ABC resulting in scrambled key BCA. The scrambled key BCA
is then sent to equipment 20a, and the scrambler 76 modifies key BCA so that it injects key 31 ABC. The equipment 20a does not realize that the key BCA (that it received) was stored by 21534179.1 1 the server 18a in a protected form as ABC. It will be appreciated that the key stored by the 2 server 18a may also be in a form such as CAB, which is then modified to read BCA for 3 scrambling to then be converted to ABC for injection. Such a case may arise when key CAB
4 is the standard form and must be modified to suit an existing solution where CAB would not be accepted as the key. Therefore, the signed objects 72 will contain any program required to 6 accommodate the existing solution implemented by equipment 20a, and the example 7 provided above is solely for illustrative purposes.
8 [0077] The signed objects 72 also inhibit malicious code from being loaded into the 9 server 18a for modifying the keys prior to injection, since the signed executables are typically verified for the keys to be released to the machine prior to being applied to a key. The system 11 10 can thus provide an increased level of security whilst accommodating an existing solution.
12 [0078] Therefore, by utilizing a remote system controller 16 separate from the server 18, 13 the producer 12 is able to monitor the activities of the manufacturer 14, and meter credit 14 through the HSM 28. The producer 16 is thus able to govern the injection of keying information on the devices 22, in order to ensure that the manufacturer 14 correctly reports 16 the identities and the number of units manufactured for the producer 12.
This enables the 17 producer 12 to have assurances that a manufacturer 14 is not creating and distributing grey or 18 black market products or devices 22.
19 [0079] With the above procedures and system 10 in place, a producer 12 can monitor production at a manufacturer 14. The producer 12, using the credit instructions in the control 21 messages C, can meter the production of devices 22 by adding or removing available credit 22 for use by the manufacturer 14.
23 [0080] It will be appreciated that the s_ystem 10 is not limited to one manufacturer 14 as 24 shown in Figure 1, nor is each manufacturer 14 limited to one set of equipment 20. The system 10 is also not to be limited to the use of a single controller 16. The HSM 28 is most 26 preferably trusted hardware in order to protect key values and the integrity of the credit pool 27 30. Moreover, keying information contained in the distribution image 40 does not 28 necessarily have to be keying information, but can also be any data element that requires 29 confidentiality and authenticity. A requirement for keying data is typical of a system 10 which wishes to enforce granularity of device activation.
21534179.1 1 100811 In an alternative arrangement, exemplified in Figures 10-14 and described in 2 greater detail below, overproduction may be inhibited by introducing a separation of duties 3 within the silicon or device manufacturing process. Typically a producer 12 will contract out 4 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 6 that the end product must have been "touched", by each subcontractor, in order for the end 7 product to be fully functional. Since grey markets are typically supplied by a single point of 8 failure, or a single bad-faith contractor in the manufacturing chain, forcing a set of 9 contractors to operate in sequence implies that two or more subcontractors must collude against the producer 12, in order to supply a grey market with non-crippled sub-components 11 or devices. The end product, and it's sub-components, should complete all manufacturing 12 stages to be fully functional. In general, the risk of attack against the producer 12 is 13 drastically reduced when multiple sub-contractors are required to collude in order to steal.
14 100821 In the production of silicon wafers, several stages typically occur, that are often divided amongst several third party manufacturers. A producer 12 that designs a chip, will 16 create the design in a data file or multiple data files, often referred to as a "net list". The net 17 list contains description language in the form of computer code for instructing a third party 18 how to produce a mask for in turn producing a wafer of silicon, from which an IC is 19 packaged and distributed.
100831 For example, in an illustrative manufacturing process, the mask may be sent by 21 the producer 12 to a silicon fabricator who manufactures the silicon wafers from the masks.
22 The wafers may then be sent to a wafer testing facility where individual chips are tested 23 directly on the wafer, and electronically marked so that, when cut, only the individual chips 24 that passed will be forwarded to the packaging facility. The packaging facility will bond and package the silicon into a chip package, and again test the final packaged chip. The finished 26 chips are then typically sent to an OEM, where the chips are mounted on a printed circuit 27 board, which is part of a finished device product, and the finished device product is sent to 28 the distribution channel, and eventually a customer.
29 [0084) The above illustrative manufacturing process generally comprises multiple stages that occur between design and integration of silicon chips into devices, namely fabrication, 31 testing, packaging and installation. It will be appreciated that all of these stages may 21534179.1
-20-1 alternatively occur at a single facility and that there may also be many more stages, up to an 2 arbitrary N number of stages. At each of these stages, there exists an opportunity for 3 overproduction or yield shrinkage to occur.
4 [0085] Referring now to Figure 10, the producer 12 designs a mask 90. The mask 90 is used for producing a registered device 22, in this example, an IC. The device 22 includes 6 some form of sensitive or immutable information that is to be included in its design, and 7 preferably cannot operate without such sensitive information. The producer 12 contracts, in 8 this example, two or more third party manufacturing entities that perform specific stages in 9 the overall manufacture of device 22. Figure 10 shows a first manufacturing stage 100, a second manufacturing stage 102, up to an arbitrary Nth manufacturing stage 104.
11 [0086] The producer 12 distributes the mask 90 over a product distribution channe180.
12 The mask 90 is sent to the first manufacturing stage 100, where a portion of the 13 manufacturing takes place, such as production of a silicon wafer. Once the first stage 100 is 14 complete, the resultant partially finished product is sent to the second manufacturing stage 102, to complete a second portion of the manufacturing, such as testing of the wafers. This is 16 repeated for each stage up to the arbitrary Nth stage, which ultimately ships a completely 17 functional, registered device 22 to a distribution entity 106.
18 [0087] In order to prevent an incomplete product or sub-components from being diverted 19 to a grey market 110 at one of the manufacturing entities 100-104, a "separation of duties" is applied. The separation of duties is a division of manufacturing and data programming duties
4 [0085] Referring now to Figure 10, the producer 12 designs a mask 90. The mask 90 is used for producing a registered device 22, in this example, an IC. The device 22 includes 6 some form of sensitive or immutable information that is to be included in its design, and 7 preferably cannot operate without such sensitive information. The producer 12 contracts, in 8 this example, two or more third party manufacturing entities that perform specific stages in 9 the overall manufacture of device 22. Figure 10 shows a first manufacturing stage 100, a second manufacturing stage 102, up to an arbitrary Nth manufacturing stage 104.
11 [0086] The producer 12 distributes the mask 90 over a product distribution channe180.
12 The mask 90 is sent to the first manufacturing stage 100, where a portion of the 13 manufacturing takes place, such as production of a silicon wafer. Once the first stage 100 is 14 complete, the resultant partially finished product is sent to the second manufacturing stage 102, to complete a second portion of the manufacturing, such as testing of the wafers. This is 16 repeated for each stage up to the arbitrary Nth stage, which ultimately ships a completely 17 functional, registered device 22 to a distribution entity 106.
18 [0087] In order to prevent an incomplete product or sub-components from being diverted 19 to a grey market 110 at one of the manufacturing entities 100-104, a "separation of duties" is applied. The separation of duties is a division of manufacturing and data programming duties
21 of each manufacturing stage, such that all duties must be performed by the intended
22 contractor in the intended order, necessary to complete production of an un-crippled device.
23 In this example, a sensitive task such as the injection of cryptographic data is injected in
24 multiple stages, each of which is carried out by a distinct manufacturing entity, during a distinct manufacturing stage. In order to separate the sensitive task(s), the producer 12 26 incorporates a registration module 92 into the design defined in the mask 90. The module 92 27 is used such that when the mask 90 is compiled to produce the device 22, a mathematical 28 transformation intercepts critical signals and data flows within the silicon chip, such as a boot 29 signal, and if the mathematical transformation cannot operate, the device 22 is crippled. The mathematical transformation is preferably a cryptographic transformation that makes 31 extensive use of Exclusive-OR (XOR) operations, for performance reasons, however this is 21534179.1 1 not a requirement. In order for the mathematical transformation to operate, it is registered 2 through incremental injections or additions of critical data, such as portions of cryptographic 3 keving data, at each stage of the manufacturing process. In this way, if a wafer produced at 4 the first stage 100, is overproduced and supplied to grey market stages 2 through N 110 as shown in Figure 10, the product 112 is crippled, typically because it has not received all of 6 the required cryptographic data that is required to properly operate.
7 100881 Preferably, as shown by way of example in Figure 10, the key injection system 10 8 described above in Figures 1-9 may be used to distribute, meter and solicit reporting of the 9 key injection stages at each manufacturing step. In this case, even if all entities are in collusion to distribute grey market product, the producer 12 will be able to detect this activity 11 due to incomplete log reports, and if necessary inhibit the distribution of further keying data 12 It will be appreciated that altematively, system 10 may be used at any number of stages and 13 need not be used at each or any stage at all. For example, the second stage 102 may utilize 14 the system 10 but not any other stage. However, since preferably each manufacturing stage will include some form of testing procedure, it is beneficial to incorporate system 10 into 16 such testing. The producer 12 in this scenario would at least expect data during the second 17 stage. It will also be appreciated that the module 92 may be used without relying on the 18 system 10 and may rely on each manufacturing stage to implement a portion of the keying 19 process. In any of these situations, by splitting responsibilities, no one entity has the necessary information, on their own, to successfully supply grey markets with product or sub-21 components.
22 [0089] The mask 90 is shown in greater detail in Figure 11. As discussed above, the 23 registration module 92 may be incorporated into any mask design, and the mask 90 is then 24 programmed to implement a set of instructions or lines of code etc., that will, in part, insert the contents defined in module 92 within a path (preferably one that is critical to the device's 26 operation) between one portion of the customer code 120 and another portion of the 27 customer's code 122. Data that enters the module 92 along path 124 is applied to a 28 cryptographic transform 128 and is output to the portion 122 along path 126. The output 29 present at path 126 will preferably only be usable if the cryptographic transform 128 is successfully applied to the data input at path 124. The cryptographic transform 128 31 preferably works with a memor_v 130, processor 132 and cryptographic key 134 in order to 21534179.1 1 perform its operation. The memory 130, processor 132 and cryptographic key 134 are 2 configured, preferably using the key injection s_ystems 10 present at each manufacturing 3 stage. The memory 130 also includes another cryptographic key 131, which, in general, 4 comprises keying material that is accumulated at each stage, preferably through injection using a key injection system 10 as shown in Figure 10. Preferably, the key 134 is used at 6 injection time to ensure that the material being accumulated in memory 130 to compose the 7 key 131 is authentic. The key 134 may be a public key, and may or may not be needed. For 8 example, the module 92 may work without the key 134, at the potential risk of some classes 9 of attack that may or may not be relevant to the particular producer 12.
100901 In general, the sensitive data used by module 92 is split into portions, each portion 11 being added to key 131 at each stage of the manufacturing process. For example, one 12 technique would be to inject digital signatures with message recovery at each stage in the 13 manufacturing process. The key 134 may be used to validate the digital signature, in doing 14 so; the validated digital signature produces a message that could be used in a key derivation scheme, with existing data in memory 130, to derive a cryptographic key 131.
Another 16 example, would be to employ a key shadowing technique, where pieces of the cryptographic 17 key 131 are added to memory 130 at various manufacturing stages. When the final 18 manufacturing stage has been completed, the memory 130 contains enough data, so that the 19 key shadow technique can be used to re-compose the cryptographic key 131.
100911 An example of the first manufacturing stage 100 is schematically shown in Figure 21 12. As noted above, the producer 12 preferably utilizes system 10 for distributing keying 22 data and for monitoring reports generated when keying occurs. Key injection into a silicon 23 chip typically occurs at wafer test, or during a post packaging test. In this example, stage 100 24 includes a server 18 and key agent 21 operating with testing equipment 20.
The stage 100 also includes production equipment 139 to, e.g., produce a silicon wafer. The production 26 equipment 139 uses the mask 90 distributed over channel 80 to produce a partially 27 manufactured Devicel 140. The subscript 1 in this example is used to represent the first 28 portion of sensitive data that is applied to the device 22, where preferably, the first portion of 29 the sensitive data is injected using the key agent 21 of equipment 20.
Preferably at this point, the Devicel is not yet fully operational, for the reason that the transform 128 does not have all 21534179.1 I the necessary information to perform its operation. The Devicel is then available to be 2 distributed to the second manufacturing stage 102.
3 100921 Figure 13 provides a flow chart showing an example manufacturing process that 4 includes two distinct manufacturing stages (i.e. N=2). At step 500, the producer 12 determines the number of stages, and thus the number of portions of keying data that will be 6 injected, in this example, N=2. At step 502, the producer 12 preferably establishes a key 7 injection system 10 that links each manufacturing stage to itself over the channels 24, 25, and 8 26. As discussed above with reference to Figure 1, the producer 12 may use a single 9 controller 16 to communicate with multiple servers 18. In this example, the producer 12 would distribute, monitor and receive log records from two servers 18.
11 100931 At step 504, the producer 12 incorporates a registration module 92 into its design, 12 defined in the mask 90. The mask 90 is then distributed to the first manufacturer 100 for 13 implementing stage I of the manufacturing process at step 506, and stage 1 is executed at 14 step 508. For example, the first manufacturer will produce a wafer, creating chips that conform to the mask 90. During wafer test, the manufacturer will then program some partial 16 keying material into memory 130. This portion of the sensitive data is inserted at step 510, 17 and the sever 18 would preferably report to the producer at step 512 using the mechanisms 18 outlined above. Altematively, stage I may not handle the injection of any sensitive data, and 19 this operation may then be solely executed during stage 2.
[00941 Once the first portion of the keying data is programmed to the chip or device, the 21 product contains only partial keying information, not sufficient to operate properly. Figure 22 13 is represented by Devicel, wherein the subscript 1 represents the first portion as described 23 above. The partially produced, partially programmed Devicel is then distributed to stage 2 at 24 step 514, for execution at step 516. The manufacturer 102, at step 518 will then inject a second portion of key data. For example, at step 518, the second manufacturer 102 may 26 program additional keying information, or may derive cryptographic keying information 27 using partial key data stored in memory 130 during step 510 and new key data from the 28 system 10 used at step 518. This derivation step could be based on a hash, or possibly a more 29 sophisticated key shadowing technique. Preferably, at step 520, the second manufacturer 102 reports back to the producer 12, indicating that the second key portion was successfully 21534179.1 1 injected. The producer 12 may now possess two log records indicating that the key data has 2 been successfully inserted, and can use this information to monitor its records.
3 [0095] Once the second portion of the keying data is inserted, the device 22, in this 4 example, is completely produced, and completely registered (e.g. tested and packaged IC), and in Figure 13 is represented by Devicel2, wherein the subscript 12 represents the complete 6 set of key data, namely data portion 1 and data portion 2. The Device12 then continues to a 7 distribution channel at step 522 where it eventually arrives at the customer as a working 8 product at step 524.
9 [0096] As also illustrated in Figure 13, if for example, the first manufacturer 100, or an employee thereof, attempts to distribute grey market product at step 526, through an alternate 11 distribution channel at step 528, a crippled product would be provided to the customer at step 12 530, since the Devicel only contains the first portion of the key data, and thus the transform 13 128 cannot perform its operation. Therefore, although the testing, packaging etc. may be 14 performed at grey market stage 2, the additional keying data is not provided, and thus the product 530 is fully manufactured, but not completely registered, rendering it crippled. It 16 will be appreciated that the module 92 is preferably implemented such that anti-tampering 17 means are considered and implemented.
18 100971 Referring now to Figure 14, a schematic example of a fmished customer product 19 22a, incorporating a module 92a is shown, wherein module 92a is a logical manifestation of the physical layout for module 92 shown in Figure 11. In Figure 14, like numerals may be 21 given the suffix "a" for clarity. The product 22a, using the implementation of module 92 22 (e.g. 92a) is able to apply the cryptographic transform 128a, being part of an enforcement 23 block 150, to the product's critical data path between code 120a and 122a.
The path is 24 decoded through the transform 128a so that the customer's logic 122a can properly function.
In this example, a verification 132a, which is an implementation of processor 132, is 26 performed. The verification 132a uses a one-time programmable (OTP) memory 130a and an 27 identity portion 134a, which is an implementation of the key 134 of Figure 11. The key 134a 28 and memory 130a are injected with sensitive data using, e.g. the procedure outlined in Figure 29 13. It will be appreciated that the product 22a is only one implementation incorporating the logic provided by module 92 (e.g. as module 92a), and that the example shown in Figure 14 31 is for illustrative purposes only.
21534179.1
7 100881 Preferably, as shown by way of example in Figure 10, the key injection system 10 8 described above in Figures 1-9 may be used to distribute, meter and solicit reporting of the 9 key injection stages at each manufacturing step. In this case, even if all entities are in collusion to distribute grey market product, the producer 12 will be able to detect this activity 11 due to incomplete log reports, and if necessary inhibit the distribution of further keying data 12 It will be appreciated that altematively, system 10 may be used at any number of stages and 13 need not be used at each or any stage at all. For example, the second stage 102 may utilize 14 the system 10 but not any other stage. However, since preferably each manufacturing stage will include some form of testing procedure, it is beneficial to incorporate system 10 into 16 such testing. The producer 12 in this scenario would at least expect data during the second 17 stage. It will also be appreciated that the module 92 may be used without relying on the 18 system 10 and may rely on each manufacturing stage to implement a portion of the keying 19 process. In any of these situations, by splitting responsibilities, no one entity has the necessary information, on their own, to successfully supply grey markets with product or sub-21 components.
22 [0089] The mask 90 is shown in greater detail in Figure 11. As discussed above, the 23 registration module 92 may be incorporated into any mask design, and the mask 90 is then 24 programmed to implement a set of instructions or lines of code etc., that will, in part, insert the contents defined in module 92 within a path (preferably one that is critical to the device's 26 operation) between one portion of the customer code 120 and another portion of the 27 customer's code 122. Data that enters the module 92 along path 124 is applied to a 28 cryptographic transform 128 and is output to the portion 122 along path 126. The output 29 present at path 126 will preferably only be usable if the cryptographic transform 128 is successfully applied to the data input at path 124. The cryptographic transform 128 31 preferably works with a memor_v 130, processor 132 and cryptographic key 134 in order to 21534179.1 1 perform its operation. The memory 130, processor 132 and cryptographic key 134 are 2 configured, preferably using the key injection s_ystems 10 present at each manufacturing 3 stage. The memory 130 also includes another cryptographic key 131, which, in general, 4 comprises keying material that is accumulated at each stage, preferably through injection using a key injection system 10 as shown in Figure 10. Preferably, the key 134 is used at 6 injection time to ensure that the material being accumulated in memory 130 to compose the 7 key 131 is authentic. The key 134 may be a public key, and may or may not be needed. For 8 example, the module 92 may work without the key 134, at the potential risk of some classes 9 of attack that may or may not be relevant to the particular producer 12.
100901 In general, the sensitive data used by module 92 is split into portions, each portion 11 being added to key 131 at each stage of the manufacturing process. For example, one 12 technique would be to inject digital signatures with message recovery at each stage in the 13 manufacturing process. The key 134 may be used to validate the digital signature, in doing 14 so; the validated digital signature produces a message that could be used in a key derivation scheme, with existing data in memory 130, to derive a cryptographic key 131.
Another 16 example, would be to employ a key shadowing technique, where pieces of the cryptographic 17 key 131 are added to memory 130 at various manufacturing stages. When the final 18 manufacturing stage has been completed, the memory 130 contains enough data, so that the 19 key shadow technique can be used to re-compose the cryptographic key 131.
100911 An example of the first manufacturing stage 100 is schematically shown in Figure 21 12. As noted above, the producer 12 preferably utilizes system 10 for distributing keying 22 data and for monitoring reports generated when keying occurs. Key injection into a silicon 23 chip typically occurs at wafer test, or during a post packaging test. In this example, stage 100 24 includes a server 18 and key agent 21 operating with testing equipment 20.
The stage 100 also includes production equipment 139 to, e.g., produce a silicon wafer. The production 26 equipment 139 uses the mask 90 distributed over channel 80 to produce a partially 27 manufactured Devicel 140. The subscript 1 in this example is used to represent the first 28 portion of sensitive data that is applied to the device 22, where preferably, the first portion of 29 the sensitive data is injected using the key agent 21 of equipment 20.
Preferably at this point, the Devicel is not yet fully operational, for the reason that the transform 128 does not have all 21534179.1 I the necessary information to perform its operation. The Devicel is then available to be 2 distributed to the second manufacturing stage 102.
3 100921 Figure 13 provides a flow chart showing an example manufacturing process that 4 includes two distinct manufacturing stages (i.e. N=2). At step 500, the producer 12 determines the number of stages, and thus the number of portions of keying data that will be 6 injected, in this example, N=2. At step 502, the producer 12 preferably establishes a key 7 injection system 10 that links each manufacturing stage to itself over the channels 24, 25, and 8 26. As discussed above with reference to Figure 1, the producer 12 may use a single 9 controller 16 to communicate with multiple servers 18. In this example, the producer 12 would distribute, monitor and receive log records from two servers 18.
11 100931 At step 504, the producer 12 incorporates a registration module 92 into its design, 12 defined in the mask 90. The mask 90 is then distributed to the first manufacturer 100 for 13 implementing stage I of the manufacturing process at step 506, and stage 1 is executed at 14 step 508. For example, the first manufacturer will produce a wafer, creating chips that conform to the mask 90. During wafer test, the manufacturer will then program some partial 16 keying material into memory 130. This portion of the sensitive data is inserted at step 510, 17 and the sever 18 would preferably report to the producer at step 512 using the mechanisms 18 outlined above. Altematively, stage I may not handle the injection of any sensitive data, and 19 this operation may then be solely executed during stage 2.
[00941 Once the first portion of the keying data is programmed to the chip or device, the 21 product contains only partial keying information, not sufficient to operate properly. Figure 22 13 is represented by Devicel, wherein the subscript 1 represents the first portion as described 23 above. The partially produced, partially programmed Devicel is then distributed to stage 2 at 24 step 514, for execution at step 516. The manufacturer 102, at step 518 will then inject a second portion of key data. For example, at step 518, the second manufacturer 102 may 26 program additional keying information, or may derive cryptographic keying information 27 using partial key data stored in memory 130 during step 510 and new key data from the 28 system 10 used at step 518. This derivation step could be based on a hash, or possibly a more 29 sophisticated key shadowing technique. Preferably, at step 520, the second manufacturer 102 reports back to the producer 12, indicating that the second key portion was successfully 21534179.1 1 injected. The producer 12 may now possess two log records indicating that the key data has 2 been successfully inserted, and can use this information to monitor its records.
3 [0095] Once the second portion of the keying data is inserted, the device 22, in this 4 example, is completely produced, and completely registered (e.g. tested and packaged IC), and in Figure 13 is represented by Devicel2, wherein the subscript 12 represents the complete 6 set of key data, namely data portion 1 and data portion 2. The Device12 then continues to a 7 distribution channel at step 522 where it eventually arrives at the customer as a working 8 product at step 524.
9 [0096] As also illustrated in Figure 13, if for example, the first manufacturer 100, or an employee thereof, attempts to distribute grey market product at step 526, through an alternate 11 distribution channel at step 528, a crippled product would be provided to the customer at step 12 530, since the Devicel only contains the first portion of the key data, and thus the transform 13 128 cannot perform its operation. Therefore, although the testing, packaging etc. may be 14 performed at grey market stage 2, the additional keying data is not provided, and thus the product 530 is fully manufactured, but not completely registered, rendering it crippled. It 16 will be appreciated that the module 92 is preferably implemented such that anti-tampering 17 means are considered and implemented.
18 100971 Referring now to Figure 14, a schematic example of a fmished customer product 19 22a, incorporating a module 92a is shown, wherein module 92a is a logical manifestation of the physical layout for module 92 shown in Figure 11. In Figure 14, like numerals may be 21 given the suffix "a" for clarity. The product 22a, using the implementation of module 92 22 (e.g. 92a) is able to apply the cryptographic transform 128a, being part of an enforcement 23 block 150, to the product's critical data path between code 120a and 122a.
The path is 24 decoded through the transform 128a so that the customer's logic 122a can properly function.
In this example, a verification 132a, which is an implementation of processor 132, is 26 performed. The verification 132a uses a one-time programmable (OTP) memory 130a and an 27 identity portion 134a, which is an implementation of the key 134 of Figure 11. The key 134a 28 and memory 130a are injected with sensitive data using, e.g. the procedure outlined in Figure 29 13. It will be appreciated that the product 22a is only one implementation incorporating the logic provided by module 92 (e.g. as module 92a), and that the example shown in Figure 14 31 is for illustrative purposes only.
21534179.1
-25-1 100981 Although the above has been described with reference to certain specific 2 embodiments, various modifications thereof will be apparent to those skilled in the art.
21534179.1
21534179.1
- 26 -
Claims (76)
1. A method for controlling insertion of sensitive data into devices, said method comprising:
arranging a server to be communicably connectable to a controller responsible for distributing said sensitive data and equipment responsible for injecting said sensitive data into said devices according to an existing data injection solution, said server being located remote from said controller, and said server comprising a secure module for performing cryptographic operations;
receiving from said controller, a cryptographically protected data transmission comprising said sensitive data;
receiving from said controller, an object for accommodating said existing data injection solution, said object having been signed;
verifying said signed object;
modifying said sensitive data received from said controller according to said signed object to accommodate said existing solution if said signed object is verified; and said server sending modified sensitive data to said equipment for injection into one or more devices in accordance with said existing data injection solution.
arranging a server to be communicably connectable to a controller responsible for distributing said sensitive data and equipment responsible for injecting said sensitive data into said devices according to an existing data injection solution, said server being located remote from said controller, and said server comprising a secure module for performing cryptographic operations;
receiving from said controller, a cryptographically protected data transmission comprising said sensitive data;
receiving from said controller, an object for accommodating said existing data injection solution, said object having been signed;
verifying said signed object;
modifying said sensitive data received from said controller according to said signed object to accommodate said existing solution if said signed object is verified; and said server sending modified sensitive data to said equipment for injection into one or more devices in accordance with said existing data injection solution.
2. The method according to claim 1, further comprising receiving an equipment log report indicative of insertion of said modified sensitive data into said one or more devices.
3. The method according to claim 1 or claim 2, further comprising:
storing a credit value provided by said controller indicative of a number of sensitive data insertions that are permitted before requesting more of said sensitive data from said controller;
referencing said credit value and providing an amount of said modified sensitive data to said equipment for injection into said one or more devices according to said credit value; and if said amount is less than said credit value, updating said credit value according to said amount.
storing a credit value provided by said controller indicative of a number of sensitive data insertions that are permitted before requesting more of said sensitive data from said controller;
referencing said credit value and providing an amount of said modified sensitive data to said equipment for injection into said one or more devices according to said credit value; and if said amount is less than said credit value, updating said credit value according to said amount.
4. The method according to claim 2 or claim 3, further comprising sending said equipment log report to said controller.
5. The method according to any one of claims 1 to 4, further comprising preparing a server log report regarding obtaining said sensitive data from said controller, and said server sending said server log report to said controller.
6. The method according to claim 5, wherein said server log report is provided to said controller in response to a poll initiated by one of said server and said controller.
7. The method according to claim 5 or claim 6, wherein said server log report is provided to said controller for obtaining additional sensitive data wherein, a further data transmission is received if said log report is favourable and additional sensitive data is required.
8. The method according to claim 7, wherein said server receives from said controller, an instruction to inhibit further extraction of one or more of said plurality of types of sensitive data if said log report is not favourable.
9. The method according to any one of claims 1 to 8, wherein said extracting comprises decrypting a header included in said data transmission to obtain a key, and using said key to decrypt said transmission and extract said sensitive data therefrom.
10. The method according to any one of claims 1 to 9, further comprising executing a provisioning procedure prior to receiving said sensitive data from said controller, said provisioning procedure being used to initialize said server and said secure module.
11. The method according to any one of claims 1 to 10 comprising a plurality of servers, wherein said data transmission is sent to said plurality of servers.
12. The method according to any one of claims 3 to 11, further comprising receiving a credit instruction from said controller indicating an update for said credit value.
13. The method according to any one of claims 1 to 12, further comprising receiving a configuration message from said controller for use in modifying settings in said secure module.
14. The method according to any one of claims 1 to 13, wherein said sensitive data comprises a plurality of keys; and said extracting comprises decrypting a quantity of said keys as indicated by instructions provided by said controller apriori.
15. The method according to claim 14, wherein said secure module decrypts keys upon receipt thereof and individually re-encrypts each key; and wherein certain ones of said keys are decrypted for use by said equipment upon a request made by said equipment.
16. The method according to any one of claims 1 to 15, wherein said secure module contains a symmetric key for communicating over forward and backward communication channels between said server and said controller.
17. The method according to any one of claims 1 to 16, wherein said cryptographically protected data transmission comprises a quantity of each of a plurality of types of sensitive data, said method further comprising:
receiving a request from said equipment for sensitive data for a product type;
extracting from said cryptographically protected data transmission, one or more of said plurality of types of sensitive data according to said product type; and providing said one or more of said plurality of types of sensitive data to said equipment.
receiving a request from said equipment for sensitive data for a product type;
extracting from said cryptographically protected data transmission, one or more of said plurality of types of sensitive data according to said product type; and providing said one or more of said plurality of types of sensitive data to said equipment.
18. The method according to claim 17, wherein said equipment has permission to obtain sensitive data for fewer than all product types that can be produced using said plurality of types of sensitive data.
19. The method according to claim 17 or claim 18, further comprising providing to said controller, an indication of which one or more of said plurality of types of sensitive data have been provided by said secure module to said equipment.
20. A server system for controlling insertion of sensitive data into devices, said system comprising:
a server communicably connectable to a controller responsible for distributing said sensitive data and equipment responsible for injecting said sensitive data into said devices according to an existing data injection solution, said server being located remote from said controller, said server comprising a secure module for performing cryptographic operations and being configured for:
arranging said server to be communicably connectable to a controller responsible for distributing said sensitive data and equipment responsible for injecting said sensitive data into said devices, said server being located remote from said controller, and said server comprising a secure module for performing cryptographic operations;
receiving from said controller, a cryptographically protected data transmission comprising said sensitive data;
receiving from said controller, an object for accommodating said existing data injection solution, said object having been signed;
verifying said signed object;
modifying said sensitive data received from said controller according to said signed object to accommodate said existing solution if said signed object is verified; and said server sending modified sensitive data to said equipment for injection into one or more devices in accordance with said existing data injection solution.
a server communicably connectable to a controller responsible for distributing said sensitive data and equipment responsible for injecting said sensitive data into said devices according to an existing data injection solution, said server being located remote from said controller, said server comprising a secure module for performing cryptographic operations and being configured for:
arranging said server to be communicably connectable to a controller responsible for distributing said sensitive data and equipment responsible for injecting said sensitive data into said devices, said server being located remote from said controller, and said server comprising a secure module for performing cryptographic operations;
receiving from said controller, a cryptographically protected data transmission comprising said sensitive data;
receiving from said controller, an object for accommodating said existing data injection solution, said object having been signed;
verifying said signed object;
modifying said sensitive data received from said controller according to said signed object to accommodate said existing solution if said signed object is verified; and said server sending modified sensitive data to said equipment for injection into one or more devices in accordance with said existing data injection solution.
21. The system according to claim 20, further configured for receiving an equipment log report indicative of insertion of said modified sensitive data into said one or more devices.
22. The system according to claim 20 or claim 21, further configured for:
storing a credit value provided by said controller indicative of a number of sensitive data insertions that are permitted before requesting more of said sensitive data from said controller;
referencing said credit value and providing an amount of said modified sensitive data to said equipment for injection into said one or more devices according to said credit value; and if said amount is less than said credit value, updating said credit value according to said amount.
storing a credit value provided by said controller indicative of a number of sensitive data insertions that are permitted before requesting more of said sensitive data from said controller;
referencing said credit value and providing an amount of said modified sensitive data to said equipment for injection into said one or more devices according to said credit value; and if said amount is less than said credit value, updating said credit value according to said amount.
23. The system according to claim 21 or claim 22, further configured for sending said equipment log report to said controller.
24. The system according to any one of claims 20 to 23, further configured for preparing a server log report regarding obtaining said sensitive data from said controller, and said server sending said server log report to said controller.
25. The system according to claim 24, wherein said server log report is provided to said controller in response to a poll initiated by one of said server and said controller.
26. The system according to claim 24 or claim 25, wherein said server log report is provided to said controller for obtaining additional sensitive data wherein, a further data transmission is received if said log report is favourable and additional sensitive data is required.
27. The system according to claim 26, wherein said server receives from said controller, an instruction to inhibit further extraction of one or more of said plurality of types of sensitive data if said log report is not favourable.
28. The system according to any one of claims 20 to 27, wherein said extracting comprises decrypting a header included in said data transmission to obtain a key, and using said key to decrypt said transmission and extract said sensitive data therefrom.
29. The system according to any one of claims 20 to 28, further configured for executing a provisioning procedure prior to receiving said sensitive data from said controller, said provisioning procedure being used to initialize said server and said secure module.
30. The system according to any one of claims 20 to 29 comprising a plurality of servers, wherein said data transmission is sent to said plurality of servers.
31. The system according to any one of claims 22 to 30, further configured for receiving a credit instruction from said controller indicating an update for said credit value.
32. The system according to any one of claims 20 to 31, further configured for receiving a configuration message from said controller for use in modifying settings in said secure module.
33. The system according to any one of claims 20 to 32, wherein said sensitive data comprises a plurality of keys; and said extracting comprises decrypting a quantity of said keys as indicated by instructions provided by said controller apriori.
34. The system according to claim 33, wherein said secure module decrypts keys upon receipt thereof and individually re-encrypts each key; and wherein certain ones of said keys are decrypted for use by said equipment upon a request made by said equipment.
35. The system according to any one of claims 20 to 34, wherein said secure module contains a symmetric key for communicating over forward and backward communication channels between said server and said controller.
36. The system according to any one of claims 20 to 35, wherein said cryptographically protected data transmission comprises a quantity of each of a plurality of types of sensitive data, said system further configured for:
receiving a request from said equipment for sensitive data for a product type;
extracting from said cryptographically protected data transmission, one or more of said plurality of types of sensitive data according to said product type; and providing said one or more of said plurality of types of sensitive data to said equipment.
receiving a request from said equipment for sensitive data for a product type;
extracting from said cryptographically protected data transmission, one or more of said plurality of types of sensitive data according to said product type; and providing said one or more of said plurality of types of sensitive data to said equipment.
37. The system according to claim 36, wherein said equipment has permission to obtain sensitive data for fewer than all product types that can be produced using said plurality of types of sensitive data.
38. The system according to claim 36 or claim 37, further configured for providing to said controller, an indication of which one or more of said plurality of types of sensitive data have been provided by said secure module to said equipment.
39. A method for controlling insertion of sensitive data into devices, said method comprising:
arranging a controller to be communicably connectable to a server being located remote therefrom and configured to be communicably connectable to equipment responsible for injecting said sensitive data into said devices according to an existing data injection solution, said controller being configured for distributing said sensitive data to said server to enable said server to provide modified sensitive data to said equipment to accommodate said existing data injection solution, said controller comprising a secure module for performing cryptographic operations;
sending to said server, a cryptographically protected data transmission comprising said sensitive data;
obtaining an object for accommodating said existing data injection solution;
signing said object to generate a signed object; and sending said signed object to said server to enable said server to verify said signed object, modify said sensitive data sent by said controller according to said signed object to accommodate said existing solution if said signed object is verified, and send said modified sensitive data to said equipment for injection into one or more devices in accordance with said existing data injection solution.
arranging a controller to be communicably connectable to a server being located remote therefrom and configured to be communicably connectable to equipment responsible for injecting said sensitive data into said devices according to an existing data injection solution, said controller being configured for distributing said sensitive data to said server to enable said server to provide modified sensitive data to said equipment to accommodate said existing data injection solution, said controller comprising a secure module for performing cryptographic operations;
sending to said server, a cryptographically protected data transmission comprising said sensitive data;
obtaining an object for accommodating said existing data injection solution;
signing said object to generate a signed object; and sending said signed object to said server to enable said server to verify said signed object, modify said sensitive data sent by said controller according to said signed object to accommodate said existing solution if said signed object is verified, and send said modified sensitive data to said equipment for injection into one or more devices in accordance with said existing data injection solution.
40. The method according to claim 39, further comprising receiving an equipment log report indicative of insertion of said modified sensitive data into said one or more devices.
41. The method according to claim 39 or claim 40, further comprising:
sending a credit value to said server indicative of a number of sensitive data insertions that are permitted before requesting more of said sensitive data from said controller to enable said server to reference said credit value and provide an amount of said modified sensitive data to said equipment for injection into said one or more devices according to said credit value, wherein if said amount is less than said credit value said credit value is updated according to said amount.
sending a credit value to said server indicative of a number of sensitive data insertions that are permitted before requesting more of said sensitive data from said controller to enable said server to reference said credit value and provide an amount of said modified sensitive data to said equipment for injection into said one or more devices according to said credit value, wherein if said amount is less than said credit value said credit value is updated according to said amount.
42. The method according to claim 40 or claim 41, further comprising receiving said equipment log report from said server.
43. The method according to any one of claims 39 to 42, further comprising receiving from said server, a server log report regarding obtaining said sensitive data from said controller.
44. The method according to claim 43, wherein said server log report is received by said controller in response to a poll initiated by one of said server and said controller.
45. The method according to claim 43 or claim 44, wherein said server log report is provided to said controller for obtaining additional sensitive data, wherein a further data transmission is sent by said controller if said log report is favourable and additional sensitive data is required,
46. The method according to claim 45, wherein said controller sends to said server, an instruction to inhibit further extraction of one or more of said plurality of types of sensitive data if said log report is not favourable.
47. The method according to any one of claims 39 to 46, wherein a header of said data transmission encrypts a key, wherein said server decrypts said header to obtain said key to use said key to decrypt said transmission and extract said sensitive data therefrom.
48. The method according to any one of claims 39 to 47, further comprising initiating a provisioning procedure prior to sending said sensitive data to said server, said provisioning procedure being used to initialize said server and said secure module.
49. The method according to any one of claims 39 to 48 comprising a plurality of servers, wherein said data transmission is sent to said plurality of servers.
50. The method according to any one of claims 42 to 49, further comprising sending a credit instruction to said server indicating an update for said credit value.
51. The method according to any one of claims 39 to 50, further comprising sending a configuration message to said server for use in modifying settings in a secure module of said server.
52. The method according to any one of claims 39 to 51, wherein said sensitive data comprises a plurality of keys; wherein said server decrypts a quantity of said keys as indicated by instructions provided by said controller apriori.
53. The method according to any one of claims 39 to 52, wherein said secure module contains a symmetric key for communicating over forward and backward communication channels between said controller and said server.
54. The method according to any one of claims 39 to 53, wherein said cryptographically protected data transmission comprises a quantity of each of a plurality of types of sensitive data, wherein said server receives a request from said equipment for sensitive data for a product type, extracts from said cryptographically protected data transmission, one or more of said plurality of types of sensitive data according to said product type, and provides said one or more of said plurality of types of sensitive data to said equipment.
55. The method according to claim 54, wherein said equipment has permission to obtain sensitive data for fewer than all product types that can be produced using said plurality of types of sensitive data.
56. The method according to claim 54 or claim 55, further comprising receiving from said server, an indication of which one or more of said plurality of types of sensitive data have been provided by said secure module to said equipment.
57. A system for controlling insertion of sensitive data into devices, said system comprising:
a controller device communicably connectable to a server being located remote therefrom and configured to be communicably connectable to equipment responsible for injecting said sensitive data into said devices according to an existing data injection solution, said controller device being configured for distributing said sensitive data to said server to enable said server to provide modified sensitive data to said equipment to accommodate said existing data injection solution, said controller device comprising a secure module for performing cryptographic operations;
said controller device being configured for:
sending to said server, a cryptographically protected data transmission comprising said sensitive data;
obtaining an object for accommodating said existing data injection solution;
signing said object to generate a signed object; and sending said signed object to said server to enable said server to verify said signed object, modify said sensitive data sent by said controller according to said signed object to accommodate said existing solution if said signed object is verified, and send said modified sensitive data to said equipment for injection into one or more devices in accordance with said existing data injection solution.
a controller device communicably connectable to a server being located remote therefrom and configured to be communicably connectable to equipment responsible for injecting said sensitive data into said devices according to an existing data injection solution, said controller device being configured for distributing said sensitive data to said server to enable said server to provide modified sensitive data to said equipment to accommodate said existing data injection solution, said controller device comprising a secure module for performing cryptographic operations;
said controller device being configured for:
sending to said server, a cryptographically protected data transmission comprising said sensitive data;
obtaining an object for accommodating said existing data injection solution;
signing said object to generate a signed object; and sending said signed object to said server to enable said server to verify said signed object, modify said sensitive data sent by said controller according to said signed object to accommodate said existing solution if said signed object is verified, and send said modified sensitive data to said equipment for injection into one or more devices in accordance with said existing data injection solution.
58. The system according to claim 57, further configured for receiving an equipment log report indicative of insertion of said modified sensitive data into said one or more devices.
59. The system according to claim 57 or claim 58, further configured for:
sending a credit value to said server indicative of a number of sensitive data insertions that are permitted before requesting more of said sensitive data from said controller to enable said server to reference said credit value and provide an amount of said modified sensitive data to said equipment for injection into said one or more devices according to said credit value, wherein if said amount is less than said credit value said credit value is updated according to said amount.
sending a credit value to said server indicative of a number of sensitive data insertions that are permitted before requesting more of said sensitive data from said controller to enable said server to reference said credit value and provide an amount of said modified sensitive data to said equipment for injection into said one or more devices according to said credit value, wherein if said amount is less than said credit value said credit value is updated according to said amount.
60. The system according to claim 58 or claim 59, further configured for receiving said equipment log report from said server.
61. The system according to any one of claims 57 to 60, further configured for receiving from said server, a server log report regarding obtaining said sensitive data from said controller.
62. The system according to claim 61, wherein said server log report is received by said controller in response to a poll initiated by one of said server and said controller.
63. The system according to claim 61 or claim 62, wherein said server log report is provided to said controller for obtaining additional sensitive data, wherein a further data transmission is sent by said controller if said log report is favourable and additional sensitive data is required.
64. The system according to claim 63, wherein said controller sends to said server, an instruction to inhibit further extraction of one or more of said plurality of types of sensitive data if said log report is not favourable.
65. The system according to any one of claims 57 to 54, wherein a header of said data transmission encrypts a key, wherein said server decrypts said header to obtain said key to use said key to decrypt said transmission and extract said sensitive data therefrom.
66. The system according to any one of claims 57 to 65, further configured for initiating a provisioning procedure prior to sending said sensitive data to said server, said provisioning procedure being used to initialize said server and said secure module.
67. The system according to any one of claims 57 to 66 comprising a plurality of servers, wherein said data transmission is sent to said plurality of servers.
68. The system according to any one of claims 60 to 67, further configured for sending a credit instruction to said server indicating an update for said credit value.
69. The system according to any one of claims 57 to 68, further configured for sending a configuration message to said server for use in modifying settings in a secure module of said server.
70. The system according to any one of claims 57 to 69, wherein said sensitive data comprises a plurality of keys; wherein said server decrypts a quantity of said keys as indicated by instructions provided by said controller apriori.
71. The system according to any one of claims 57 to 70, wherein said secure module contains a symmetric key for communicating over forward and backward communication channels between said controller and said server.
72. The system according to any one of claims 57 to 71, wherein said cryptographically protected data transmission comprises a quantity of each of a plurality of types of sensitive data, wherein said server receives a request from said equipment for sensitive data for a product type, extracts from said cryptographically protected data transmission, one or more of said plurality of types of sensitive data according to said product type, and provides said one or more of said plurality of types of sensitive data to said equipment.
73. The system according to claim 72, wherein said equipment has permission to obtain sensitive data for fewer than all product types that can be produced using said plurality of types of sensitive data.
74. The system according to claim 72 or claim 73, further configured for receiving from said server, an indication of which one or more of said plurality of types of sensitive data have been provided by said secure module to said equipment.
75. A computer readable medium comprising computer executable instructions for performing the method of any one of claims 1 to 19.
76. A computer readable medium comprising computer executable instructions for performing the method of any one of claims 39 to 56.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CA2611818A CA2611818C (en) | 2005-06-14 | 2006-06-12 | System and method for remote device registration |
Applications Claiming Priority (10)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US69015505P | 2005-06-14 | 2005-06-14 | |
US60/690,155 | 2005-06-14 | ||
CA2510366A CA2510366C (en) | 2005-06-14 | 2005-06-21 | System and method for remote device registration |
CA2,510,366 | 2005-06-21 | ||
US77726206P | 2006-02-28 | 2006-02-28 | |
CA2,538,087 | 2006-02-28 | ||
CA2538087A CA2538087C (en) | 2005-06-14 | 2006-02-28 | System and method for remote device registration |
US60/777,262 | 2006-02-28 | ||
CA2611818A CA2611818C (en) | 2005-06-14 | 2006-06-12 | System and method for remote device registration |
PCT/CA2006/000944 WO2006133545A1 (en) | 2005-06-14 | 2006-06-12 | System and method for remote device registration |
Publications (2)
Publication Number | Publication Date |
---|---|
CA2611818A1 CA2611818A1 (en) | 2006-12-21 |
CA2611818C true CA2611818C (en) | 2015-12-29 |
Family
ID=39153753
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA2611818A Active CA2611818C (en) | 2005-06-14 | 2006-06-12 | System and method for remote device registration |
Country Status (1)
Country | Link |
---|---|
CA (1) | CA2611818C (en) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2689598B1 (en) | 2011-03-25 | 2015-11-25 | Certicom Corp. | Interrogating an authentication device |
CN103503366B (en) | 2011-05-06 | 2016-10-12 | 塞尔蒂卡姆公司 | Manage the data for authenticating device |
US9369290B2 (en) | 2012-11-30 | 2016-06-14 | Certicom Corp. | Challenge-response authentication using a masked response value |
US9727720B2 (en) | 2012-11-30 | 2017-08-08 | Certicom Corp. | Challenge-response authentication using a masked response value |
CN112366249B (en) * | 2020-11-16 | 2023-10-20 | 理想万里晖半导体设备(上海)股份有限公司 | Solar cell manufacturing method with tracking function and tracking system used by solar cell manufacturing method |
-
2006
- 2006-06-12 CA CA2611818A patent/CA2611818C/en active Active
Also Published As
Publication number | Publication date |
---|---|
CA2611818A1 (en) | 2006-12-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2538087C (en) | System and method for remote device registration | |
CA2642363C (en) | System and method for product registration | |
US20190370159A1 (en) | System and method for managing electronic assets | |
US10102500B2 (en) | System and method for performing serialization of devices | |
CA2611818C (en) | System and method for remote device registration | |
JP4989806B2 (en) | System and method for remote device registration | |
KR101336529B1 (en) | System and method for remote device registration | |
US20210334085A1 (en) | Systems and methods for secure over-the-air updates for cyber-physical systems | |
CN102013977B (en) | System and method for remote device registration | |
JP2012113323A (en) | System and method for remote device registration |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request |