HK1178341B - Generating secure device secret key - Google Patents

Abstract

The invention provides generating secure device secret keys, methods, devices, systems and computer program products for facilitating cryptographically secure retrieval of secret information that is embedded in a device. The embedded secret information can include a random number that is not custom-designed for any specific requestor of the secret information. Upon receiving a request for the embedded secret information, an encrypted secret is provided to the requestor that enables the recovery of the embedded secret information by only the requestor. Moreover, a need for maintenance of a database of the embedded secret information and the associated requestors is eliminated.

Description

Generating secure device keys

Technical Field

This patent document relates to information security and device security, including techniques for exchanging secret information between different entities and generating a secure device key (secret).

Background

In various applications involving secure information and certain devices, secure exchange and transfer of information between different devices is important. To this end, various security protocols and algorithms may be used to securely exchange information, including voice, image, video, and other types of data, between various entities. Data security protocols often rely on encryption techniques, such as encryption, digital signatures, and hash functions, to authenticate and exchange information at a desired level of security. These techniques often rely on secret values (e.g., keys, random values, etc.) that are used by one or more participants to establish a secure communication channel, to carry out authentication protocols, etc.

Disclosure of Invention

(1) A method, comprising: receiving a first message from a first requester of secret information of an embedded device, wherein the message includes a public key associated with the first requester, and wherein the embedded secret information includes random information that is not associated with any particular requester; and generating a first encryption secret based on the received public key and the embedded secret information.

(2) The method of (1), wherein the first requestor signs the public key using a key associated with the device.

(3) The method of (1), wherein the generating of the first encryption secret is performed without maintaining a database of embedded secret information.

(4) The method of (1), further comprising: verifying the received public key, wherein the first cryptographic secret is only generated if the received public key is successfully verified.

(5) The method of (1), further comprising: the apparatus is marked to indicate generation of the first cryptographic secret.

(6) The method of (5), wherein tagging the device comprises: locking a one-time programmable (OTP) device.

(7) The method of (1), wherein the first cryptographic secret is generated only if the apparatus is not marked with an indication that the first cryptographic secret has been generated before.

(8) The method of (1), wherein the first encryption secret is generated by encrypting embedded secret information using the received public key.

(9) The method of (1), wherein the apparatus further comprises an identifier embedded in the apparatus; and the embedded identification of the device is provided to the first requestor with the first cryptographic secret.

(10) The method of (1), wherein the first message includes assistance information representing an identity of the first requester; and generating the first encrypted secret by encrypting auxiliary information representing the identity of the first requestor using the embedded secret information and then encrypting the result using the public key received by the first requestor.

(11) The method of (10), further comprising: receiving a second message from a second requestor of the embedded secret information, wherein the second message includes assistance information representing an identity of the second requestor; and generating a second encrypted secret by encrypting the auxiliary information representing the identity of the second requester using the embedded secret information and then encrypting the result using the public key received by the second requester.

(12) The method of (1), further comprising: digitally signing the first encrypted secret.

(13) The method of (1), wherein the first message includes both a signed public key and a signed requestor identification related to the first requestor; and generating the first encrypted secret by encrypting the received identification associated with the first user using the embedded secret information and then encrypting the result using the public key received by the first requester.

(14) The method of (13), further comprising: receiving a second message from a second requestor of embedded secret information, wherein the second message includes both a signed public key and a signed requestor identification related to the second requestor; and generating a second encrypted secret by encrypting the received identification associated with the second user using the embedded secret information and then encrypting the result using the public key received by the second requester.

(15) The method of (1), wherein the embedded secret information comprises a random number embedded in the device as part of a manufacturing process of the device.

(16) The method of (15), wherein the random number is an encrypted secure random number generated external to the apparatus.

(17) The method of (1), wherein the first message includes one or more usage labels representing one or more particular operations of the apparatus.

(18) The method of (17), further comprising: tagging the apparatus with one or more usage tags contained in the first message, wherein the tagged one or more usage tags within the apparatus are subsequently used to control access to the apparatus.

(19) A method, comprising: receiving a request for retrieval of secret information related to a device, wherein the secret information is not related to any particular requestor of the secret information; and generating an encrypted secure response such that a recipient of the response can recover the embedded secret information, wherein the embedded secret information can only be recovered by a sender of the request.

