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

Abstract

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

Description

System and method for remote device registration

The present invention relates to the production of devices with critical data, and more particularly to the remote control and monitoring of critical data injection inside the device.

Devices included in cryptographic secure communication systems typically have some unique and unaltered information injected during production. This information can be cryptographic keys, distributed security or other data that encrypts the inherently unique attributes on the device. The information is generally referred to as "key" and the injection of information is referred to as "keying" or "key injection."

The purpose of key injection is to assure that after the device is distributed, the device will be accepted as an authentication participant in a secure communication system at some point in the future. However, the manufacturer of the device will want the device to be produced legally and want to protect the keys that are injected into the device. Since key authentication is used to regulate access to the security system and its contents, producers will typically aim for key protection to protect future revenue. The injected key is also important in enabling the consumer or user of the device to avoid the tedious process required to register the device.

The device will control access to the system based on cryptographic authentication in which the key is trusted. This trust is based on the fact that it is difficult to reproduce trust data outside the production process. Systems that access satellite television, radio, and a series of systems constantly want to provide broadcast information and control access to the content and revenues to provide to that content. Such systems rely on the production process and product production (OEM) under the orderer's brand, in particular on key injection, which provides a source of trust for the device, and also on the overall safety communication system.

Keys injected into the device are usually in standard form and are purchased from the operating system. For example, HDCP (High Definition Content Protection) keys are used to protect the data transmitted by the cable from the PC to the monitor. The operating system is also interested in assuring that keys distributed to device manufacturers are protected and not lost. This adds responsibility to the producer, thus increasing the importance of injection key protection. In some cases, producers can be penalized by losing or copying a key, and the operating system will restrict or be cautious if it is reputed to be negligent in handling the key. Maintaining this relationship is often important to the producer, especially when the key is a standard format required for equipment compatible with other devices and / or sub-devices. In such a case, the device will not operate intentionally without using a special key.

In the modern business world of increasing complexity and difficulty, it is common for independent parts to be produced, keyed by one manufacturer, and then assembled by another. In this situation, when the device producer or the owner of the communication system is not the same as the device manufacturer, there is certain and safe reasoning. Therefore, it may be a major problem for the device producer to ensure the completeness necessary to build a system responsible for the integrity of the producer device.

When considering the preservation of the manufacturing process, particular attention is concerned with the confidentiality of the secure information used to manufacture the device, the manufacturer correctly describing the identity and describing the multiple units produced to the producer. Ideally, the device producer should strive to gain confidence that the manufacturer will not create and distribute "gray" or "black" (black) on the market or device. For example, a producer who has returned several encrypted items to a producer will have the remaining key, and will produce and sell the device with the extra key. The producer loses the revenue because the producer profits from the sale. Actions such as the loss or duplication of keys also occur when the encryption process takes place externally, and it is difficult to detect and control them. In another case, a key can be generated on the Internet to allow a user to gain access to a regulatory system without paying for certain services.

Typically, producers who are interested in protecting the information injection stage at the shop floor have absolutely confidence that the manufacturer operates in a way that attaches importance to producer device and system security. Protection mechanisms are generally inexperienced, where key information is typically encrypted and sent to the producer, all key information is immediately decrypted upon arrival, and the producer is not trusted in compromising a lot of information.

One way to restrict access to key information is to use an online client-server mechanism. With this mechanism, the client, for convenience of the producer, is connected to the network, performs an information encryption request to the device, and is connected to a remote key providing server under the producer's control.

There are a number of problems in building a production system that rely on off-site, remote network servers that provide key information such as a barely timely basis. The main problem is that the off-site server cannot guarantee the minimum service level when using an air split packet switch network, and cannot respond to the time required for line production. In order to prevent problems in the production line, the level of service should be appropriate with respect to the amount of work that can be done in a potential and timely manner. Given the current production reality, production lines exist as producers and remote jurisdictions, and the network facilities that protect them are quite expensive.

The manufacturing facility typically cannot start production without preparing all the necessary materials except the data material. In contrast, the risk for production line delay is quite high. The key system used by the producer must inherently protect the service capability and be able to provide appropriate responses. This requires the local possibility of all data resources and key information before the start of the production run.

All data resources can be locally connected to the production line, residing in computer systems, and connected to media under the direct control of the producer, but the producer must consider how to ensure the confidentiality of any security key information.

In order to start and complete the production run, sufficient data must be available locally by the producer. If a producer finds an unauthorized producer's behavior unauthorized, the producer should consider how to prevent the evil producer from producing black market products after the contract is terminated.

Other issues related to cloning begin with mass production, and the clear way of cloning is of particular interest to silicon chip producers. Mass production occurs when the producer of an integrated circuit (IC) outsources the manufacture of integrated circuit designs to one or more manufacturing companies. The purpose of outsourcing or any stage of production is to lower the cost of production by selecting a third party that can suggest the optimal cost to perform a particular stage in the production process. For example, a fabricless design house (producer) would want to create convenience overseas to make a designed chip. This overseas production convenience is selected when electronic components can be produced at relatively low cost.

However, outsourcing generally increases the risk of a specific contractor mass producing a product, and a production contract is being made to supply a black market. For example, if a contract manufacturer acts with poor trust to produce integrated circuits from a design provided by a producer, the producer may not be informed that mass production occurs, and the extra product is black forged as a "counterfeiting" or "cloning" product. Will be sold to the market. This allows other producers to implement separate revenue at the cost of product demand and revenue for their consumers, namely producers and designers.

The above occurs because in the scenario the producer handles the product at the beginning of production without receiving a technical sample. Thus, at each stage of the manufacturing process, after the design, there is an opportunity to steal products and personnel. In such a case, the person hired by a good trust contract maker can be a thief. "Reduced output" occurs, at which time the employee steals the product directly from the production line. This can be detrimental not only to producers and contract producers due to low profits, but also to relationships between producers and producers for future business operations.

After all, it is an object of the present invention to obviate or eliminate the problems discussed above.

The present invention provides systems and methods that allow producers to use separate entities for at least some areas of the production process and to monitor and protect the production of devices from telescopes.

The present invention also provides a means of separating the addition of sensitive data to a product between separate individuals to prevent black market due to overproduction and shortage of goods.

