Data to hardware binding with physical unclonable functions

The various technologies presented herein relate to binding data (e.g., software) to hardware, wherein the hardware is to utilize the data. The generated binding can be utilized to detect whether at least one of the hardware or the data has been modified between an initial moment (enrollment) and a later moment (authentication). During enrollment, an enrollment value is generated that includes a signature of the data, a first response from a PUF located on the hardware, and a code word. During authentication, a second response from the PUF is utilized to authenticate any of the content in the enrollment value, and based upon the authentication, a determination can be made regarding whether the hardware and/or the data have been modified. If modification is detected then a mitigating operation can be performed, e.g., the hardware is prevented from utilizing the data. If no modification is detected, the data can be utilized.

BACKGROUND

Techniques for protecting the integrity and/or confidentiality of data (e.g., software) may utilize message authentication codes (MACs) and encryption. However, by eliminating the necessity of storing and protecting keys, increased security of these techniques can be realized by making them less vulnerable to key extraction attacks.

There are several commercially available protections for field programmable gate arrays (FPGAs), wherein the protections can utilize encryption of a bitstream(s), e.g., via advanced encryption standard (AES). One solution utilizes an AES key that is one-time programmable and stored in non-volatile memory in the FPGA. Another solution stores the AES key in volatile memory on a device with a battery backup, in combination with a unique identifier (signature) that is hardcoded into the FPGA during manufacturing. During an initial enrollment process, a user-defined function value of the identifier is computed and stored on the system. At a later time, when the FPGA is again configured the computation is repeated and compared to the enrolled value.

However, these techniques are fundamentally insecure as they rely on secrets that are stored in nonvolatile (or battery backed volatile) memory on the device. This creates opportunities for key extraction and can also introduce a key storage problem. In the case of the unique identifier, the enrolled value must also be protected so that it cannot be extracted and used to spoof the verification step in a replay attack.

After a foundation of trust is established for the hardware, it is desirable that this trust be extended to a data to be employed by the hardware. Data cannot itself be secured by other data since, in this scenario, security data and malicious data exist within the same execution context. By consequence, no advantage is available to either side because any action taken by one side may also be taken or altered by the other side.

SUMMARY

The various technologies presented herein relate to binding data (e.g., software) to hardware, wherein the data is to be utilized by the hardware. The generated binding can be utilized to detect whether at least one of the hardware or the data has been modified between an initial moment (enrollment) and a later moment (authentication). In an embodiment, during enrollment, a cryptographic key is generated based on a signature (an identifier) of the data, S, (e.g., a hash of the data content), a first response P from a physical unclonable function (PUF) located on the hardware, and code word C from an error correcting code. During authentication, a second response, P′, can be generated from the PUF, and optionally a second code word C′, and such values can be used to ascertain whether the hardware is unmodified (e.g., P=P′) and further, whether the data is also unmodified (e.g., S is constant through the enrollment and authentication processes). If modification is detected, then a mitigating operation can be performed, e.g., the data is prevented from executing on the hardware. If no modification is detected, then the data can by utilized by the hardware.

In another embodiment, the binding between the data and the hardware can be relaxed by removing the data signature from the PUF's helper data. As such, the PUF can be reproduced correctly even if the data is modified. In a further embodiment, an encrypted cryptographic key can be generated and authenticated.

In an embodiment, the PUF response is based upon an operational state of the PUF and/or the hardware device. Hence, if either, or both, of the PUF and/or the hardware device are modified then the PUF response is altered from a PUF response that would be obtained if the PUF and the hardware device were in their original, unmodified states.

DETAILED DESCRIPTION

As used herein, the terms “component”, “device”, and “system” are intended to encompass computer-readable data storage that is configured with computer-executable instructions that cause certain functionality to be performed when executed by a processor. The computer-executable instructions may include a routine, a function, or the like. It is also to be understood that a component or system may be localized on a single device or distributed across several devices. The terms “component”, “device”, and “system” are also intended to encompass hardware configured to cause certain functionality to be performed, where such hardware can include, but is not limited to including, Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Application-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc.

Further, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or”. That is, unless specified otherwise, or clear from the context, the phrase “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, the phrase “X employs A or B” is satisfied by any of the following instances: X employs A; X employs B; or X employs both A and B. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from the context to be directed to a singular form. Additionally, as used herein, the term “exemplary” is intended to mean serving as an illustration or example of something, and is not intended to indicate a preference.