(20) A method, comprising: sending a message to a device to request secret information embedded in the device, wherein the sent message includes a public key, and wherein the embedded secret information includes random information that is not related to any particular requestor of the embedded secret information; receiving an encryption secret in response to the transmitted message; and recovering the embedded secret from the encrypted secret.

Drawings

FIG. 1 is a block diagram of an exemplary system in which various exemplary embodiments may be implemented.

Fig. 2 illustrates a set of operations that may be performed for embedding random numbers in an apparatus according to an example embodiment.

FIG. 3 illustrates a set of operations that may be performed for securely providing secret information related to a device in accordance with an example embodiment.

FIG. 4 illustrates a set of operations that may be performed for securely providing secret information related to a device according to another example embodiment.

FIG. 5 illustrates a set of operations that may be performed for securely providing secret information related to a device according to another example embodiment.

FIG. 6 illustrates a set of operations that may be performed for securely providing secret information related to a device according to another example embodiment.

Fig. 7 is a block diagram of an exemplary apparatus that may incorporate the disclosed exemplary embodiments.

Detailed Description

The present invention provides methods, apparatus, systems and computer program products for cryptographically secure retrieval of secret information embedded in a device. The embedded secret information may include a random number that is not custom designed for any particular requestor of the secret information. Upon receiving a request for embedded secret information, the encrypted secret will be provided to the requestor such that the embedded secret information can only be recovered by the requestor. The techniques may be used to eliminate the need to maintain a database of embedded secret information and associated requestors.

Some information security systems, such as Digital Rights Management (DRM) systems, require that a unique key be embedded, for example, in a chipset as part of the chipset's manufacturing process. Typically this key (key) is used for secure transfer of information to/from the system on chip (SoC). Therefore, the party desiring to establish such a channel must know the key. At the same time, the key must be invisible in any way outside the device and cannot be accessed by unauthenticated parties. In order to properly use and distribute these keys, some systems use key management and exchange protocols, which require the presence and maintenance of a key database. Maintenance of such databases can increase the cost and complexity of such systems and can also increase the liability of database maintenance parties.

The techniques may be implemented without the database maintenance mentioned above. The disclosed embodiments provide examples of implemented methods, apparatus, systems, and computer program products that facilitate the exchange of secret information present in an apparatus, which may be, for example, a chip, chipset, system-on-a-chip, and the like. Such secret information is typically embedded into the system at the time of manufacture. Such secret information (or keys) may need to be accessed only by a particular authenticated party. In some systems, this may be accomplished by embedding a specific secret value and an identification associated with the requestor into the SoC at the time of SoC manufacture. To avoid subsequent manipulation of the secret value and/or identification, the SoC may be equipped with a locking capability, thereby preventing future corruption of the key and identification once written to the device. Such systems therefore require the specific manufacture of each device for the requesting party, thereby increasing the complexity of inventory management, ordering, and manufacturing processes. For example, the device manufacturer must know the security provider responsible for providing the secret value and, once the device is manufactured, implement specific inventory maintenance and track processes. Furthermore, in such systems, the keys and/or identifications are stored in a database that must be maintained and managed by the device manufacturer, the requestor, and/or a trusted third party. Therefore, the device manufacturer may be burdened with securely communicating with such databases and possibly managing at least a portion of the operations associated with the databases.

In other systems, database management may be avoided by embedding a random (but visible) identification into the SoC and creating the relevant keys using a keyed one-way function. A party with a one-way function and knowledge of the associated key knows the random identity and can easily generate the key. Such a system may be used, for example, in a challenge-response protocol, where the security system may allow access to the device (or unlock some test port of the device) after the challenge requester and in response receives the correct key. The security of this system relies entirely on the privacy of one-way functions, which can be shared by multiple external parties. If each requestor requests a unique one-way function (e.g., to ensure that another third party does not divulge or maliciously use the one-way function), then devices need to be specially manufactured for each requestor to have its own dedicated one-way function. However, the implementation of a unique one-way function for each requestor can increase the cost and complexity of operations in the device manufacturing stage.