The present invention provides a method comprising the steps of: an adjuster preparing and sensitively protecting the sensitive data in transmission data; The controller sending a data transmission to a server, the server including a security module to perform an encryption operation; The safety module extracting the sensitive data from a data transmission; The server providing the sensitive data to equipment for injection into the device; It is configured to include, the controller provides a remote device registration method, characterized in that located at a distance from the server.

The present invention provides a controller comprising a first safety module for performing an encryption operation; A server located remotely from the regulator, the server being connected by front and rear channels; The front end channel is used by the controller to provide data transmission to a second secure module of the server, the data transmission protects the sensitive data in an encrypted manner, and the second secure module extracts the data from the transmission. An agent drawing with the equipment used for the injection of said data extracted from said transmission and obtaining said data from said second safety module; It provides a remote device registration system, characterized in that configured to include.

The present invention provides an encryption variant for interrupting and modifying the data flow in a device and an encryption key stored in memory and an area of sensitive data added to each encryption key at each stage, and operation of the encryption key requested for successful operation of the encryption variant. A module for controlling the insertion of sensitive data in a device at a plurality of stages comprising: the device for controlling insertion of sensitive data in a device, characterized in that for performing a successful operation of the encryption variant. to provide.

The present invention includes a module in the device, the module having an encryption variant for interrupting and modifying data flow in the device; Adding an area of sensitive data to an encryption key stored in the module memory at each of a plurality of stages in production of the device, wherein the encryption key operation is required for successful operation of the encryption variant; A method for adjusting the insertion of sensitive data in a device comprising: the device provides a method for adjusting the insertion of sensitive data in a device, characterized in that for enabling the successful operation of the encryption transformation.

Embodiments of the invention may be described by way of example related to the accompanying drawings.

1 is a block diagram of a remote device registration system;

2 illustrates the graphical user interface described in FIG. 1;

3 shows a distribution image;

4 is a flow chart illustrating a key injection and reporting procedure;

5 is a flowchart illustrating a preparation procedure;

6 is a flow chart illustrating a credit indication procedure;

7 is a mapping diagram of another embodiment for supporting a plurality of products;

8 illustrates one embodiment of a filtered log report;

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

10 is a key injection implementation block diagram using multiple stages in the production process;

11 illustrates a mask registration module for separating a key injection stage using the embodiment of FIG. 10;

12 is a stage start view shown in the embodiment of FIG. 10;

13 is a flow chart showing the steps of producing a device using the embodiment of FIG.

FIG. 14 is an embodiment block diagram of an article produced from the mask shown in FIG.

As shown in FIG. 1, the remote device 22 registration or trust key injection system 10 is generally represented by a formula. The producer 12 of the device 22 uses a separate body service, and in the case of the outsourced producer 14, it injects unique and unchanged information into the device 22. The information may be an encryption key, a distribution secret, or various data actually required for the device 22, which will be referred to as a "key" hereinafter. The step of injecting a key into the device 22 is hereinafter referred to as "keying" or "key injecting".

The producer 12 uses a regulator 16, which is a computer system 10 remote from the facility of the producer 14. The regulator 16 includes a hardware safety module (hereinafter referred to as "HSM 11"). HSM 11 is a protective device 22 used by regulator 16 to perform cryptographically secure operations such as encryption, decryption, and signing. The HSM 11 is hard to ride (physically difficult to access) or susceptible to damage (delete data in case of damage). The regulator 16 is responsible for packaging and delivering keys and other information to the producer 14 as well as monitoring key distribution and usage by the producer 14. Producer 12 typically obtains a number of keys (not shown) from external resources, such as an operating system (e.g., producer 12 of HDCP keys). The key is stored in the data storage device 22 until it is distributed to a particular producer 14. The regulator 16 and its operation can be monitored, modified and controlled by a graphical user interface (hereinafter referred to as "GUI 13"). The GUI 13 is a software application that is usually used and displayed by a personal computer (not shown).

The regulator 16 is connected to a server 18 present to the producer 14 via a pipeline 23. Pipeline 23 includes two front and rear channels 24 corresponding to control channel 26 and distribution channel 25. The control channel 26 is used by the regulator 16 to process several keys used by the producer 14 to convey credit instructions. The distribution channel 25 is used by the regulator 16 to distribute a protective block key to the producer 14. The trailing channel 24 is used by the system 10 to allow the regulator 16 to know key usage for reporting and auditing purposes. Each channel is an arbitrary communication channel and no trust or security is required. Trust and safety for each channel are used to mix technical mechanisms and processes. For example, if a message sent through the front end channel 26 to the module cannot be decrypted due to immorality, the user can call the system 10 regulator 16 operator to send the message again.

The producer 14 uses one or more servers 18, which are connected locally to the producer 14 facility, whose activity is via a message sent by the regulator 16. Are monitored and measured. Server 18 will also reply to regulator 16 via a back channel 24. The server 18 includes an HSM 28 similar to the HSM 11 used by the regulator 16. HSM 28 stores a credit credit pool that determines how many keys the producer 14 uses. The use of the key is measured by the regulator 16 by monitoring the data reported by the server 18 and being added or subtracted by the credit pool. The credit pool is an abstract concept representing a key that can be decrypted by the HSM 28 before the server 18 requests and obtains more keys from the regulator 16. The regulator 16 distributes the keys to the server 18 via the distribution channel 25, and the server 18 stores the keys in the local data store 15 as described below.

The producer 14 uses one or more equipment 20 used to inject an encryption key into the device 22. Typically, key injection occurs in the test state of the manufacturing process, so the equipment 20 is often a test machine on an assembly line. The equipment 20 typically includes a key agent 21 corresponding to software or toolkit that is moved to the equipment 20 used to manage key injection in terms of use. The key agent 21 is in communication with a server 18 for requesting and obtaining a key if necessary. Normally, server 18 provides sufficient keys to key agent 21 in order not to disturb the time of the production process. However, server 18 will not provide an unnecessary number of keys to limit key usage until key injection is provided by regulator 16 as measured through the credit pool.

Typically, when a new key is needed by a particular piece of equipment 20 so as not to interfere with production, the key agent 21 will have a reference level indicating it. Since the regulator 16 is not in constant communication with the server 18, the regulator 16 adjusts its parameters to ensure that sufficient key injection material is supplied to the equipment 20 through the server 18. The controller 16 ensures that too much key data is not leaked by the server 18 before the controller 16 obtains the key usage report from the server 18.