As previously mentioned, various techniques are available for binding data with hardware, wherein the data is to be utilized by (executed upon, employed by, used by) the hardware. However, such techniques are fundamentally insecure as they rely on secrets that are stored in nonvolatile (or battery backed volatile) memory on the device, which creates opportunities for key extraction and introduces a key storage problem.

To ensure secure binding between data and the hardware upon which it is to be utilized, an assurance is desired that neither the data nor the hardware have undergone any modification from a known initial condition. After a foundation of trust is established for the hardware (e.g., the hardware is unmodified), it is desirable that this trust be extended to any data to be utilized by the hardware (e.g., the data is also unmodified). Data cannot itself be secured by other data since, in this scenario, the security data and the malicious data exist within the same execution context. By consequence, no advantage is available to either side because any action taken by one side may also be taken or altered by the other side. Per the various embodiments presented herein, placing the primary security mechanism(s) in the hardware enables various defensive procedures to exist in a context below that of malicious data, undercutting the ability of the malicious data to disrupt the system.

For descriptive purposes herein, data is defined as any information and/or sequence of instructions that can be utilized by hardware; examples are software, compiled code, firmware, etc. Additionally, the term data is additionally intended to encompass FPGA bitstreams. In one or more situations it is desired that the integrity, confidentiality, or both of particular data is protected. For example, it is desired that the integrity of data that controls critical systems, such as medical devices, aircraft, infrastructure, etc., is protected. Commercial software companies (e.g., a data provider) may desire to encrypt their data to prevent competitors from analyzing it, and governments may need to encrypt data to protect classified information. As such, the following data security features may be desired:

a). Only authenticated data may be utilized by the hardware.

b). Only decrypted and authenticated data may be utilized by the hardware.

c). Data will only be utilized by one instance of hardware.

To achieve item (a) the data can authenticate itself to the hardware prior to utilization by the hardware. To achieve item (b), the data can be further encrypted with a key known to the hardware. To achieve item (c), the encryption key is known only to the hardware. In scenario (c), the hardware will only utilize authenticated data that the hardware itself previously encrypted; since only the hardware knows the decryption key the data cannot be utilized by (e.g., execute on) any other hardware.

Various embodiments described herein can provide the ability to bind data to the hardware that utilizes it. The various embodiments presented herein provide integrity of the data, and further, some can also provide confidentiality. In each exemplary embodiment the integrity, and confidentiality when applicable, is derived from a combination of a unique hardware identity, provided by a physical unclonable function (PUF), and an identity of the data, the data signature. For descriptive purposes herein, a hash of the data is used as its data signature; however, it is to be appreciated that other techniques for generating a data identity can also be utilized as applicable to the various embodiments presented herein. To facilitate understanding, an overview of a system for binding (enrolling) data with hardware, and subsequently analyzing the integrity of the binding (authentication) is presented, followed by various exemplary methods for binding of the data to the hardware and subsequent analysis of the binding.

FIG. 1illustrates a system100that can be utilized to bind data with a hardware device that is configured to utilize the data (or be configured in accordance with the data). Data110can be received at a device120(e.g., an integrated circuit, hereinafter IC120), wherein the IC120is configured to utilize the data110. In an exemplary embodiment, the IC120comprises a processor130and memory140, wherein the memory140comprises data that is accessible to the processor130and instructions that can be executed by the processor130. A data store150can store data utilized by one or more components included in the IC120. In an embodiment, the data110received at the IC120can be stored in the memory140, in another embodiment, the data110can be stored in the data store150for retrieval by the processor130.

The memory140can comprise an enrollment component160that is configured to generate an enrollment value165, wherein the enrollment value165is generated based upon a hash(es), a key(s), helper data, etc., from the hardware and/or the data, as required to enable binding of the data110to the IC120(e.g., during an enrollment phase).

The memory140can further include an authentication component170that is configured to generate an authentication value175, wherein the authentication value175is generated based upon the enrollment value165, a hash, key, etc., utilized to generate the enrollment value165, a newly generated hash(es), a newly generated key(s), error code, etc., as required to enable confirmation that one or more portions of the enrollment value165correspond and/or match with one of more portions of the authentication value175to facilitate confirmation of the binding between the data110and the IC120, and further, that neither the data110and/or the IC120have been modified between the time at which the initial enrollment phase was undertaken and the time that the authentication is being performed.