Embodiments of the present disclosure personalize secret information embedded in a device (e.g., SoC) that can be used for a single requestor without embedding dedicated secret information for each requestor. The disclosed embodiments further eliminate the need to manage and maintain a database of embedded secret information and corresponding requestor identifications at the device manufacturing facility. In some embodiments, the random key is written to the device. The device then securely passes the derivative of the random key to a plurality of external parties so that each external party can confirm the integrity of the unique secret without requiring each device to be specially manufactured for a single third party or requiring database management on the part of the device manufacturer. In some embodiments, the value that is passed into and/or read from the device (e.g., SoC) by the requestor of the embedded secret information is not necessarily a secret value, but provides valid access to the information when used in conjunction with other secrets held exclusively by external parties.

FIG. 1 provides a block diagram of a system that may incorporate embodiments of the present disclosure. The device manufacturing facility 102 depicted in fig. 1 typically produces the devices 104a, 104c through 104c as chips, chipsets, system on a chip (SoC), etc., which may be purchased, for example, by external entities such as OEM manufacturers and system developers. Each device 104a manufactured by 104c is embedded with unique secret information, such as a random number. So that multiple requesters 106a may request the embedded secret information via 106 i. As previously described, the embedded secret information may be used by the requestor, for example, to establish a secure communication channel with the device, with other systems or devices, and/or to affect other cryptographic security operations.

Fig. 2 illustrates a set of operations that may be performed for embedding random numbers in an apparatus according to an example embodiment. Some or all of operations 200 shown in fig. 2 may be performed, for example, at a device manufacturing facility. At 202, a Random Number (RND) is generated, and at 204, the generated random number is sent to the device. The apparatus may comprise, for example, a SoC. In some implementations, the random number can be generated at the device. However, the generation of true random numbers (e.g., encrypted secure random numbers) for cryptographic applications may require time consuming operations and/or may be more easily generated outside of the device or possibly outside of the manufacturing facility. For example, generating random numbers from thermal noise may require operation of the heat source for a certain period of time before a suitable value can be generated. Thus, in some embodiments, the generation of the random numbers precedes the embedding of the numbers into the device, and may be generated outside of the manufacturing facility using a suitable random number generation scheme. The generated random numbers are then transmitted to and/or stored within a manufacturing facility for use in later device manufacturing processes. It should further be noted that in addition to the embedded random numbers, any identification associated with the devices may be generated and written to each device. In some embodiments, such an identification may be read as clear text by the requestor accessing the device, while an embedded random number (described in the following section) communicates securely only with the particular requestor.

Next at 206, a random number is embedded into the device. For example, the random number may be written to a particular register or memory location within the device. At 208, the random value of the embedded device is read back, and at 210, the location within the device containing the random value is locked. The locking of the device prevents future manipulation of the embedded random number. In an example embodiment, the apparatus includes a one-time programmable (OTP) component, such as a non-volatile on-chip storage location, for permanently storing the random number within the apparatus. At 212, processing is performed to determine whether the random number is properly embedded in the device. If the correct random number cannot be retrieved at 212, the device may be discarded at 216. However, if the random number is correctly embedded, the device retains at 214.

The means for embedding the random number by, for example, the exemplary set of operations in fig. 2 may also include a set of asymmetric keys associated with a public key (public) encryption algorithm. In some implementations, the stored key may include both a public key and a private key (privatekey). The public key may be stored in the device to prevent the public key from changing and to allow access to the key. The private key contained in the device is kept secret. For example, one or more RSA public key pairs may be stored in the device. The stored public key may be owned by the device manufacturer or by a number of third parties.

Fig. 3 illustrates a set of operations 300 that may be performed for securely providing secret information related to a device according to an example embodiment. The example operations 300 in fig. 3 may be performed, for example, outside of a device manufacturing facility by one or more components of a device including a security system. At 302, a message is received containing a public signature key from a requestor of embedded secret information. In an example, the public key received at 302 is signed using one RSA public key corresponding to the device (e.g., corresponding to the device manufacturer). Thus, the OTP can be used to select which stored public key to use to verify a received requestor public key. At 304, processing is performed to determine whether the secret information was previously derived. If the information was previously derived ("YES"), a reset operation is performed at 306 and the process stops. In an example, a processor or circuitry configured to control some or all of operations 300 of fig. 3 may assert a hardware reset signal to cause the SoC to reset or reboot. On the other hand, if the determination at 304 is "no," then operation continues at 308 by verifying the requestor public key. In some implementations, the verification at 308 includes an RSA verification operation on the message and related signature received at 302. For example, the verification operation at 308 may be performed using the RSA probabilistic signature scheme (RSA-PSS). In another example, the verification at 308 may be performed using an Elliptic Curve Digital Signature Algorithm (ECDSA). In some implementations, the verify operation at 308 includes an Error Correction Code (ECC) verify operation. If the public key cannot be verified, a reset operation is performed at 312 and processing stops. For example, a processor or circuitry configured to control some or all of operations 300 of fig. 3 may assert a hardware reset signal to cause the SoC to reset or reboot. On the other hand, if the requester public key is properly verified, then at 314, the embedded secret information is encrypted using the requester public key. At 316, the encrypted embedded secret information is output along with potentially arbitrary identification of the device. Further, the device may be marked to indicate that the embedded secret information has been exported to a particular requestor. This is the operation at 318 and may be implemented by, for example, burning a fuse and/or writing an OTP.