The key agent 21 includes an application program interface (hereinafter referred to as "API") that operates on the equipment 20 so that the equipment 20 operator can request a key on his own, which is done in a manual or automatic manner. The key agent 21 is used to provide a level of protection for data traveling between the server 18 and the equipment 20, and a simplified secure socket layer (hereinafter referred to as "SSL") between the server 18 and the equipment 20. Can be thought of as a connection. It supplies resources and can be recognized that the key agent 21 also uses an SSL connection with the server 18. The key agent 21 serves to record the key as it is used and return the purpose to the server 18.

The regulator 16 is a command center for monitoring and measuring key injection by the manufacturer 14. To control key injection at a distance, the GUI 13 is used by the operator 14 monitoring the manufacturer 14, the server 18 and the equipment 20 under the control of the regulator 16. One embodiment of the GUI 13 is shown in FIG. 2. The GUI 13 is divided by the server window 200, the controller window 204, and the equipment window 202. Server window 200 includes a list of producers 14 and servers 18 controlled by regulator 16. Specific regulator 16 is represented by controller window 204. The operator can select a particular producer (maker A shown in FIG. 2), and the equipment 20 associated with the producer 14 is displayed by the equipment window 202.

In the example shown in FIG. 2, server 18 for producer A compromises a window that provides information related to server 18 1, server 18 2, and server 18 3. Each server 18 has reliable data connected to it. For example, as shown in FIG. 2, each server 18 includes a forward bar showing storage space, credit, and several keys used for keytypes 1 and 2. FIG. Each tester window displays log information such as the date the previous step was processed, the credit reported, the refill amount and the missing log record data. The server 18 window provides the operator with options 214 and 216 to remotely set and cancel the server 18 from the regulator 16.

The regulator 16 can form the server 18 remotely. This allows the regulator 16 to change keytypes, such as addition and subtraction, and to form other formation options. It is preferably accomplished by sending a configuration message to server 18 HSM 28 along control channel 26. The HSM 28 evaluates the formation message, whereby several formation messages change the operation of the HSM 28 and other formation messages are sent to the server 18. The formation message is sent to the server 18 via the HSM 28, and using this method, can help the server 18 achieve the formation command originating from the regulator 16.

The regulator 16 may form the system remotely at the server 18 level or the equipment 20 level via the key agent 21. The regulator 16 can also force the server 18 polls and adjust the duration for regular polling. Typically, server 18 is polled for a fixed period of time, and regulator 16 may use a forced poll to obtain information for the required period. For example, during the day the regulator 16 needs data to report to the manager, and thus can force polls of all servers 18 to obtain such data. The GUI 13 includes a regulator 16 email option that allows the regulator 16 to automatically contact the manager in extreme environments such as failure to decrypt or dispense during critical production operations.

Each key distributed to the server 18 and injected by the device 20 into the device 22 generates a log record in certain events. The GUI 13 can be used to search, sort, edit and analyze log records, and can be used to present a standard report 400, as shown in FIG. In this embodiment, two major log records exist. The key for the server log 402 is generated when the key is supplied to the server 18 by the producer, and the key for the agent log 404 is sent to the HSM 28 at the time the key is transferred to the key agent 21. Generated by the key agent 21 upon key injection. Each log record contains identification information including ID type, time stamp, manufacturer, equipment 20, and the like. In the report shown in FIG. 8, the report 400 identifies the key for the server log 402, the key for the agent log 404, and the key for the injection log 406 in relation to the key with sequence ID = 001. Explain. These records estimate the life cycle of the key with the sequence ID number. The report 400 includes a plurality of records, and basic filtering is performed at appropriate places. For example, a report 400 representing all keys injected May 3 by Tester 2 at producer A may be edited by filtering, which is done in the time and location area.

As shown in FIG. 3, the producer 16 packages a large amount of keys in secure data transmission using the distributed image 40 sent to the server 18, preferably using encryption. The distribution image 40 allows the producer 16 to include keys for a plurality of products that are defined for the plurality of servers 18 in one transmission. Each server 18 can decrypt and obtain a certain number of keys, and via the control channel 26 from the regulator 16 after authentication has been received by the HSM 28. The distribution image 40 is a collection of data records, each record comprising a type 58, an ID 60, a size 54 and a data 56 area. At this time, the data 56 area contains key data 50 of an arbitrary size 54 identified by the size 54. Type 58 and ID 60 areas are used by the HSM 28 to identify key data and to filter certain keys, depending on the formation of the HSM 28, but prior to the control channel 26. Are directed via. The keys are enclosed by capsules so that they do not know what their purpose is. This allows for flexibility and extension without requiring a redesign for each new key type 58. Wrappers include elements that support more advanced features, such as logging on abstract images or various tasks.

Image 40 is encrypted by image key 42. The image key 42 is used by the server 18 to decrypt the image and obtain a key. The image key 42 itself is decrypted by each server 18 and stored in the server 18 header 48. The set 44 of server 18 headers 48 are stored in the main header 48. To decrypt the image and obtain the key, the header 48 is selected by the server 18 and decrypted by the HSM 28 that obtained the image key 42. The image key 42 is used to decrypt the image.

As described above, the dispense image 40 can be used to support a plurality of products. In Figure 7 the mapping for the product type and data block is shown. For example, producer 16 corresponds to alpha-enabled key 1, key 2, including gamma-enabled key 1 (with filter tag 1), beta-enabled key 2 (with filter tag 2), and building blocks (with filter tag 2). Has three products. The image contains large amounts of keytype 1 and keytype 2, and the gamma and beta products are more complex than the alpha products. Producer 16 may package a single image with data such as fifty (50) of each block, thereby allowing a certain tester (e.g., tester 1) to author, thus providing fifty alphas. 50 filter tags 1 and 2 can be obtained to produce the product. Another tester (Tester 2) simultaneously manufactures and acquires 50 filter tags 1 from the image to produce 50 beta products, and has 50 filter tags 2 to produce gamma products. The image contains all key injection data, contains as many key types as possible and produces a single type of product. The tester identifies the product type 58 or product model to the server 18, which is programmed. The model information is sent to the HSM 28 having an encrypted image, which can be filtered when the HSM 28 decrypts the image and key data 50 and needs to program the identified product model. Data 50 is transferred to the tester by the HSM 28. Therefore, the producer 16 can support a plurality of products having a single image, and at this time, it allows the producer to secure the steps to manufacture the product as intended.