The authentication component170can be further configured to generate an indication178of whether the data110and the IC120are still in their original state (e.g., their respective states at the time of enrollment). In response to determining that respective data in the enrollment value165and the authentication value175match, the indication178can indicate that the IC120and data110are functioning as desired. In response to determining that the enrollment value165and the authentication value175do not match, the indication178can indicate that the IC120and data110are not functioning as desired, whereupon a subsequent operation can be performed, e.g, the authentication component170can attempt to reauthenticate the enrollment value165, utilization (e.g., execution) of the data110by the IC120can be terminated, a secondary operation that relies upon the indication178being in an expected state can be prevented from executing, etc.

As previously mentioned, the enrollment value165can be generated in conjunction with a PUF180, wherein, in response to a stimulus applied to the PUF180, the PUF180can generate an initial PUF value185(P) which can be utilized to generate the enrollment value165. A subsequent stimulus can be applied to the PUF180to generate a subsequent PUF value186(P′) as part of either generation of the enrollment value165and/or the authentication value175.

It is to be appreciated that while the enrollment value165and the authentication value175are depicted inFIG. 1as being separate items (e.g., different keys), the authentication value175can be a derivation of the enrollment value165. For example, the authentication value175can be based upon the enrollment value165, e.g., the enrollment value165is generated in conjunction with the response185(P), and authentication of the enrollment value165is performed as a function of the subsequent response186(P′) being applied to the enrollment value165to form the authentication value175.

A plurality of embodiments are now presented inFIGS. 2-9, whereinFIGS. 2-5relate to “strict hardware to data binding”, whileFIGS. 6-9relate to “relaxed hardware to data binding”. As further described herein, a plurality of enrollment and authentication processes can be performed based upon different combinations of one or more hashes, keys, error codes, encryption operations, etc., utilized to generate the enrollment value165and/or the authentication value175. In the various embodiments the following nomenclature is utilized: the PUF180of IC120(D) has an initial output value P and a future, noisy output value P′. C is a code word from an error correcting code, e is an error vector, and h( ) is a one-way hash function. Binding the data110(S) to the IC120can protect the integrity of the data110or prevent use of the data by unintended hardware.

The various embodiments presented herein utilize a fuzzy extraction procedure based upon h(P⊕C) in connection with ascertaining a PUF output value, wherein a combination of the PUF response P and a data signature S are utilized, e.g., h(P⊕S⊕C), or a variation thereof. In one or more embodiments presented with strict hardware to data binding, hardware and data can be bound together by preventing correct recovery of the PUF value if either the hardware or the data is modified. Further, some embodiments can provide data integrity. The binding can be accomplished by incorporating the data signature (e.g., a hash of the data) in the PUF's fuzzy extraction procedure during an enrollment process. Later, if a modified version of the data is presented to the hardware then the PUF will not be recovered correctly and the modified data will not be authenticated. This functionality can be utilized to prevent hardware from utilizing (e.g., executing) data with which it has not previously been enrolled. In an embodiment, the data signature S can be generated based upon at least one value in the data, e.g., a hash of the values included in the data.

FIGS. 2 and 3illustrate embodiments termed “strict hardware to data binding”. The embodiments presented inFIGS. 2 and 3can provide authentication but not data confidentiality.

FIG. 2illustrates an enrollment operation being performed, wherein the data110is being bound to the IC120. The respective acts 21-27 can be performed (e.g., generation of an enrollment value, key calculation, etc.), by the processor130, e.g., operating in conjunction with the data110, and/or the PUF180, wherein the processor130is executing the enrollment component160. It is to be understood, however, that the below functionality may be performed partially or entirely in hardware.

At 21, data110is received at the IC120, wherein data110has a data signature S.

At 22, a first instance of a cryptographic hash h(S) is generated by executing a hash function over S.

At 23, a first output value P is generated from the PUF180(e.g., in response to a stimulus applied to the PUF180).

At 24, a code word C is generated from an error correcting code.

At 25, from h(S), P, and C, h(S)⊕P⊕C is generated with respective exclusive OR (XOR) logical operators, termed herein “public data”.

At 26, a keyed hash hk(S) is calculated based upon S and a key k generated from h(P⊕h(S)). The keyed hash is unique to the combination of the data signature S and the key k. The keyed hash is denoted h[h(h(S)⊕P)|S] inFIG. 2.