The requester of the embedded secret information, after receiving the encrypted message, can use its private key to easily decrypt the received message and recover the RND value. Alternatively, the requester may store the RND and associated identification in a secure location (e.g., a key database). However, the device manufacturer need not maintain or interact with such a database. Thus, the exemplary embodiment illustrated by means of fig. 3 provides a flow for providing embedded secret information to any particular requesting party without the need to manufacture a custom device for that particular party. Furthermore, the exemplary embodiment shown in FIG. 3 eliminates the need for the device manufacturer to manage and maintain a key database and related information.

In some implementations, the message received from a particular requester (e.g., operation 302 in FIG. 3) includes not only the requester's public signature key, but also one or more pieces of ancillary information, such as one or more usage tags. For example, such a usage tag may indicate that a particular operation (such as retrieval of embedded secret information) is requested. For example, the usage tag may be verified as part of operation 310 in FIG. 3 and then read and parsed by the security system before subsequent operations (e.g., encryption of secrets) are performed.

Fig. 4 illustrates a set of operations 400 that may be performed for securely providing secret information related to a device in accordance with an example embodiment. The example operations 400 in fig. 4 may be performed, for example, outside of a device manufacturing facility by one or more components of a device including a security system. At 402, a message is received from a requestor that includes a signed public key and a requestor identity (identification). In an exemplary embodiment, the public key received at 302 is signed using one RSA public key corresponding to the device (e.g., corresponding to the device manufacturer). The requestor identity is an example of assistance information that may be passed from the requestor to the device. In the exemplary embodiment shown in FIG. 4, the requestor identity indicates the owner, the requestor, or another party interested in obtaining the embedded secret information. In one example, the requestor identity is a binary field.

Next, at 404, the public key is verified. At 406, a determination is made whether the public key is valid. If the public key cannot be verified ("NO" of 406), a reset operation is performed at 408 and processing stops. If the public key is valid, processing is performed at 410 to determine whether the embedded secret information was previously exported to a particular requestor. If the information was previously derived ("yes" at 410), a reset operation is performed at 412 and processing stops. On the other hand, if the determination at 410 is "no," then operation 400 continues at 414, where the derived secret is generated using the requestor identity and the embedded secret information. In an exemplary embodiment, the derived secret is generated by encrypting the requestor identity using embedded secret information (e.g., RND). In some implementations, Advanced Encryption Standard (AES) or other symmetric key encryption algorithm may be used to encrypt the requester identity. In some implementations, the secret information (e.g., RND) is used as a key for an encryption algorithm, the requestor ID is in plaintext, and the requestor ID is encrypted to produce ciphertext that is a secret specific to the requestor. At 416, the derived secret is encrypted using the public key of the requestor, and at 418, the encrypted derived secret is output. At 420, the device is marked to indicate that the embedded secret information has been exported to a particular requestor. In this manner, when the device receives another request, the determination at 410 to evaluate whether the RND has been previously derived is facilitated. The operation performed at 420 may be implemented, for example, by burning a fuse or writing an OTP.

Based on operation 400 in fig. 4 above, the requestor may decrypt the received derived secret and determine the embedded secret information. Thus, operation 400 in FIG. 4 enables a unique derived secret for each requestor to be generated from embedded secret information using auxiliary information (e.g., a requestor ID). As such, a device configured to operate in this manner may provide embedded secret information to multiple requesters using encrypted secure messages. The secure message sent to each requestor is unique and cannot be decrypted by any other requestor without a suitable decryption key. Such a design would potentially allow an unlimited number of requesters to query the device and receive the embedded secret information in such a manner as to be cryptographically isolated from messages sent to other requesters.