Since the image can support multiple products, log recording is used to estimate the actual key injection performed at the tester, which will be discussed in detail below. By estimating the log record, the producer 16 can detect whether the producer sends back product gamma instead of product alpha (pay for production), thereby enabling the product beta to be sold in the black market. . Such discrepancies may not be intentional and can be reasonably confirmed by various methods.

A typical life cycle of a key from distribution to distribution channel 25 to HSM 28 is reported to regulator 16 via trailing channel 24, as shown in FIG. The block highlighted in FIG. 4 represents the steps performed by the safety module, ie each HSM 11, 28. The regulator 16 first obtains a large number of standard keys from a subcontractor. The regulator 16 sends a key to the HSM 11, which encrypts each block containing a key block, i. The key is encrypted in a block with one or more key types. The regulator 16 stores a large amount of encryption keys in the storage 15 until it receives an instruction indicating that the key block is to be distributed.

When the producer 16 distributes the key block, it will first include the encrypted block, and then send the block to the HSM 11. The HSM 11 decrypts the block and re-encrypts the key block sent to the image key 42. The image key 42 is itself encrypted for the production of each header 48. This header 48 is stored in the main header 46 group 44. Here, HSM 11 generates a key in server log 402 for the re-encrypted key because of the distribution. The log 402 is stored locally at the producer 12 for later analysis. The re-encryption block of keys is distributed to server 18 via distribution channel 25.

The server 18 sends the encryption key block included in the image 40 to the HSM 28, which then decrypts the image. HSM 28 first selects a particular header 48 from group 44 and decrypts image key 42. Image key 42 is decrypted to obtain a key from the image. At this time, the image 40 is verified, for example using a secure hash algorithm, MAC or digital signature, which is filtered. HSM 28 also re-encrypts each key obtained from the stored image. The server 18 then locally stores the re-encrypted key with the use of the equipment 20. The reliability of the image is based on the only symmetric distribution keys k s ₁ and k s ₂ split between the regulator 16 and the server 18. In the meantime the split message is acknowledged to be certain, and a successful integration check is performed after, for example, a sha-2 understanding comparison.

When the regulator 16 receives a request for a certain number of keys (N keys) from the equipment 20, the HSM 28 is given an N key for decryption. A key for the agent log record 404 is generated for each of the N keys that are decrypted by the HSM 28 and the key is sent to the equipment 20 for injection. At this time, the key is in the clear state and is ready for injection.

Equipment 20 injects each of the N keys, and key agent 21 generates a key injection log record 404 of each key being injected. The HSM 28 continuously acquires the keys for the agent log record 406 and the key injection log record 404 and preferably returns this record to the regulator 16 via the trailing channel 24. Link to report R.

Each log 402 is associated with two files and identifies the date the file was produced. The report R is encrypted by the HSM 28 with the encryption key k ₁ and returns to the drive application on the server 18 which is transmitted via the back channel 24. The regulator 16 decodes report R and checks each log (eg, 402, 404, 406). Each log is monotonous and tagged by the same number. If all record IDs are valid and not in contiguous set together, the operator of the regulator 16 will know where to track successively missing logs.

As described above, the regulator 16 has previously stored a number of keys in the server 18 log record 402 for N keys in key distribution. Thus, the regulator 16 expects to receive a report R that completes a life cycle for each key at some point in the future indicating that the aided key is decrypted and injected by the legitimate server 18 into the correct device. . The regulator 16 can evaluate the log report as provided. The regulator 16 can determine which operations interfere with the manufacturing process (eg, stop dispensing) or provide more keys. The regulator 16 requires more information before distributing the key block. In this way, regulator 16 can measure distribution and provide more keys if producer 14 operates with good confidence to produce consistently accurate log 402 reports.

The log record (shown in Figure 8) will allow the producer 16 to block discontinuities in ID number order. For example, if multiple keys are distributed but fail to report the key to the agent or to the injection log, the producer 14 may lose the key. This can lead to the activity of the black market. As another scenario, report R includes a key in agent log 404 and does not include key injection log 406 for a particular key. This indicates that the problem originates with the particular equipment 20 requesting the key rather than the producer 14 itself. Therefore, producer 14 uses log report R for auditing purposes and identifies malicious behavior internally to maintain a relationship with producer 12. The life cycle of each key requires report recording at the critical stage at which the key is operated. Therefore, the producer 12 has important information to check where the problem occurs and make an effort to correct or eliminate such problem. The log record contains information related to the key type as well as consecutive numbers for the key. In this way, the producer 16 can determine whether an alpha product is delegated but still produces gamma and beta products.

The log report provides information that prevents malicious or unethical behavior by the producer 14 and provides a means for evaluating the level of the creator 14 and tools that provide evidence of unfavorable behavior. . The use of substantive evidence to detect undesirable behavior causes producers 12 to face producers 14 with more than suspected, in which case torts occur at the tester level (employees, not companies). The use of substantive evidence, however, will rescue the important relationship between producer 12 and producer 14.

In addition to the dispenser, the regulator 16 uses the control channel 26 to adjust the credit pool 30 and handles the key injection step. The credit instruction process is as shown in FIG. HSM 28 must consume credit from credit pool 30 when decrypting distribution image 40 and achievement keys. Over time, the credit pool 30 needs to decrease to fill up the credit indication file sent by the regulator 16.

The regulator 16 sends a control message C to the server 18 via the control channel 26. One preferred request file included in this message is a credit indication file. The file may be encrypted with the data set of the particular server 18 decrypted by the HSM 28 with a credit indication. The credit indication includes, for example, the serial number of the HSM 28 or / or server 18, the ID of the server 18, the sequence number, the new credit amount and the formation data, but is signed by the regulator 16. .

Upon receipt of control message C, HSM 28 decrypts the credit indication data from control message C and verifies the signature. HSM 28 also identifies its own serial number and symbol ID. Thereafter, confirmation of the sequence number is performed. The sequence number should be larger than the sequence stored internally in the HSM 28. Once confirmed, HSM 28 updates the internal sequence number and sets the value of credit pool 30 to credit indication value.