At 27, the public data h(S)⊕P⊕C generated at act 25 is concatenated with the keyed hash hk(S) generated at act 26, forming h(S)⊕P⊕C|hk(S) (enrollment value165), denoted as h(S)⊕P⊕C|h[h(h(S)⊕P|S] inFIG. 2. Upon publication of the enrollment value165, the enrollment value165can be stored in the memory140, in a memory communicatively coupled to the IC120, e.g., a flash drive, a server on a network on which the IC120resides, etc. In an embodiment, the enrollment value165does not have to be stored in a protected manner.

FIG. 3illustrates an authentication operation being performed to confirm binding of the data110to the IC120, and further, that neither the data110and/or the IC120have been modified between the generation of the enrollment value165and the authentication operation. The respective acts 31-38 can be performed (e.g., key authentication, etc.), by the processor130, e.g., operating in conjunction with the data110, and/or the PUF180, wherein the processor130is executing the authentication component170. In other examples, one or more of such acts can be performed in hardware.

At 31, the enrollment value165is received and concatenated with the data110, S, to form S|h(S)⊕P⊕C|hk(S), denoted as S|h(S)⊕P⊕C|h[h(h(S)⊕P)|S] inFIG. 3.

At 32, a splitting operation is performed resulting in the formation of respective components h(S)⊕P⊕C, hk(S), and S. The hk(S) key is forwarded for comparison.

At 34, the PUF180is re-stimulated to generate a response value P′, wherein P′ indicates a current state of the PUF180. Ideally, if no modification of the PUF180has occurred since the initial generation of the enrollment value165, then P=P′ with a tolerable degree of noise (operational error), as encountered with fuzzy extraction technologies. If the PUF180has been modified, then P≠P′, wherein the difference between P and P′ is greater than the tolerable degree of noise.

At 35, any noise associated with the P′ value can be determined, and based thereon, a degree of effect of noise in the P′ value on the error code value C can be determined, wherein the error is e=P′⊕P. The calculation P′⊕P⊕C=C⊕e is performed.

At 36, C is recovered with the error correcting code and the calculation C⊕[P⊕h(S)⊕C]=P⊕h(S) is performed. The h(h(S)⊕P⊕C⊕C′) component is generated and forwarded to be concatenated with the S component split at act 32. Concatenation results in a key h(S)⊕P⊕C⊕C′|S.

At 37, a key h[h(h(S)⊕P⊕C⊕C′)|S is formed from applying a cryptographic hash to the key h(S)⊕P⊕C⊕C′|S generated at act 36. In an embodiment, the key h(S)⊕P⊕C⊕C′|S can be considered to be the authentication value175.

At 38, a keyed hash hk(S) is calculated from S, and is compared with the h(S)⊕P⊕C⊕C′|S comprising the authentication value175. The data110and the IC120are determined to be unmodified based upon the code words C=C′, and a difference between P and P′ being within an acceptable magnitude of error and S being unmodified. Hence, perFIG. 3, h[h(h(S)⊕P)|S] (from the key165) equals h[h(h(S)⊕P⊕C⊕C′)|S] (from the key175) when C=C′, the respective values for P cancel out, and accordingly, S is common to both keys.

During the enrollment operation presented inFIG. 2, at act 25, the processor130calculates the public data h(S)⊕P⊕C. This public data can be used by the IC120during acts 33 and 36 to recover the PUF value P of the PUF180. It is this modification to standard fuzzy extraction helper data that binds the data signature S to the IC120such that a modification(s) to the IC120prevents recovery of the PUF value P. As a result, if either the data110or the IC120is changed, then the PUF value P will not be correctly recovered in act 36 of the authentication operation presented inFIG. 3. This can prevent recovery of the key k used for the keyed hash, and so the data110will not be authenticated. The IC120can then respond appropriately, for example, by refusing to utilize the data110.

The embodiments presented inFIGS. 2 and 3can be modified to incorporate encryption. Encryption can enable protection of both the integrity and the confidentiality of the data110and can prevent devices other than the device (e.g., IC120) with which the data110is originally enrolled from utilizing the data110.FIGS. 4 and 5illustrate embodiments where encryption is being utilized as part of the enrollment and authentication operations.

FIG. 4, illustrates the encrypted enrollment operation being performed, wherein at 41, data110having a data signature S is sent to IC120.

At 42, h(h(S)⊕P) is calculated and a key k is generated from the value of h(h(S)⊕P).

At 43, the data110is encrypted by calculating Ek(S) from the key k.

At 45, P⊕h(Ek(S))⊕C, Ek(S), and h(S) are concatenated and published as Ek(S)|P⊕h(Ek(S))⊕C|h(S).

FIG. 5, illustrates an authentication operation being performed, wherein at 51, Ek(S)|P⊕h(Ek(S))⊕C|h(S) is sent to IC120.

At 52, Ek(S)|P⊕h(Ek(S))⊕C|h(S) is split into its respective components for subsequent processing. As shown, a first instance of h(S) is made available for comparison (as further described at act 57) and a second instance of h(S) is made available for recovery of k (as further described at act 55).

At 54, C is recovered with the error correcting code and C⊕[P⊕h(Ek(S))⊕C]⊕h(Ek(S))=P is calculated.

At 55, h(P⊕h(S)) is calculated and k is recovered, wherein h(P⊕h(S)) is calculated based upon h(S) provided at act 52, and P calculated at act 54 (as shown by the respective hashed lines).

At 57, h(S) is calculated and a comparison performed between the h(S) component received at act 52, and the h(S) component generated by hashing S at act 57.

The enrollment phase of the embodiment presented inFIG. 4is similar to embodiment presented inFIG. 2, except that the key k can be utilized to encrypt the data110, rather than to compute a keyed hash. Accordingly, after the enrollment phase presented inFIG. 4, the unencrypted data S is no longer needed.

At act 53 of the authentication procedure presented inFIG. 5, the IC120can combine its noisy PUF measurement P′ with a hash of the encrypted data and the modified helper data P⊕h(Ek(S))⊕C. After recovering C, the initial PUF P measurement can be reproduced in act 54. Note that in act 54 of the authentication operation, P is correct if the encrypted data is authentic and if the IC120has not been modified. Act 57 can verify that the decrypted data is authentic. In the embodiment presented inFIGS. 4 and 5, the data110can be bound to the IC120, which can prevent the data110from being utilized by (e.g., executing on) any other hardware, and does not require any secret values to be stored or shared.

In other embodiments, keys can be generated from h(P⊕h(S)). The XOR logic is not necessary and can be replaced with some other combination of P and h(S), such as concatenation, logical AND, addition, etc.

FIGS. 2-5present embodiments termed strict hardware to data binding, the followingFIGS. 6-9present embodiments termed relaxed hardware to data binding. In the embodiments presented inFIGS. 2-5the fuzzy extractor helper data can be modified by including the data signature. Such approaches can bind the hardware (e.g., IC120) and the data (e.g., data110) by preventing the correct PUF value from being output by the fuzzy extraction recovery procedure if either the hardware or the data has been modified. In various embodiments, the binding between the data and the hardware can be relaxed by removing the data signature from the PUF's helper data. As such, the PUF180can be reproduced correctly even if the data is modified. However, the encryption keys are generated from both the data signature and the PUF response, achieving a cryptographic binding. As with the embodiments presented inFIGS. 2-5, various embodiments that can provide relaxed binding can also protect data integrity, and various embodiments can further protect both integrity and confidentiality.

FIGS. 6 and 7present an embodiment that can enable the PUF180(e.g., PUF value P) to be recovered independently of the data signature (e.g., S), and can protect the integrity of the data but not its confidentiality.

FIG. 6illustrates the enrollment operation being performed, wherein at 61, data110having a data signature S is received at IC120.

At 62, the PUF180is stimulated to generate a response value P.

At 63, the h(h(S)⊕P) value is calculated based upon hashing S and P, wherein the h(h(S)⊕P) value is published.

At 64, a code word C is selected from an error correction code, and based thereon, a value P⊕C is calculated and published.

FIG. 7illustrates the authentication operation being performed, wherein at 71, the h(h(S)⊕P) value generated at act 63 is received at the IC120is concatenated with S, to form S|h(h(S)⊕P).

At 72, the value P⊕C generated at act 64 is utilized to recover P through a normal fuzzy extraction procedure.

At 73, h(h(S)⊕P) is calculated, and a comparison performed between this value and the h(h(S)⊕P) value received at act 71.

In an embodiment, the integrity of the data can be protected by the hash h(h(S)⊕P). Here, if the comparison in act 73 of the authentication process is correct then the data110is authenticated, and a determination can be made that neither the hardware (e.g., IC120) nor the data (e.g., data110) has been modified.

In a further embodiment, a keyed hash can be utilized in conjunction with one or more of the acts presented inFIGS. 6 and 7. In the following embodiment the enrollment operation is based upon acts 61-64 ofFIG. 6, however operations performed at act 63 will be replaced with key generation and hashing operations 63A and 63B.

At 61, data110having a data signature S is received at IC120.

At 62, the PUF180is stimulated to generate a response value P.

At 63A, rather than the h(h(S)⊕P) value being calculated and published (per act 63), a key h(P⊕h(S)) is calculated, and a key k is generated from this value.

At 63B, a keyed hash hk(S) is calculated and this value is published.

At 64, a code word C is selected from an error correction code, and based thereon, a value P⊕C is calculated and published.

Further, the following authentication operation is based upon acts 71-73 ofFIG. 7, but a keyed hash hk(S) is utilized instead of the h(h(S)⊕P) utilized in acts 71-73. Hence, the authentication acts become:

At 71A, S|hk(S) is received at the IC120.

At 72, the value P⊕C generated at act 32 is utilized to recover P through a normal fuzzy extraction procedure.

At 73A, h(P⊕h(S)) is calculated and the key recovered.

At 73B, a keyed hash hk(S) is calculated and a comparison performed between the newly calculated keyed hash hk(S) and the keyed hash hk(S) calculated at act 63B.

A modification can be made to the foregoing embodiments to enable protection of both the integrity and the confidentiality of the data110. By applying encryption, other hardware can be prevented from utilizing the data110. Turning toFIGS. 8 and 9

FIG. 8presents an embodiment illustrating an enrollment operation being performed, wherein at 81, data110having a data signature S is received at IC120.

At 82, the value h(h(S)⊕P) is calculated and a key k from this value is generated.

At 83, the data signature S is encrypted as Ek(S) with the key k generated at act 82.

At 84, the encryption Ek(S) is concatenated with h(S), and published as Ek(S)|h(S).

At 85, a code word C is selected from an error correction code, P⊕C is calculated and published.

FIG. 9presents an embodiment illustrating an authentication operation being performed, wherein at 91, the Ek(S)|h(S) concatenation is received at the IC120.

At 92, P⊕C is utilized to recover P through a normal fuzzy extraction procedure.

At 93, h(P⊕h(S)) is calculated and the key k recovered.

At 95, h(S) is calculated and a comparison performed between the newly calculated hash h(S) and the hash h(S) utilized at act 84.

The embodiments presented inFIGS. 8 and 9can achieve similar protections to those presented inFIGS. 4 and 5; if the hash in act 95 of the authentication matches the publically stored value then the data (e.g., data110) is the same data that was enrolled, and because the key was correctly recovered it can be determined that the hardware (e.g., IC120) has not changed. The embodiment presented inFIGS. 8 and 9differs from the embodiment inFIGS. 4 and 5in that the fuzzy extraction operation can be a standard PUF fuzzy extraction, rather than a fuzzy extraction that combines the PUF output with the data signature, as such it is possible for the IC120to recover its PUF independently of the data110.

It is to be noted that the foregoing embodiments make use of the value h(P⊕h(S)). The XOR operation is not a requirement and can be replaced with any combination of P and h(S).

As shown inFIGS. 2, 4, 6, and 8, an enrollment component160is presented, wherein the processor130can operate in combination with the enrollment component160, the data110, and/or the PUF180, to perform the respective acts (e.g., generation of the enrollment value165, etc.) presented inFIGS. 2, 4, 6, and 8. In an embodiment, the processor130is executing the enrollment component160. It is to be understood, however, that the respective functionality may be performed partially or entirely in hardware.

Further, as shown inFIGS. 3, 5, 7, and 9, an authentication component170is presented, wherein the processor130can operate in combination with the authentication component170, the data110, and/or the PUF180, to perform the respective acts (e.g., authentication of the enrollment value, etc.) presented inFIGS. 3, 5, 7, and 9. In an embodiment, the processor130is executing the authentication component170. It is to be understood, however, that the respective functionality may be performed partially or entirely in hardware.

FIGS. 10 and 11illustrate exemplary methodologies relating to binding data to hardware, wherein the data is to execute on the hardware. While the methodologies are shown and described as being a series of acts that are performed in a sequence, it is to be understood and appreciated that the methodologies are not limited by the order of the sequence. For example, some acts can occur in a different order than what is described herein. In addition, an act can occur concurrently with another act. Further, in some instances, not all acts may be required to implement the methodologies described herein.

FIG. 10illustrates a methodology1000for enrolling data with hardware, wherein the data is to be utilized by the hardware. In an embodiment, the hardware is utilized to secure the data, such that the hardware will not utilize (e.g., execute) the data in the event that the data and/or the hardware has been modified between enrolling the data with the hardware and a subsequent authentication operation.

At1010, a data signature S is generated for the data that is to be utilized by a hardware device.

At1020, a PUF response is generated, wherein the PUF response is generated by a PUF located on the hardware device. In an embodiment, the PUF response is based upon an operational state of the PUF and/or the hardware device. Hence, if either, or both, of the PUF and/or the hardware device are modified then the PUF response is altered from a PUF response that would be obtained if the PUF and the hardware device were in their original, unmodified states.

At1030, an enrollment value is generated based upon a combination of S and P.

FIG. 11illustrates a methodology1100for authenticating a data with a hardware device, wherein the data is to be utilized by the hardware device. As previously mentioned, if either of the hardware device or the data have been modified since the data was enrolled with the hardware device, the hardware device is prevented from utilizing the data. At1110, a data signature S′ is obtained (e.g., generated/received) for the data that is to be utilized by the hardware.

At1120, a PUF response P′ is generated, wherein P′ is generated by the PUF located on the hardware.

At1130, the enrollment value generated during the enrollment process (e.g., as described in methodology1000) is obtained. As previously described, the enrollment value comprises values for S and P obtained during the enrollment of the data with the hardware.

At1140, S and P are extracted from the enrollment value obtained at1130.

At1150, an authentication operation is performed wherein the PUF response P extracted from the enrollment value and the newly generated PUF response P′ are compared, and further, the data signature S extracted from the enrollment value and the newly generated data signature S′ are also compared.

At1160, a determination is made regarding whether S=S′? In the event that S≠S′, then the methodology advances to1180, whereupon a notification can be generated indicating that owing to S≠S′ it is presumed that the data has been modified between generation of S and S′. Accordingly, the data can be prevented from being utilized by the hardware. The methodology can return to1120, whereupon a further data signature S′ can be generated, and the authentication process repeated.

Further, at1160, in response to a determination that S=S′ the methodology can advance to1170, wherein a determination can be made whether P=P′? In the event that P≠P′, then the methodology advances to1180, whereupon a notification can be generated indicating that owing to P≠P′ it is presumed that the hardware has been modified between generation of P and P′. Accordingly, the hardware can be prevented from utilizing the data. The methodology can return to1120, whereupon a further data signature S′ can be generated, and the authentication process repeated. In response to a determination that P=P′ (and the previously determined S=S′) the hardware and data are determined to be in respectively unmodified states and the data can be utilized by the hardware. At1170, in the event of P≠P′, the authentication process can be repeated to confirm that the PUF value P′ is correct. For example, the PUF (and the hardware) may have changed temperature during operation, and repeating the authentication process may subsequently result in the V being correctly generated once the operating temperature of the PUF returns to the operating temperature when the PUF value P was first generated during the enrollment process.

Referring now toFIG. 12, a high-level illustration of an exemplary computing device1200that can be used in accordance with the systems and methodologies disclosed herein is illustrated. For example, the computing device1200includes the IC120, wherein data110is to execute on the IC120. The computing device1200includes at least one processor1202(e.g., operating as processor130) that executes instructions that are stored in a memory1204. The instructions may be, for instance, instructions for implementing functionality described as being carried out by one or more components discussed above or instructions for implementing one or more of the methods described above. The processor1202may access the memory1204by way of a system bus1206. In addition to storing executable instructions, the memory1204may also store operating parameters, required operating parameters, and so forth.

The computing device1200additionally includes a data store1208that is accessible by the processor1202by way of the system bus1206. The data store1208may include executable instructions, operating parameters, required operating parameters, etc. The computing device1200also includes an input interface1210that allows external devices to communicate with the computing device1200. For instance, the input interface1210may be used to receive instructions from an external computer device, from a user, etc. The computing device1200also includes an output interface1212that interfaces the computing device1200with one or more external devices. For example, the computing device1200may display text, images, etc., by way of the output interface1212.

Additionally, while illustrated as a single system, it is to be understood that the computing device1200may be a distributed system. Thus, for instance, several devices may be in communication by way of a network connection and may collectively perform tasks described as being performed by the computing device1200.