It is noted that the exemplary set of operations shown in fig. 4 restricts multiple exports of secret information to the same party. In some embodiments, however, such limitations may not be present. For example, the embedded secret may be communicated to the same party multiple times (e.g., to the same requestor ID). In such embodiments, each derivation of the embedded secret information may be recorded separately in the device, or archived.

Fig. 5 illustrates another set of operations 500 that may be performed for securely providing secret information related to a device in accordance with an example embodiment. The example operations 500 in fig. 5 may be performed, for example, outside of a device manufacturing facility by one or more components of a device including a security system. Operations 502 through 516 are similar to those described in relation to operations 402 through 416, respectively, in fig. 4. Specifically, at 502, a message is received from a requestor that includes a public signature key and a requestor ID. Next, the public key is verified at 504, and if the determination at 506 indicates that the public key is invalid, a reset operation is initiated at 508. If the determination at 506 indicates that the public key is valid, the operation 500 continues at 510 to determine whether the secret information was previously exported to the requesting entity. If the determination at 510 indicates that the secret has been previously derived, then a reset operation is performed at 512. On the other hand, if the secret information has not been previously derived ("no" at 510), then at 514, a derived secret is created using the requestor ID and the secret embedding information.

At 516, the derived secret is encrypted. At 518, the encrypted derived secret is further signed. In some instances, the encrypted derived secret is signed using a global (e.g., single) private key, while in other instances, a device-specific private key is used to sign the encrypted derived secret at 518. In an exemplary embodiment utilizing device-specific keys, a list of relevant valid public keys is generated. Such a list may be generated, for example, as part of a device manufacturing operation and made publicly available. The list of public keys available to the requester of secret information enables the requester to determine that the derived secret is provided by a legitimate device. At 520, the signed and encrypted derived secret is output. At 522, the device is marked to indicate that the embedded secret information has been exported to a particular requestor.

Operation 500 shown in fig. 5 includes an additional operation 518 to sign the encrypted derived secret. Such signed messages, once received and verified by a requester of secret information, will provide assurance as to the authenticity of the message generated by the device. In particular, such a signature ensures that the message is indeed generated by a legitimate security system (or security company) and not from an attacker that intercepts the communication from the requester and merely mimics the response of the legitimate security system.

Fig. 6 illustrates another set of operations 600 that may be performed for securely providing secret information related to a device in accordance with an example embodiment. The example operations 600 in fig. 6 may be performed, for example, outside of a device manufacturing facility by one or more components of a device including a security system. At 602, a message is received from a requestor that includes a public key of a signature and an identity of the signature generated by the requestor ("requestor ID"). In an exemplary embodiment, the public key and the requestor ID are signed using one RSA public key corresponding to the device (e.g., corresponding to the device manufacturer). In some embodiments, the received public key and requestor ID may be signed as separate messages, while in other embodiments, the public key and requestor ID may constitute a single message that is signed by the requestor and sent to the device.

Next at 604, processing is performed to determine whether the device has been marked as having generated an ID key (e.g., whether the device OTP has included an ID). If the device has been marked as having generated an ID key ("YES" of 604), a reset operation is performed at 606 and processing stops. If the device has not previously generated an ID key (e.g., the OTP is empty) ("NO" at 604), the public key and the requestor ID are verified at 608. If the verification of the public key or requestor ID fails ("NO" of 610), a reset operation is performed at 612 and the process stops. Otherwise, an ID key is generated at 614. In one example, the ID key is generated by encrypting the requestor ID with secret embedded information. The ID key is encrypted using the public key of the requestor at 616, and the encrypted ID key is output at 618. At 620, a derivation indication of the secret information and the requestor ID are recorded in the device.