HSM 28 will then process the formation message of control message C, which will update the internal formation, to cause controller 16 to push the formation data to server 18, where HSM 28 As described above with respect to the GUI 13, the rule filters and updates to key inject information and credit rules. The formation data may be proposed in the HSM 28, in the application running on the server 18 or in the key agent 21. HSM 28 finds a defined type of formation message that processes the message. The formation message may be symbolized by an individual or the public interest, and its access is also controlled by the HSM 28.

The credit report Cr is the response from the server that handles the credit indication in control message C. The credit report Cr includes a serial number and symbol ID of the HSM 28, a current sequence value, a current credit pool 30 value, a recharge date, and an error code that is set to zero when no error occurs in the credit indication process.

The credit report Cr is preferably signed by the HSM 28 using the signature key k ₂ . The report Cr is then encrypted for the regulator 16 using the public encryption key k ₃ of the regulator 16. The report Cr is sent to the regulator 16 and stored by the log report R, which appears for the audit purposes described above.

Prior to distributing the keys, the producer 12 and producer 14 are in preparation for starting the HSM and server 18. The preparation process is as shown in FIG. The HSM 28 produces a preparation request message P and sends it to the regulator 16. This message P contains the serial number of the HSM 28 used by the server 18. HSM 28 generates two cryptographic key couples, k ₁ , k ₂ (e.g., using an RSA key couple, preferably using elliptic curve cryptography) where the key couple receives an encryption message. It consists of a key (k ₁ ) and a key (k ₂ ) that signs external meshes. Preferably, the producer 14 is cryptostrapped in a physical control environment during the changing period of the key couples k ₁ and k ₂ .

When the controller 16 receives a preparation request from the server 18, it checks the message and requests the HSM 11 to give the producer 14 an "ID". Two keys are generated, preferably symmetric keys k _S1 and k _S2 (Advanced Encryption Standard (AES) keys). This key is used by the regulator 16 and the server 18 to protect the distribution image 40 on the distribution channel 25 and the log report R on the downstream channel 24.

The HSM 11 then generates a ready response message P ', for example, this message is assigned an assigned symbol ID, the encryption public key of the HSM, the signature keys k ₃ and k ₄ , the distribution and trailing symmetric channels k s ₁ and k. _s2 , initial formation data, and hash digests for verification. Similar to the preparation request message P, the preparation request message P 'is handled in a physically constructed environment (eg using HSM protection).

The preparation request message P 'is sent to the server 18, which receives the preparation request and performs initial operation. The structure of the ready response includes a separate structure that includes symmetric keys for the front and back channel 24 communication between the regulator 16 and the server 18. These keys are made clear for each HSM 28 (each server 18) and are not split in the group HSM 28. When the preparation process is complete, the change in distribution image 40 and control message C begins.

In another embodiment, as shown in FIG. 9, the system 10 is updated with a solution performed by the manufacturer 14 to protect the key injection step. In the embodiment shown in FIG. 9, the component is additionally given "a". For example, producer 14 has equipment 20a that includes transducer 74 to convert a series of "BCAs" to "ABCs", where instrument 22 accepts ABC as an injected key. To be connected. In this way, if the key "BCA" is missing, the instrument 22a does not work because no conversion occurs. This attempt to protect the key is natural, although easy to install, and does not provide an adequate level of protection. By accepting this protection, the system 10 updates the equipment without undoing the already installed solution. Thus, the additional cost of the manufacturer 14 for installing the system 10 can be cut off. Updates are made until the completed redesign is warranted, in which case the arrangement shown in FIG. 1 may be used.

To accommodate the solution, system 10 stores a set of signed objects 72 at server 18, which is a collection of executables 70 associated with specific equipment 20a, with a key The solution involved in HSM 28a is released prior to injection. In this way the key is changed to accommodate the solution without the known equipment 20a. As shown in FIG. 9, the regulator 16 requires access to the executable file 70 used by the equipment that provided the solution. The regulator 16 then delivers the executable 70 to the regulating HSM 11a. The regulating HSM 11a signs the executable 70 and passes the signed executable 70 to another server HSM 28a, the server HSM 28a passing the signature executable 70 to the signature object 72. Store in In operation, when the device requests a new set of keys, the server 18 checks the executable 70 against the signature of the executable 70, while the executable 70 is the server 18 HSM 28. Are stored in. The server 18a will send the collected executable file key upon confirmation of the executable file 72.

For example, equipment 20a requests a key BCA coming into transducer 76 in device 22a to allow key ABC to be injected into product alpha. The server HSM 28a determines if the product alpha has a signature executable 70 A to modify the key ABC. The signature executable A is verified but applies to the key ABC resulting in the aggregated key BCA. The collected key BCA is sent to the equipment 20a, and the converter 76 modifies the key BCA to inject the key ABC. Equipment 20a is key BCA (already received) is sorted by server 18a in ABC protected form. The key stored by the server 18a is formed in a CAB-like format, which is modified to read the aggregated BCA which is converted into ABC for injection. This case should be modified when the key CAB is in standard format and the CAB presents a solution that is not accepted as a key. Accordingly, the signature object 72 includes a program required to accommodate a solution installed by the equipment 20a, and the example provided above is for illustrative purposes.

The signature object 72 prevents malicious code from being loaded on the server 18a to modify the key prior to injection, since the signed executable is typically verified on the key ejected to the device prior to applying it to the key. . The system may increase the safety level while accepting the solution.

Thus, using the remote system regulator 16 separated from the server 18, the producer 12 can monitor the activity of the producer 14 and manages credit through the HSM 28. The producer 12 manages the injection of key information for the device 22, so that the producer 14 correctly reports the identity and the number of units produced for the producer 12. This may assure the producer 12 that the producer 14 is unable to make and distribute the black goods and devices 22.

In the process and system 10, the producer 12 may monitor production for the producer 14. The producer 12 using the credit indication of the control message C can manage the production of the device 22 by adding or subtracting the possible credit for the producer 14 use.

The system 10 is not limited to one manufacturer 14, as shown in FIG. 1, and each manufacturer 14 is not limited to one set of equipment 20. System 10 is also not limited to the use of single regulator 16. HSM 28 is the most reliable hardware to protect the key value and reliability of credit pool 30. Moreover, the key injection information included in the distribution image 40 does not necessarily become key injection information, but may be a data element requiring trust and authentication. The request for key injection data is a typical aspect of a system that wants to enhance the shape of device 22 activity.

In an alternative arrangement, with reference to the accompanying Figures 10-14, overproduction is prohibited by implementing separation between the silicon or the process of making the device 22. The producer 12 will perform various steps in the production for multiple contractors. In general, for silicon chips or other devices 22, separation of duties results in separation of manufacturing steps by the subcontractor, in order for the last product to be "touched" to become fully functional. Since the black market 110 is supplied by a single bad trust contractor at the peak of failure or production linkage, the contractor provides a continuous hint that two or more subcontractors conspire with the producer 12, which is a normal function. This is to provide a black market 110 with an auxiliary element and a device 22. The final product and its supporting elements must complete all production stages of functionality. In general, the risk of attack on the producer 12 is absolutely reduced when multiple subcontractors are required to conspire to steal.

In the production of silicon wafers, several stages occur, which are often split between multiple third party manufacturers. The producer 12 who designs the chip makes a design for one or more data files, which is also called a "net list." This net list is addressed in a computer code format language instructing a third party how to make a mask 90 for producing a silicon wafer, from which ICs are packaged and distributed.

For example, in an illustrative manufacturing process, the mask 90 is sent by the producer 12 to a silicon assembler that fabricates a silicon wafer from the mask 90. The wafers are transferred to a wafer test facility where each chip is directly tested and electrically marked on the wafer, and each chip that passes during cutting is transferred to a packaging facility. The packaging facility binds and packages the silicon in the chip package and then tests the final packaged chip. The final chip is sent to the OEM where the chip is mounted on a printed circuit board, which is part of the final device 22 product, which is sold to the consumer via distribution channel 80.

The manufacturing process described above consists of a plurality of stages that occur between the design and integration of the silicon chip in the device 22, ie, assembly, testing, packaging and installation. All these stages alternatively occur in a single facility, with more stages occurring until there are arbitrarily N stages. At each stage, there is an opportunity for overproduction and output reduction to occur.

As shown in FIG. 10, the producer 12 designs the mask 90. The mask 90 is used to produce a registration device 22 such as an IC. The device 22 includes a sensitive or immutable form of information included in the design, but preferably cannot operate without sensitive information. The producer 12 contracts with two or more third party production entities that perform specific stages in the overall production of the instrument 22. 10 shows from first 100 and second fabrication step 102 to any N-th fabrication step 104.

The producer 12 distributes the mask 90 through the production distribution channel 80. The mask 90 is initially transferred to the fabrication stage 100 where some of the fabrication is performed, such as the production of a silicon wafer. Once the first stage 100 is completed, the partially completed product is transferred to a second fabrication stage 102, which completes some fabrication steps, such as wafer testing. This process is repeated to any Nth stage, after which the complete functional registration device 22 is transferred to the distribution 106.

In order to prevent incomplete products or auxiliary elements from branching to the black market 110 at one of the production stages 100-104, "separation of responsibility" is applied. Separation of responsibility is the division of production and data programming at each production stage, and all responsibility must be carried out by the contractor in the intended order. This is necessary to produce a normal device. In this example, sensitive tasks, such as the injection of cryptographic data, are injected into a plurality of stages, each stage being performed by explicit production in a specific production stage. To isolate the sensitive task, the producer 12 integrates the registration module 92 into the design defined within the mask 90. Module 92 is used when mask 90 is matched to produce device 22 and mathematical strain 128 intercepts critical signals and data flows to the silicon chip, which allows mathematical strain 128 to work. Used when no device is present. Mathematical variant 128 is a cryptographic variant 128 that facilitates the widespread use of exclusive-OR (XOR) operations and, in causal terms, however, this is not required. For the mathematical modification 128 for driving, it is registered through the increasing injection and addition of critical data, which is part of the encryption key injection data and is present at each stage of the production process. In this way, the wafer produced in the first step 100 is over-produced and fed to the black market 110, as shown in FIG. 10, the product 112 being abnormal, which is required during normal operation. This is because all encrypted data is not received.

Preferably, as shown in the example of FIG. 10, the key injection system 10 described in FIGS. 1 through 9 is used to distribute, manage, and bill reports for key injection stages at each stage of manufacture. In this case, even if all entities are conspiring to distribute black trade products, producer 12 will be able to detect behavior due to incomplete log reports if it is necessary to prohibit distribution of key injection data. Alternatively, system 10 is used for several stages and need not be used for all stays. For example, the second stage 102 uses the system 10 rather than another stage. However, since each production step involves some form of testing, it is efficient to integrate testing into the system. In this scenario, the producer 12 expects data at least in the second stage. Module 92 is used without using system 10 and depends on each stage of a portion of the key injection step. In any state, by sharing responsibilities, no entity can have the necessary information on its own, successfully supplying black trade as a product or ancillary elements.