Once the requestor receives the encrypted message generated by the device, the requestor can decrypt the received message using its private key and recover the ID key. The ID key, along with the requestor ID (known to the requestor), may be stored by the requestor. Thus, the exemplary set of operations 600 shown in FIG. 6 generates a derived secret (e.g., ID key) that is unique to each requestor and that is generated based on a particular token (e.g., requestor ID) that is securely passed to the device by the requestor. One of the advantages of the example operation 600 of fig. 6 is that malicious attempts to obtain information may be deterred. In particular, in one attack scenario, a malicious party may initiate a request for the device's ID key, receive the ID key, and somehow prevent the device from flagging the derivation of the ID key (e.g., the malicious party locks the OTP write). Such a device can then be used for the real authorization of a legitimate user. Upon receiving a request from a legitimate user, the device provides an ID key based on the exemplary operational set 600 described in fig. 6. Since the ID used by the legitimate user is almost certainly different from the ID used by the malicious party, the malicious requester will not receive any information from the device. Since the requester ID and factory programmed identification can be kept secret, even if a malicious third party can try to obtain a subsequent outgoing message from the device, such message includes a requester identification that is different from the identification provided by the legitimate user. Since the malicious third party does not know the unique ID for this device, they will not be able to receive the ID key corresponding to the legitimate request. Another advantage of the exemplary operation 600 of fig. 6 is that there is no need to embed any chip identification during the manufacturing process, since the identification provided by the requestor can be entirely a chip identification.

It is noted that, similar to that described in relation to the exemplary embodiment of fig. 3, the message received at 602 may also include one or more auxiliary information or usage tags that only allow certain subsequent operations. Such a use tag may be embedded in the device (e.g., written to the OTP) and used as part of the secret generation process. For example, in order for the device to generate the same secret at a later point in time, the device is provided with the same usage tag during runtime. In this way, the original message will cause the chip to generate a secret that can only be used subsequently in the manner intended by the requestor. If the usage ticket changes during runtime, i.e., the device is requested to generate a key with a different set of tickets, the generated key will not match the previously generated key and ticket values.

Further, in some implementations, the message received at 602 further includes an owner ID (not a secret), which is used to generate an owner-specific derived secret, similar to operation 400 of fig. 4. In such an embodiment, the requestor provides both the requestor-generated ID and the owner ID. But in other embodiments, in addition to encrypting the key ID (at 616), the device signs the encrypted ID key with the device public key, similar to operation 518 of fig. 5, thereby providing assurance that the outgoing message was generated by a legitimate device (or security system).

In some implementations, multiple derived secrets can be generated. In particular, the N OTPs may be configured to allow N requesters to make requests. For example, if eight requestors require derived secrets, the SoC may be configured to reserve eight OTP bits. In such an embodiment, if the common owner ID tag received by the SoC includes the value i, then bit i {1 ≦ i ≦ N } of the OTP is set (and locked). As previously discussed with respect to fig. 4, the owner ID, i, may also be subsequently used to generate a derived secret, thereby allowing the derived secret associated with requestor i to be generated only once. In some embodiments, the security system may decide to provide derived secrets for less than N users, even if the device is configured with the ability to provide derived secrets for N requesters. In this case, some OTP bits may be locked even without outputting the derived secret. This mechanism may reduce the number of requesters that a device may be accommodated by the device after it is manufactured.

It is noted that the various exemplary operations shown in fig. 2-6 are described in a particular order to facilitate an understanding of the disclosed embodiments. However, it is to be understood that one or more of the operations shown in fig. 2-6 may be omitted and/or combined with other operations. Further, one or more of the operations illustrated in each of fig. 2-6 may be performed in a different order than that illustrated.

It will be further understood that the foregoing description is not intended to be exhaustive or to limit embodiments of the invention to the precise form disclosed, and that modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments. The embodiments discussed herein were chosen and described in order to explain the principles and the nature of various embodiments and its practical application to enable one skilled in the art to utilize the present invention in various embodiments and with various modifications as are suited to the particular use contemplated. For example, in some implementations, the configuration value may be used in place of the identification to generate the derived secret. In other embodiments, multiple configuration values may be stored to allow more than one derived or valid secret to be generated. In other embodiments, a use configuration that is signed with the entered public key may be linked to the valid secret generation process.

Various embodiments described herein are described in the general context of methods or processes, which may be implemented in one embodiment by a computer program product, embodied in a computer-readable medium, including computer-executable instructions, such as program code, executed by computers in network environments. The computer readable medium may include removable and non-removable storage devices including, but not limited to, Read Only Memory (ROM), Random Access Memory (RAM), Compact Discs (CD), Digital Versatile Discs (DVD), Blu-ray discs, and the like. Thus, the computer-readable media described in this application include non-transitory storage media. Generally, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps or processes.

It is to be understood that the various embodiments of the present application may be implemented individually or selectively in a device that includes various hardware and/or software modules and components. These means may for example comprise a processor, a memory unit and an interface communicatively connected to each other. For example, FIG. 7 illustrates a block diagram of an apparatus 700 within which all or portions of various embodiments of the present application may be implemented. The apparatus 700 includes at least one processor 704 and/or controller, at least one memory unit 702 in communication with the processor 704, and at least one communication unit 706 that enables data and information to be exchanged with other entities, devices, and networks, either directly or indirectly, through communication links 708. The communication unit 706 may provide wired and/or wireless communication capabilities in accordance with one or more communication protocols, and thus may include appropriate transmitter/receiver antennas, circuitry, and ports, as well as encoding/decoding capabilities, which may be necessary for appropriate transmission and/or reception of data and other information. Memory 702 may store data, instructions, and other types of information, and may include both read-only memory (ROM) and Random Access Memory (RAM). A portion of the memory 702 may include non-volatile random access memory (NVRAM). Further, a one-time programmable (OTP) device may be implemented as part of memory 702. The OTP device may also be implemented as a separate component in the device 700.

The example apparatus 700 of fig. 7 may be used to implement example embodiments of the present application. Such an exemplary embodiment relates to a method comprising: a first message is received from a first requestor of secret information embedded in a device. Such a message includes a public key associated with the first requester. In addition, the embedded secret information includes random information that is not associated with any particular requestor. The exemplary method further comprises: a first encryption secret is generated based on the received public key and the embedded secret information.

In one embodiment, the first requester signs the public key with a key associated with the device. In another embodiment, the generation of the first encryption secret is performed without maintaining an embedded secret information database. According to another embodiment, the above-mentioned method further comprises: verifying the received public key, wherein the first cryptographic secret is only generated if the verification of the received public key is successful. In another embodiment, the above-mentioned method further comprises: the device is marked to indicate generation of the first cryptographic secret. The indicia may include, for example, a locking One Time Programmable (OTP) device.

According to another embodiment, the first cryptographic secret is generated only if the device is not marked with an indication that the first cryptographic secret has been generated before. In some implementations, the first encryption secret is generated by encrypting the embedded secret information using the received public key. In other exemplary embodiments, the apparatus further comprises an identifier embedded in the apparatus. Such an embedded identification may be provided to the first requestor along with the first cryptographic secret.

In another exemplary embodiment, the first message includes assistance information indicative of the identity of the first requester. In this exemplary embodiment, the first encrypted secret is generated by encrypting the auxiliary information representing the identity of the first requestor using the embedded secret information, and then encrypting the result using the public key received by the first requestor.

The disclosed embodiments may also accommodate multiple requestors of embedded secret information. In particular, in an exemplary embodiment, the above-mentioned method further comprises: a second message is received from a second requester of the embedded secret information, wherein the second message includes assistance information indicative of an identity of the second requester. In this case, the method further includes: the second encrypted secret is generated by encrypting the auxiliary information representing the identity of the second requestor using the embedded secret information and then encrypting the result using the public key received by the second requestor.

According to another embodiment, the above-mentioned method further comprises: the first encrypted secret is digitally signed. In another embodiment, the first message includes both the signed public key and a signed requestor identification associated with the first requestor. In this embodiment, the first encrypted secret is generated by encrypting the received identification associated with the first user using the embedded secret information and then encrypting the result using the public key received by the first requester. In a related scenario, the method of the exemplary embodiment further comprises: a second message is received from a second requestor of the embedded secret information, wherein the second message includes both the signed public key and a signed requestor identification associated with the second requestor. In this case, the method further includes: the second encrypted secret is generated by encrypting the received identification associated with the second user using the embedded secret information and then encrypting the result using the public key received by the second requester.

In another embodiment, the embedded secret information includes a random number that is embedded in the device as part of the device manufacturing process. For example, the random number may be an encrypted secure random number generated outside the device. In another example, the device comprises a system on a chip (SoC) device. In another embodiment, the embedded secret information may be recovered by decrypting the encrypted secret using a private key of the first requestor that is associated with the received public key.