Mask 90 is shown in more detail in FIG. 11. As mentioned above, the registration module 92 is integrated into the mask 90 design, which is then programmed to install instructions or lines of other code, partially in one side of the consumer code ( It will insert the content defined by the module 92 in the path 124 (preferably important in the operation of the device 22) between the 120 and the other side 122. Data entering module 92 along path 124 is applied to cryptographic variant 128 and is the output of consumer code other 122 along path 126. Existing output on path 126 is useful if cryptographic transformation 128 is successfully applied to data input. The cryptographic variant 128 works with the memory 130, the processor 132, and the cryptographic key 134 to perform its operation. Memory 130, processor 132, and encryption key 134 are formed using existing key injection systems at each production stage. The memory 130 also includes another encryption key 131, which is generally made of a key injection material that accumulates at each stage and passes through the key injection system 10 shown in FIG. The key 134 is preferably used at injection time to ensure that the material accumulates in the memory 130 assembled to ensure that the key 134 is secured. The key 134 is a public key and may be necessary or unnecessary. For example, module 92 may operate without a key, even with potential risks associated with particular producers 12 or unrelated attack classes.

In general, the sensitive data used by module 92 is divided into parts, each of which is added to the key 131 at each stage of the manufacturing process. For example, one technique injects a digital signature for message recovery at each stage of the production process. The key 134 is used to verify the digital signature, where the verified digital signature produces a message that can be used in the key derivation scheme and uses the data in the memory 130 to implement the cryptographic key 131. . As another example, using a key shadowing technique, where several cryptographic keys 131 are added to the memory 130 at various stages of production. When the final production stage is complete, the memory 130 contains enough data so that the key shadow technique can be used to reassemble the cryptographic key 131.

An example of the first production stage 100 is as shown in FIG. As discussed above, the producer 12 uses a system 10 that distributes key data and monitors reports generated upon key generation. Key injection into the silicon chip occurs during wafer testing or subsequent packaging tests. In this embodiment, the stage 100 includes a server 18 and a key agent 21 working with the testing equipment 20. Stage 100 also includes production equipment 139 for producing silicon wafers. Production equipment 139 uses mask 90 dispensed through the channel to produce partially fabricated Device 1 140. In this embodiment, subscript 1 is used to indicate the first area of sensitive data applied to device 22, where the first area of sensitive data is injected through the use of key agent 21 of equipment 20. In this regard, device 1 140 is not fully operable, which is due to the fact that variant 128 does not have all the information necessary to perform the operation. Device 1 140 may be used to be distributed to second fabrication stage 102.

13 shows an exemplary production process that includes two specific production stages (N = 2). In step 1 500, the producer 12 determines the number of stages, thereby determining the number of regions of key data to be injected (e.g., N = 2). In step 2 502, the producer 12 implements a key injection system 10 that links each production stage through the channels 24, 25, 26. As mentioned in connection with FIG. 1, the producer 12 uses a single regulator in communication with a plurality of servers 18. In this embodiment, producer 12 distributes, monitors, and receives log records from two servers 18.

In step 3 504, the producer 12 integrates the design defined in the mask 90 with the registration module 92. The mask 90 is then distributed to the first fabrication 100 which performs stage 1 of the fabrication process in step 4 506, and stage 1 is performed in step 5 508. For example, the first manufacturer will produce chips along wafers and masks 90. During wafer testing, the manufacturer will program the partial key material into memory 130. This portion of the sensitive data is injected at step 6 510 and the server 18 reports to the producer 12 at step 7 512 using the outer mechanism. Alternatively, stage 1 does not handle the injection of sensitive data, and this operation is performed independently in stage 2.

If the first area of the key injection data is programmed into the chip or device 22, the product contains partial key injection information that is not sufficient to operate. 13 is represented by device 1 140, and the subscript 1 represents the first region mentioned above. Partially produced and programmed device 1 140 is distributed in stage 2 of step 8 514 for execution in step 9 516. The producer 102 injects key data into the second area in step 10 (518). For example, at stage 10 518, the second producer 102 may program additional key information, or may use partial key data stored in memory 130 at step 6 510 and at step 10 518. Retrieve cryptographic key information using new key data from the system. This withdrawal step is based on clutter or possibly more complex key shadowing techniques. Preferably, at step 11 520, the second producer 102 returns to the producer 12 to allow the second key region to be successfully injected. The producer 12 has two log records indicating that key data is to be successfully injected, and can use the information to monitor this record.

When the second area of key data is injected, the device 22 is fully produced and registered (tested and packaged IC), represented by device 1 140 ₂ in FIG. 13 where subscript 12 is the key. The data complete set, i.e., data areas 1 and 2, is shown. Then, the device 1, 140 ₂ are sent from the consumer to continue to channel allocation, at this time, it drives the product from Step 12 (522) Step 13 (524).

Further, as shown in FIG. 13, for example, when the first producer 100 or employee attempts to distribute a black trade product at step 14 526 (optionally via the distribution channel of step 15 528), The abnormal product is provided to the consumer at step 16 530 because only device 1 140 contains the first area of key data, and thus, variant 128 cannot perform its operation. Therefore, despite testing and packaging, it is performed in the dark trading stage 2, but no additional key data is provided and produced even if the product 530 is not fully registered. Preferably, module 92 is implemented for the operation of non-interfering means.

As shown in FIG. 14, in the embodiment of the finished consumer product 22a, module 92a integration is shown, where module 92a is a logical representation of the physical layout of the module 92 shown in FIG. 11. It is an indication. In FIG. 14, "a" is added to the reference numeral for clarity. Product 22a using module 92 execution may apply cryptographic modification 128a and become part of hardening block 150, with product critical data paths between codes 120a and 122a. . This path is decoded via variant 128a so that the consumer's logic 122a can function properly. In this embodiment, proof 132a, which is a task of the processor 132, is performed. The proof 132a uses a one-time programmable (OTP) memory 130a and an independent area 134a, which corresponds to the key 134 implementation of FIG. The key 134a and memory 130a are injected with sensitive data using the external process of FIG. The product 22a is only evaluated to incorporate the logic provided by the module 92, and the embodiment shown in FIG. 14 is for the purpose of explanation.

Although described above with respect to specific embodiments, various modifications can be used by those skilled in the art.

Claims (38)

A method of remotely controlling sensitive data injection into a device during production, A controller prepares and encrypts the sensitive data in transmission data; The controller sending a data transmission to a server, the server including a security module to perform an encryption operation; The safety module extracting the sensitive data from a data transmission; The server providing the sensitive data to equipment for injection into the device; Consists of including And the controller is located remote from the server. The method of claim 1, wherein the safety module comprises: preparing a log report on the sensitive data usage for the regulator; Remote device registration method characterized in that it further comprises. The method of claim 2, wherein the extracting step comprises the step of the security module decrypting a header included in the data transmission to obtain a key, and using the key to decrypt the transmission to extract the data. Remote device registration method. The method of claim 2, wherein after sending the data transmission, the controller generates a first log record, the first log record being stored by the controller in comparison with the log report; After providing the data to the device, the safety module generates a second log record indicating the distribution of the data to the device, the second log record being included in the log report. . 5. The method of claim 4, further comprising receiving a third log record from the device instructing the server to inject the data into the device, wherein the third log record is included in the log report. How to register your device. The method of claim 1, wherein the controller prepares a procedure to be performed before preparing and protecting the data, wherein the preparation procedure is used to initialize the server and the safety module. The method of claim 1, wherein the transmitting of the data transmission comprises transmitting the data transmission to a plurality of servers. The method of claim 1, wherein the regulator provides a credit indication to the server indicating the credit value to update the credit pool value, wherein the credit value indicates the number of data elements of the data transfer extracted by the safety module from the sensitive data. Remote device registration method characterized in that. 7. The method of claim 6 wherein after extracting the data from the data transmission, the safety module reduces the value of the credit pool by consuming credit from the credit pool. The method of claim 1, wherein prior to the preparation step, the controller receives the object to implement an injection solution of presence data, the presence solution comprising: modifying the data; The regulator signing the object and sending the signed object to the safety module; The security module storing the signature object, verifying the signature object, and modifying the data in accordance with the existing solution if the signature object is verified; Transmitting the modified data to the device and injecting the modified data into the device. The method of claim 2, wherein the data transmission comprises a plurality of sensitive data types, and wherein the safety module obtains a specific type from the type according to whether permission is achieved by the regulator. 12. The method of claim 11 wherein the log report includes an instruction to allow one of the types to be provided to the equipment by the safety module. The method of claim 1, further comprising the step of a regulator sending a configuration message to the safety module for use in a modification set. 2. The method of claim 1 wherein the log report is obtained by the controller using a poll initiated by one of the server and the controller. 5. The method of claim 4, wherein after comparing the first log record in the log report, the controller provides data transfer when the log report is useful and additional data is required, and the controller provides a data transfer when the log report is not useful. Providing an instruction to prohibit extraction of said data from a previous transmission. The method of claim 2, wherein the sensitive data consists of a plurality of keys and the transmission comprises the plurality of keys encrypted by the safety module of the regulator, wherein extracting the data is indicated by instructions provided by the regulator. Remote key registration method comprising a specific key decryption of the key. A system for remotely controlling sensitive data injection into a device during production, An adjuster having a first safety module for performing an encryption operation; A server located remotely from the regulator, the server being connected by front and rear channels; The front end channel is used by the controller to provide data transmission to a second secure module of the server, the data transmission protects the sensitive data in an encrypted manner, and the second secure module extracts the data from the transmission. , An agent drawing with the equipment used for the injection of said data extracted from said transmission and obtaining said data from said second safety module; Remote device registration system, characterized in that comprises a. 18. The remote device registration system of claim 17, wherein the second safety module relates to the use of the sensitive data and provides the log report to the controller via the trailing channel. 19. The remote device registration system of claim 18, wherein the controller comprises a graphical user interface (GUI) for forming the server and for monitoring the log report. 18. The method of claim 17, wherein the first safety module consists of an encryption key for encrypting a data key in the header of the data transmission, and the second safety module consists of a decryption key for decrypting the data key, wherein the second safety module comprises the data. And use the data key to decrypt the transmission to extract. 19. The method of claim 18, wherein the regulator consists of a first data store to store the data prior to preparing the data transfer, wherein the data is stored in a secure manner and the server stores the data transfer before extracting the data. Remote device registration system, characterized in that consisting of a second data storage. 22. The method of claim 21, after sending the data transmission, the controller generates a first log record and stores the first log record in the first store in comparison with the log report; After providing the data to the device, the second safety module generates a second log record indicating the distribution of the data to the device and saves the second log record of the second store included in the log report. Characterized in that the remote device registration system. 23. The remote device registration system of claim 22, wherein the agent generates a third log record indicating data injection into the device and transmits the third log record to the second safety module included in the log report. . 18. The system of claim 17, wherein the controller performs a preparation procedure before preparing and protecting the data, wherein the preparation procedure is used to initialize the server and the first and second safety modules. 18. The system of claim 17, further comprising the plurality of servers, wherein the regulator transmits the data transmissions by sending data transmissions to the plurality of servers. 18. The apparatus of claim 17, further comprising a credit indication generated by a regulator indicating a credit value to update the value of the credit pool stored by the second safety module, wherein the controller sends the credit indication to the second safety module. And wherein said credit value represents the number of data transmission elements extracted by said second security module from said sensitive data. 27. The system of claim 26, wherein after extracting the data from the data transmission, the second safety module reduces the value of the credit pool by consuming credit from the credit pool. 22. The method of claim 21, comprising at least one signature object stored by the second security module in the second reservoir, the signature object for implementing an existing data injection solution and transmitting the signature object to the second security module. Generated by a regulator that signs the object; The second security module verifies the signature object and modifies the data according to the existing solution if the signature object is verified; And send the modified data to the device for injection into the device. 19. The method of claim 18, wherein the data transmission is prepared by a first safety module comprising sensitive data having a plurality of different types, the second safety module acquiring a particular type of the types according to the permission achieved by the regulator. Remote device registration system, characterized in that. 30. The system of claim 29, wherein the log report includes instructions for causing one of the types to be provided to the equipment by the second safety module. 18. The remote device registration system of claim 17, wherein the regulator generates and sends a configuration message to the safety module for use in a modification set. 19. The system of claim 18, wherein the log report is obtained by the coordinator using a poll initiated by one of the server and the coordinator. 23. The method of claim 22, wherein after comparing the first log record in the log report, the controller provides data transfer when the log report is useful and additional data is required by an agent, wherein the controller is useful for the log report. Otherwise provide an indication prohibiting extraction of the data from a previous transmission. 19. The method of claim 18, wherein the sensitive data consists of a plurality of keys and the transmission comprises the plurality of keys encrypted by the first security module, wherein a particular one of the keys is indicated by a directive provided by the regulator Remote device registration system, characterized in that decrypted by the safety module. The method of claim 34, wherein the second security module decrypts the block keys after receipt and re-encrypts each key; Wherein said particular key of said key is decrypted for use by said equipment after being requested by an agent. 18. The system of claim 17, wherein the first and second safety modules comprise symmetric keys communicating over the front and back communication channels. An encryption variant that interrupts and transforms the data flow within the device and encryption key stored in memory and the area of sensitive data added to each encryption key at each stage Operation of the encryption key requested for successful operation of the encryption variant, In the module for adjusting the insertion of the sensitive data in the device in a plurality of stages comprising: And the device controls the insertion of sensitive data into the device, characterized in that it performs the successful operation of the encryption variant. A module in said device, said module having cryptographic modifications for interrupting and modifying data flow in said device; Adding an area of sensitive data to an encryption key stored in the module memory at each of a plurality of stages in production of the device, wherein the encryption key operation is required for successful operation of the encryption variant; In the method for adjusting the insertion of sensitive data in the device configured to include, Said device enables successful operation of said cryptographic modification.

Images