In another embodiment, the first message received from the first requester includes one or more usage tags representing one or more operations of the apparatus. In one embodiment, the above-mentioned method further comprises: the device is tagged with one or more usage tags contained in the first message. In one example, one or more usage tags marked within the device are then used to control access to the device.

Another aspect of the disclosed embodiments relates to an apparatus comprising a processor and a memory. The memory includes processor executable code such that the processor executable code, when executed by the processor, configures the apparatus to: a first message is received from a first requestor of secret information embedded in a device. The message includes a public key associated with the first requester and the embedded secret information includes random information not associated with any particular requester. The processor executable code, when executed by the processor, further configures the apparatus to: a first encryption secret is generated based on the received public key and the embedded secret information.

Another aspect of the disclosed embodiments relates to a computer program product embodied on a non-transitory computer readable medium. The computer program product includes computer code for receiving a first message from a first requester of secret information embedded in a device. The message includes a public key associated with the first requester and the embedded secret information includes random information not associated with any particular requester. The computer program product also includes computer code for generating a first cryptographic secret based on the received public key and the embedded secret information.

Another exemplary embodiment relates to a method, comprising: a request is received for retrieval of secret information associated with a device, wherein the secret information is not associated with any particular requestor of secret information. The method further includes generating an encrypted secure reply such that a recipient of the reply can recover the embedded secret information. However, the embedded secret information can only be recovered by the sender of the request.

In another exemplary embodiment, a method is provided, comprising: a message is sent to the device requesting secret information embedded in the device. The transmitted message includes a public key and the embedded secret information includes random information that is not related to any particular requestor of the embedded secret information. The method further comprises the following steps: an encrypted secret is received in response to the transmitted message, and the embedded secret is recovered from the encrypted secret.

While this specification contains many specifics, these should not be construed as limitations on the scope of any invention or of what may be claimed, but rather as descriptions of features specific to particular embodiments of particular inventions. Some functions described in this specification in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Claims (10)

1. A method of encrypting secret information associated with a device, comprising:

receiving a first message from a first requester of secret information of an embedded device, wherein the message includes a public key associated with the first requester, and wherein the embedded secret information includes random information that is not associated with any particular requester; and

performing processing to determine whether the secret information was previously derived;

in the event that the determination is negative, a first encryption secret is generated based on the received public key and the embedded secret information.

2. The method of claim 1, wherein the first requestor signs the public key using a key associated with the device.

3. The method of claim 1, further comprising: verifying the received public key, wherein the first cryptographic secret is only generated if the received public key is successfully verified.

4. The method of claim 1, further comprising:

the apparatus is marked to indicate generation of the first cryptographic secret.

5. The method of claim 1, wherein the first cryptographic secret is generated only if the apparatus is not marked with an indication that the first cryptographic secret has been generated before.

6. The method of claim 1, wherein,

the apparatus further comprises an identifier embedded in the apparatus; and

the embedded identification of the device is provided to the first requestor with the first cryptographic secret.

7. The method of claim 1, wherein,

the first message comprises assistance information representing an identity of the first requester; and

the first encrypted secret is generated by encrypting auxiliary information representing the identity of the first requester using embedded secret information and then encrypting the result using the public key received by the first requester.

8. The method of claim 1, wherein,

the first message includes both a signed public key and a signed requestor identification related to the first requestor; and

the first encrypted secret is generated by encrypting the received identification associated with the first user using the embedded secret information and then encrypting the result using the public key received by the first requester.

9. A method for cryptographically secure retrieval of secret information embedded in a device, comprising:

receiving a request for retrieval of secret information related to a device, wherein the secret information is not related to any particular requestor of the secret information; and

performing processing to determine whether the secret information was previously derived;

in the event that the determination is negative, an encrypted secure response is generated such that a recipient of the response can recover the embedded secret information, wherein the embedded secret information can only be recovered by the sender of the request.

10. A method of recovering secret information embedded in a device, comprising:

sending a message to a device to request secret information embedded in the device, wherein the sent message includes a public key, and wherein the embedded secret information includes random information that is not related to any particular requestor of the embedded secret information, the embedded secret information having not been previously derived;

receiving an encryption secret in response to the transmitted message; and

the embedded secret is recovered from the encrypted secret.