Patent Description:
It is the object of the present invention to provide a method and system for thwarting personal identification number retry attacks in a trusted platform module.

Methods, systems, and computer readable mediums that store code for performing methods are described herein. In one aspect, a method for thwarting personal identification number (PIN) state replay attacks in a trusted platform module (TPM) is implemented in a system on a chip (SOC). The SOC comprises a plurality of programmable fuses and an on-die random access memory (RAM) that stores a TPM state. The TPM state comprises a TPM state PIN-attempt-failure count and a TPM state fuse count. The method comprises initializing the TPM, where the on-die RAM stores a blown-fuse count comprising a count of currently blown fuses of the plurality of programmable fuses. The initialization comprises at least, in response to the blown-fuse count being greater than the TPM state fuse count, incrementing the TPM state PIN-attempt-failure count. The method further comprises receiving a PIN in a first PIN attempt for accessing a system protected by the TPM. In response to the TPM state PIN-attempt-failure count satisfying a PIN-attempt-failure count policy, and in response to the received PIN being correct, the method comprises clearing the TPM state PIN-attempt-failure count. In response to the received PIN being incorrect, the method comprises blowing a fuse and incrementing the blown-fuse count in the on-die RAM. In response to the fuse blow failing, the method comprises halting TPM activity. In response to the fuse blow succeeding, the method comprises incrementing the TPM state PIN-attempt-failure count and setting the TPM state fuse count equal to the blown-fuse count in the on-die RAM. The method further comprises saving the TPM state to an off-die non-volatile (NV) memory to update a NV state stored in the off-die NV memory.

Further features and advantages of embodiments, as well as the structure and operation of various embodiments, are described in detail below with reference to the accompanying drawings. It is noted that the methods and systems are not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Additional embodiments will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.

The present specification and accompanying drawings disclose one or more embodiments that incorporate the features of the disclosed embodiments. The scope of the embodiments is not limited only to the aspects disclosed herein. The disclosed embodiments merely exemplify the intended scope, and modified versions of the disclosed embodiments are also encompassed. Embodiments are defined by the claims appended hereto.

As described above, a TPM may be configured to provide security-related functions involving cryptographic keys. The TPM may hold the sensitive keys (e.g., long cryptographic keys) and release a key when a correct corresponding PIN is provided by a user. A TPM may be configured to prevent "PIN hammering" attacks, where an attacker repeatedly tries PIN combinations to find a correct PIN, by implementing replay protection measures that keep track of how many times an incorrect PIN is entered. The cryptographic key may be cleared when the number of PIN attempt failures exceeds a specified threshold, for example, according to a PIN attempt failure policy of the TPM. The replay protection measures may be relatively easy to implement on a discrete TPM chip (e.g., a system on a chip (SOC)) that has embedded non-volatile (NV) flash memory to record and preserve PIN attempt failure counts. However, it may be uneconomical to add NV flash memory to a large SOC die (e.g., an SOC built on leading-edge process nodes that has an on-die CPU) to support an embedded security processor used as the TPM. Without any form of "long term memory" on the SOC die to record how many PIN attempt failures have occurred, an attacker can try a presumably safe number of PIN combinations, and then reset the SOC to a previous state in which the PIN tries were not yet recorded (e.g., replay an earlier state that had a lower number of PIN tries recorded). The attacker may then try more PINs. By repeating this "replay" process, the attacker can eventually enumerate an entire PIN space to release one or more keys and steal the PINs authorized in the TPM.

The methods and systems described herein provide PIN attack countermeasures, which may be applied to large SOCs comprising an on-die CPU, using one-time programmable fuses that can be blown within the SOC. The fuses provide large SOCs, such as those on leading edge process nodes (e.g., <NUM> process), a way to permanently record a state of the TPM (e.g., how many PIN attempt failures have occurred). As fuses can be very expensive, both economically and in terms of SOC die area, they may not be reasonably allocated in large quantities. Methods are provided herein that utilize fuses in a conservative manner, which makes it practical to implement a TPM embedded within a large SOC, and provide effective "PIN hammering" countermeasures.

The present disclosure describes three embodiments of a TPM that may be embedded on an SOC, where each embodiment utilizes a plurality of programmable fuses (e.g., one-time programable fuses) for protecting the TPM from PIN hammering attacks (e.g., replay attacks and/or voltage draw attacks). For example, the TPM may blow fuses during authentication of PIN entries, where the number of blown fuses functions as a counter. The first embodiment may be referred to as FUSE BASED REPLAY PROTECTION WITH CONSERVATIVE FUSE USAGE. In this first embodiment a fuse is utilized depending on whether an incorrect PIN has been entered for access to a system protected by the TPM. The second embodiment may be referred to as FUSE BASED REPLAY PROTECTION WITH AGGRESSIVE FUSE USAGE AND FUSE VOLTAGE CUT COUNTERMEASURES. In this second embodiment a fuse may be utilized for each PIN entry attempt, independent of whether the entered PIN is correct or incorrect. The third embodiment may be referred to as FUSE BASED REPLAY PROTECTION WITH DYNAMIC FUSE USAGE AND FUSE VOLTAGE CUT COUNTERMEASURES. In this third embodiment the TPM dynamically determines whether to apply the conservative fuse utilization method or the aggressive fuse utilization method depending on the status of prior PIN entry attempts (e.g., whether a currently entered PIN has previously passed a PIN verification test in response to a PIN entry attempt, i.e., was previously verified as a correct PIN). In addition describing the three embodiments with respect to <FIG>, an example of each embodiment is provided in pseudo-code below in section II.

Fuse based replay protection may be implemented in various ways. For example, <FIG> is a block diagram <NUM> of a system comprising a trusted platform module (TPM) implemented on a system on a chip (SOC) for verifying PIN entries and protecting against PIN hammering attacks, according to an example embodiment. As shown in <FIG>, system <NUM> comprises a SOC <NUM>, an off-die non-volatile (NV) memory <NUM>, a TPM <NUM>, a central processing unit (CPU) <NUM>, an SOC voltage <NUM>, and a fuse voltage <NUM>. TPM <NUM> comprises TPM logic <NUM> and a plurality of programmable fuses <NUM>. System <NUM> is described in detail as follows.

SOC <NUM> may comprise an integrated circuit having various components on a substrate or microchip. For example SOC <NUM> may integrate a microcontroller, microprocessor (e.g., CPU <NUM>), and/or one or more processing cores with on-die random access memory devices, input/output ports (not shown), and may include one or more peripherals (e.g., a graphic processing unit (GPU), Wi-Fi and cellular network radio modems, etc.). SOC <NUM> may comprise TPM <NUM>, which may be communicatively coupled to an external long-term memory, such as off-die NV memory <NUM>. TPM <NUM> may comprise plurality of programmable fuses <NUM> that may be utilized as an on-die long-term counter. TPM <NUM> may be configured to execute TPM logic <NUM>, to verify PIN entries, blow fuses of the plurality of programmable fuses <NUM>, and write/read TPM states to/from off-die NV memory <NUM>. Although the embodiments described herein with respect to <FIG> refer to a TPM or TPM logic, any other suitable system and/or logic that utilizes a PIN, entered by a user to release or authorize usage of a long cryptographic key, may perform the embodiments described herein and may be referred to as a TPM and/or TPM logic herein. Moreover, although the embodiments described herein with respect to <FIG> refer to PINs (personal identification numbers), the embodiments described herein may apply to any suitable passwords or passcodes comprising any suitable characters or symbols, which may be referred to herein as a PIN.

SOC <NUM> may comprise one or more pins for providing power to SOC <NUM> and various components on the SOC. For example, SOC voltage <NUM> and fuse voltage <NUM> may be provided on one or more pins of SOC <NUM>. Fuse voltage <NUM> may be configured to provide power to blow a fuse of the plurality of programmable fuses <NUM>.

Although the embodiments described herein comprise a TPM <NUM> implemented on an SOC <NUM> (as described with respect to <FIG>), TPM <NUM> may also be implemented in other types of devices such as a computing device comprising a traditional motherboard-based computer architecture. Such a computing device may have components that are separated based on function and that are connected through a central interfacing circuit board. For example, as described in more detail below with respect to <FIG>, the TPM system may be implemented in a computing device <NUM>, which may comprise any suitable computing device, such as a stationary computing device (e.g., a desktop computer or personal computer), a mobile computing device (e.g., a Microsoft® Surface® device, a personal digital assistant (PDA), a laptop computer, a notebook computer, a tablet computer such as an Apple iPad™, a netbook, etc.), a mobile phone (e.g., a cell phone, a smart phone such as an Apple iPhone, a phone implementing the Google® Android™ operating system; a Microsoft® Windows phone, etc.), a wearable computing device (e.g., a head-mounted device including smart glasses such as Google® Glass™, Oculus Rift® by Oculus VR, LLC, etc.), a gaming console/system (e.g., Nintendo Switch®, etc.), an appliance, a set top box, etc..

The plurality of programmable fuses <NUM> may comprise a bank of one-time programmable fuses. For example, the plurality of programmable fuses <NUM> may be configured as a programmable read-only memory and utilized as a counter, where the setting of each bit of the counter is locked by a fuse or anti-fuse. Count data stored in the plurality of programmable fuses <NUM> may be permanent. In one example, fuses of the plurality of programmable fuses <NUM> may blown one by one, where a fuse counter value may comprise an integer between zero through the number of available fuses to represent the state of the fuse bank. In some embodiments, the fuse counter value may be incremented (by blowing a fuse) but may not be decremented.

Plurality of programmable fuses <NUM> may receive extra power from fuse voltage <NUM> to blow a fuse. TPM logic <NUM> may attempt to blow fuses of plurality of programmable fuses <NUM> to increment the fuse counter. However, an attacker may be able to control voltage input to the SOC including to the pin that supplies fuse voltage <NUM>. Thus the attacker may have the ability to detect extra power being drawn for fuse voltage <NUM>, which may signal an attempt to blow a fuse by the TPM, and may immediately cut the power to prevent the fuse from being blown. Fuse based methods are provided herein for preventing replay attacks by combatting this type of fuse voltage cut attack.

Off-die NV memory <NUM> comprises NV storage that is external to SOC <NUM> and available to TPM logic <NUM> for storing TPM <NUM> state information. TPM logic <NUM> may encrypt and integrity protect the state information that is saved to off-die NV memory <NUM> to prevent the disclosure or modification of the state information. Although the state information may be encrypted, an attacker may be able to replay previously signed state information in TPM <NUM>, by copying state information from off-die memory <NUM>, and after a newer state is written to off-die memory <NUM> by TPM logic <NUM>, the attacker may re-write the earlier state over the newer state so that the next time TPM <NUM> initializes, TPM logic <NUM> may read the rewritten earlier state information from off-die memory <NUM> and store it in a TPM state (e.g., TPM state <NUM> or TPM state <NUM>, described below). In this manner, the attacker may be able to lower a count of blown fuses (e.g., TPM state fuse count <NUM>, described below), which is included in the TPM state. Methods are provided herein for combating such replay attacks.

TPM <NUM> may operate in various ways to perform its functions. For instance, <FIG> is a flowchart <NUM> representing multiple methods for performing fuse based replay protection, according to an example embodiment. In an embodiment, TPM <NUM> may operate according to flowchart <NUM>. Flowchart <NUM> is described as follows with reference to <FIG> and <FIG>.

<FIG> is a block diagram of a system <NUM> comprising a TPM with a counter comprising a plurality of fuses for verifying PIN entries and performing fused based replay protection, according to an example embodiment. For example, system <NUM> comprises TPM <NUM>, off-die NV memory <NUM>, TPM logic <NUM>, an on-die random access memory (RAM) <NUM>, plurality of programmable fuses <NUM>, and fuse voltage <NUM>. TPM logic <NUM> comprises a PIN-attempt-failure count policy <NUM>, an initialization manager <NUM>, a dependent fuse blow manager <NUM>, and an independent fuse blow manager <NUM>. On-die RAM <NUM> comprises a blown-fuse count <NUM> and a TPM state <NUM>. TPM state <NUM> comprises a TPM state fuse count <NUM>, a TPM state PIN-attempt-failure-count <NUM>, and a TPM state PIN-key table <NUM>. Off-die NV memory <NUM> comprises a NV state <NUM>. NV state <NUM> comprises a NV state fuse count <NUM>, a NV state PIN-attempt-failure count <NUM>, and a NV state PIN-key table <NUM>.

On-die RAM <NUM> may comprise any suitable memory device such as a static RAM (SRAM) or dynamic RAM (DRAM). In some embodiments, on-die RAM <NUM> may be part of TPM <NUM>. On-die RAM <NUM> may store variables utilized by TPM logic <NUM> including blown-fuse count <NUM> and TPM state <NUM> variables such as TPM state fuse count <NUM> and TPM state PIN-attempt-failure count <NUM>.

Blown-fuse count <NUM> may comprise a current count of blown fuses in the plurality of programmable fuses <NUM>. TPM state fuse count <NUM> may comprise a count for blown fuses in the plurality of programmable fuses <NUM> as stored in TPM state <NUM>. TPM state fuse count <NUM> may have the same value as blown-fuse count <NUM>, but it may lag behind depending on conditions of TPM <NUM>. TPM state PIN-attempt-failure count <NUM> may comprise an integer value indicating the number of failed PIN attempts for a PIN. In some embodiments, TPM state PIN-attempt-failure count <NUM> may comprise an array of integer values, where each value in the array indicates the number of failed PIN attempts for a corresponding PIN that may be processed by TPM <NUM>. An upper bound may be assumed for the number of PINs allowed in the TPM, and an index into the TPM state PIN-attempt-failure count <NUM> array may be used to specify a specific PIN. TPM state <NUM> may include additional variables. For example, TPM state <NUM> may comprise PIN-key table <NUM> that may be populated with authorized (e.g., correct) PINs and respective cryptographic keys that are released when a correct PIN is entered (e.g., to gain access to a system that is PIN protected by TPM <NUM>). NV state <NUM> may comprise a saved copy from TPM state <NUM>. For example, NV state fuse count <NUM>, NV state PIN-attempt-failure count <NUM>, and NV state PIN-key table <NUM> may comprise copies of TPM state fuse count <NUM>, TPM state PIN-attempt-failure count <NUM>, and TPM state PIN-key table <NUM> respectively.

In some embodiments, TPM logic <NUM> includes only one of dependent fuse blow manager <NUM> and independent fuse blow manager <NUM>. In other embodiments, both of dependent fuse blow manager <NUM> and independent fuse blow manager <NUM> may be included in TPM logic <NUM>. For example, TPM logic <NUM> may include only dependent fuse blow manager <NUM>, only independent fuse blow manager <NUM>, or both of dependent fuse blow manager <NUM> and independent fuse blow manager <NUM>.

In some embodiments system <NUM> may be implemented in system <NUM>. For purposes of illustration, system <NUM> is described in detail as follows with respect to flowchart <NUM> of <FIG>.

Flowchart <NUM> begins with step <NUM>. In step <NUM>, the TPM may be initialized. For example, initialization manager <NUM> of TPM logic <NUM> may be configured to initialize TPM <NUM> by updating and/or clearing information stored in on-die RAM <NUM>. Initialization may be performed when TPM logic <NUM> is newly instantiated or when TPM <NUM> is restarted (e.g., after SOC <NUM> has been powered down). The initialization process may be configured to detect when a replay attack occurred in a previous PIN attempt, and penalize the attacker by incrementing the TPM state PIN-attempt-failure count <NUM> (described in more detail below). Steps taken during initialization may vary depending conditions of data stored in on-die RAM <NUM> or the ability to read NV state <NUM> information into TPM state <NUM>. For example, if a failure occurs in reading NV state <NUM> into TPM state <NUM>, initialization manager <NUM> may be configured to treat this situation as a fresh TPM instance and reset the variables in TPM <NUM>. For example, initialization manager <NUM> may be configured to determine the number of fuses blown in the plurality of programmable fuses <NUM> and store the determined number of blown fuses in blown-fuse count <NUM> of on-die RAM <NUM>. Initialization manager <NUM> may also be configured to store blown-fuse count <NUM> to TPM state fuse count <NUM> and/or clear TPM state PIN-attempt-failure-count <NUM> (e.g., to zero), as if no PIN failures have occurred yet. Where TPM logic <NUM> is able to read NV state <NUM> information and store it as TPM state <NUM> information, TPM logic <NUM> may be configured to compare the newly written TPM state fuse count <NUM> to blown-fuse count <NUM>, and if the count values do not match, this may indicate a replay attack has occurred. In response, TPM state logic may be configured to increment TPM state PIN-attempt-failure count <NUM> to adjust for the replay attack and penalize the attacker (e.g., when the PIN-attempt-failure count policy <NUM> is applied, as described in more detail below).

Steps taken during initialization may also vary depending which method of fuse based replay protection is implemented (e.g., (<NUM>) fuse based replay protection with conservative fuse usage (i.e., the first embodiment), (<NUM>) fuse based replay protection with aggressive fuse usage and fuse voltage cut countermeasures (i.e., the second embodiment), or (<NUM>) fuse based replay protection with dynamic fuse usage and fuse voltage cut countermeasures (i.e., the third embodiment)), which will be described in more detail below.

In step <NUM>, a PIN attempt entry may be received. For example, a user may enter a PIN to gain access to a system that is PIN protected by TPM <NUM> (e.g., CPU <NUM>, a computer device, a phone, an application, etc.), and the PIN may be received by TPM logic <NUM> for verification that the received PIN is correct. For example, TPM logic <NUM> may be configured to compare the received PIN to PINs registered in TPM state PIN-key table <NUM> to determine that the received PIN is an authorized PIN for gaining access to the system. In some embodiments, TPM <NUM> may be configured to verify multiple PINs (e.g., PINs <NUM> - X). In this regard, TPM state PIN-attempt-failure count <NUM> may comprise a plurality of counts in an array (e.g., PIN-attempt-failure count [X]) where each count of the array corresponds to one of the PINs in TPM state PIN-key table <NUM>).

In step <NUM>, the received PIN may be tested as to whether it is a correct PIN. For example, TPM logic <NUM> may be configured to compare the received PIN value to one or more correct PINs (e.g., authorized PINs) in TPM state PIN-key table <NUM>. Depending on which embodiment is in play, the PIN authorization process may vary. In the first embodiment, if the PIN is incorrect (e.g., not authorized) TPM logic <NUM> may proceed to step <NUM> and blow a fuse to increase the count of failed PIN attempts, whereas if the PIN is correct, TPM logic <NUM> may proceed to step <NUM> without blowing a fuse, thereby conserving fuses of the plurality of programmable fuses <NUM>. In the second embodiment, from step <NUM>, TPM logic <NUM> may be configured to proceed to step <NUM> to blow a fuse when the received PIN is incorrect and may proceed to step <NUM> and blow a fuse even when the received PIN is correct (e.g., TPM logic may be configured to blow a fuse whether or not the entered PIN is determined to be correct). In this manner, TPM logic <NUM> may aggressively pursue attackers that cut or reduce fuse voltage <NUM> before the voltage reaches a magnitude great enough to blow the fuse, and thereby avoid incrementing PIN-attempt-failure counts. In the third embodiment, TPM logic <NUM> may be configured to dynamically determine whether to proceed to step <NUM> and blow a fuse only when a PIN has been determined to be incorrect, or proceed via both of steps <NUM> and <NUM> and blow a fuse whether or not the received PIN was determined to be correct. In this manner, under some conditions (e.g., when the received PIN was verified as correct PIN in a prior PIN entry attempt), TPM logic <NUM> may more conservatively utilize plurality of programmable fuses <NUM>, and in other conditions (e.g., in instances where the received PIN was not previously verified as being correct), TPM logic <NUM> may be configured to use the more aggressive approach as a countermeasure to a fuse voltage cut attack (as described in more detail below).

In step <NUM>, TPM state values may be stored to off-die NV memory. For example, TPM logic <NUM> may be configured to write TPM state <NUM> (e.g., including TPM state fuse count <NUM>, TPM state PIN-attempt-failure count <NUM>, and TPM state PIN-key table <NUM>) to off-die NV memory <NUM> as NV state <NUM> (e.g., as NV state fuse count <NUM>, NV state PIN-attempt-failure count <NUM>, and NV state PIN-key table <NUM>).

In step <NUM>, a PIN result may be returned. For example, TPM logic <NUM> may be configured to return a result that indicates whether the user has permission to access the system protected by TPM <NUM>.

As described above, TPM logic <NUM> of <FIG> may include dependent fuse blow manager <NUM> in embodiments providing fuse based reply protection with conservative fuse usage.

TPM <NUM> may operate in various ways to perform its functions. For instance, <FIG> is a flowchart <NUM> of a method for implementing fuse based replay protection with conservative fuse usage, according to an example embodiment. In an embodiment, TPM logic <NUM> may operate according to flowchart <NUM>. Flowchart <NUM> is described as follows with reference to <FIG> and <FIG>.

Flowchart <NUM> begins with step <NUM>. In step <NUM>, the TPM may be initialized. As described above, initialization manager <NUM> of TPM logic <NUM> may be configured to initialize TPM <NUM> when TPM logic <NUM> is newly instantiated or when TPM <NUM> is restarted (e.g., after SOC <NUM> has been powered on). During initialization, initialization manager <NUM> may be configured to update and/or clear information stored in on-die RAM <NUM>.

In step <NUM>, in response to the blown-fuse count being greater than the TPM state fuse count, the TPM state PIN-attempt-failure count may be incremented. For example, as part of the initialization process, initialization manager <NUM> may be configured to increment TPM state PIN-attempt-failure count <NUM> in response to determining that the value of blown-fuse count <NUM> is greater than the value of TPM state fuse count <NUM>. In one example, TPM state PIN-attempt-failure count <NUM> may be incremented based on the difference between blown-fuse count <NUM> and TPM state fuse count <NUM>. By detecting the difference and incrementing TPM state PIN-attempt-failure count <NUM>, a state replay attack may be discovered and a penalty imposed. For example, if an attacker rewrites an out of date NV state <NUM> into off-die NV memory <NUM> (e.g., thereby lowering NV state fuse count <NUM> and/or NV state PIN-attempt-failure count <NUM>), and TPM logic <NUM> reads the rewritten NV state <NUM> into TPM state <NUM>, at this point, TPM state fuse count <NUM> may be lower than blown-fuse count <NUM>. The attacker may do this state rewriting procedure in an attempt to lower the TPM state PIN-attempt-failure count <NUM>, and thus be able to attempt more PIN entries than allowed for by PIN-attempt-failure count policy <NUM>. The penalty for lowering TPM state fuse count <NUM> relative to TPM state blown-fuse count <NUM> may be imposed by incrementing TPM state PIN-attempt-failure count <NUM>, which may affect whether a PIN entry attempt is allowed to be considered for access according to PIN-attempt-failure count policy <NUM>. Additional steps of initialization are described with respect to <FIG>.

Whereas steps <NUM> and <NUM> may be part of the initialization process, steps <NUM> through <NUM> may be part of a PIN verification process, which may be repeated for each PIN entry.

In step <NUM>, a PIN may be received in a first PIN attempt for accessing a system protected by the TPM. For example, a user may enter a PIN for verification by TPM logic <NUM>, in order to access a system that is PIN protected by TPM <NUM> (e.g., CPU <NUM>, a computer device, a phone, an application, etc.). As described above, TPM logic <NUM> may be configured to authenticate multiple PINs and may receive different valid PIN values in different PIN entry attempts.

In step <NUM>, it may be determined whether the TPM state PIN-attempt-failure count satisfies a PIN-attempt-failure count policy. For example, TPM logic <NUM> may be configured to determine that TPM state PIN-attempt-failure count <NUM> satisfies PIN-attempt-failure count policy <NUM>. If the policy is satisfied, TPM logic <NUM> may be configured to continue the PIN verification process for the received PIN. However, if the policy is not satisfied, a penalty may be enforced. For example, TPM logic <NUM> may be configured to compare a current value stored in TPM state PIN-attempt-failure count <NUM> to a PIN attempt threshold configured with respect to PIN-attempt-failure count policy <NUM>. In instances where TPM state PIN-attempt-failure count <NUM> has a specified relationship to the PIN attempt threshold (e.g., TPM state PIN-attempt-failure count <NUM> exceeds the PIN attempt threshold) TPM logic <NUM> may be configured to deny access to the system protected by TPM <NUM>, and enforce a rule regarding whether another PIN entry attempt will be processed. For example, PIN-attempt-failure count policy <NUM> may indicate that if a specified number of PIN entry attempts have failed, no more PIN attempts will be accepted, or a user must wait a specified amount of time to try another PIN attempt.

In step <NUM>, in instances when the received PIN is correct, TPM logic <NUM> may proceed to step <NUM>.

In step <NUM>, the TPM state PIN-attempt-failure count may be cleared. For example, if the received PIN is correct, TPM logic <NUM> may be configured to clear TPM state PIN-attempt-failure count <NUM> (e.g., to zero) for the received PIN value. This may affect the result when the PIN-attempt-failure count policy is applied to the next received PIN. As noted above, in some embodiments, TPM state PIN-attempt-failure count <NUM> may comprise a plurality of counts in an array (e.g., PIN-attempt-failure count [X]) where each count in the array corresponds to a different PIN of a plurality of PINs that may be verified by TPM logic <NUM>. Subsequent to step <NUM>, TPM logic <NUM> may proceed to step <NUM>.

In step <NUM>, in instances when the received PIN is incorrect, TPM logic <NUM> may proceed to step <NUM>.

In step <NUM>, a fuse may be blown. For example, dependent fuse blow manager <NUM> of TPM logic <NUM> may be configured to blow a fuse of the plurality of programmable fuses <NUM> in response to the PIN being deemed incorrect. In some embodiments, dependent fuse blow manager <NUM> may control fuse voltage <NUM> to blow the fuse. However, the disclosure is not limited with regard to how a counter comprising the programmable fuses <NUM> is incremented.

In step <NUM>, the blown-fuse count in the on-die RAM may be incremented. For example, in response to blowing the fuse in programmable fuses <NUM>, dependent fuse blow manager <NUM> may be configured to increment blown-fuse count <NUM> stored in on-die RAM <NUM>.

In step <NUM>, in instances where the fuse blow was unsuccessful, TPM logic <NUM> may proceed to step <NUM>.

In step <NUM>, activity of TPM <NUM> may be halted. For example, TPM logic <NUM> may be configured to halt TPM <NUM> activity and may place TPM <NUM> in a failure state, in response to a fuse failing to blow after dependent fuse blow manage <NUM> attempted to blow it. In some embodiments, TPM logic <NUM> may shut down PIN verification in response to the fuse blow failure. In this regard, the failure of the fuse to blow may indicate that a fuse voltage cut attack occurred after dependent fuse blow manager <NUM> (or TPM logic in general) made an attempt to blow it. For example, an attacker may monitor power provided to TPM <NUM> (e.g., fuse voltage <NUM>) to detect when the power increases to a level that indicates a fuse blow is underway. The attacker may then cut or diminish fuse voltage <NUM>, thereby denying voltage needed to blow the fuse. The attacker's goal may be to prevent TPM logic <NUM> from recording occurrences of failed PIN tries or incorrect PIN entries. The attacker's motive may be to gain additional PIN tries (e.g., unlimited PIN tries) in order to discover (e.g., steal) one or more authorized PINs. To counter such attacks, TPM logic <NUM> has the ability to blow fuses and execute code. However, although the attacker may not have access to the internal components of TPM <NUM> or SOC <NUM>, they may be able to gain access to external components such as off-die NV memory, fuse voltage <NUM>, SOC voltage <NUM>, or always-on power rail <NUM> (described with respect to <FIG>) in order to breach the PIN protection methods of the TPM <NUM>.

In step <NUM>, in instances when the fuse blow was successful, TPM logic <NUM> may proceed to step <NUM>.

In step <NUM>, the TPM state PIN-attempt-failure count may be incremented. For example, dependent fuse blow manager <NUM> may be configured to increment TPM state PIN-attempt-failure count <NUM> in response to blown-fuse count <NUM> being incremented. Subsequent to step <NUM>, TPM logic <NUM> may proceed to step <NUM>.

In step <NUM>, the TPM state fuse count may be set equal to the blown fuse count in the on-die RAM. For example, TPM logic <NUM> may be configured to write the value of blown-fuse count <NUM> into TPM state fuse count <NUM>.

In step <NUM>, the TPM state may be saved to an off-die non-volatile (NV) memory to update a NV state stored in the off-die NV memory. For example, TPM logic <NUM> may be configured to store TPM state <NUM>, comprising the values of TPM state PIN-attempt-failure count <NUM>, TPM state fuse count <NUM>, and TPM state PIN-key table <NUM>, to NV state <NUM> in off-die NV memory <NUM>, as NV state PIN-attempt-fail count <NUM>, NV state fuse count <NUM>, and NV state PIN-key table <NUM>, respectively.

Initialization manager <NUM> may operate in various ways to perform its functions. For instance, <FIG> is a flowchart <NUM> of a method for initializing the TPM, according to an example embodiment. Flowchart <NUM> may be performed as part of flowchart <NUM> (<FIG>), such as prior to step <NUM>. In an embodiment, initialization manager <NUM> may operate according to flowchart <NUM>. Flowchart <NUM> is described as follows with reference to <FIG> and <FIG>.

Flowchart <NUM> includes step <NUM>. In step <NUM>, the NV state may be read from the off-die NV memory to initialize the TPM. For Example, initialization manager <NUM> may be configured to retrieve NV state fuse count <NUM>, NV state PIN-attempt-failure count <NUM>, and NV state PIN-key table <NUM> of NV state <NUM> from off-die memory <NUM> for an initialization process.

In step <NUM>, the TPM state PIN-attempt-failure count and the TPM state fuse count may be updated based on the NV state. For example, initialization manager <NUM> may be configured to write values of NV state fuse count <NUM>, NV state PIN-attempt-failure count <NUM>, and NV state PIN-key table <NUM> to TPM state fuse count <NUM>, TPM state PIN-attempt-failure count <NUM>, and TPM state PIN-key table <NUM>, respectively. As described above with respect to <FIG>, steps <NUM> and <NUM> of flowchart <NUM> may also be performed as part of the initialization process.

Initialization manager <NUM> may operate in various ways to perform its functions. For instance, <FIG> is a flowchart <NUM> of a method for initializing the TPM in instances where the TPM is unable to read the state variables from external non-volatile memory, according to an example embodiment. Flowchart <NUM> may be performed as part of flowchart <NUM> (<FIG>), such as prior to step <NUM>. In an embodiment, initialization manager <NUM> may operate according to flowchart <NUM>. Flowchart <NUM> is described as follows with reference to <FIG> and <FIG>.

Flowchart <NUM> may be performed as part of flowchart <NUM> (<FIG>), such as during or after step <NUM>. In an embodiment, pull mode manager <NUM> and/or transmission manager <NUM> may operate according to flowchart <NUM>. Flowchart <NUM> is described as follows with reference to <FIG> and <FIG>.

Flowchart <NUM> includes step <NUM>. In step <NUM>, the NV state may be read from the off-die NV memory to initialize the TPM. For example, initialization manager <NUM> may be configured to retrieve NV state fuse count <NUM>, NV state PIN-attempt-failure count <NUM>, and NV state PIN-key table <NUM> of NV state <NUM> from off-die memory <NUM> for an initialization process.

In step <NUM>, in response to a failure in reading NV state from off-die NV memory, TPM logic <NUM> may proceed to step <NUM>.

In step <NUM>, the TPM state may be reset to a cleared initial state. For example, initialization manager <NUM> may be configured to clear TPM state <NUM> where the values held in TPM state fuse count <NUM>, TPM state PIN-attempt-failure count <NUM>, and TPM state PIN-key table <NUM> are cleared to zero or to a nulled state.

In step <NUM>, the TPM state fuse count may be set equal to the blown fuse count. For example, initialization manager <NUM> may be configured to set the value of TPM state fuse count <NUM> to the value of blown-fuse count <NUM>.

As described above with respect to <FIG>, steps <NUM> and <NUM> of flowchart <NUM> may also be performed as part of the initialization process.

As described above, TPM logic <NUM> of <FIG> may include independent fuse blow manager <NUM> in embodiments providing fuse based reply protection with aggressive fuse usage and countermeasures for fuse voltage cut attacks.

TPM <NUM> may operate in various ways to perform its functions. For instance, <FIG> is a flowchart <NUM> of a method for implementing fuse based replay protection with aggressive fuse usage, according to an example embodiment. In an embodiment, TPM logic <NUM> may operate according to flowchart <NUM>. The initialization process described above with respect to the fuse based replay protection with conservative fuse usage embodiment (e.g., in steps <NUM> and <NUM> of flowchart <NUM>, and in flow charts <NUM> and <NUM>) may be similar or substantially the same as the initialization process for this method of implementing fuse based replay protection with aggressive fuse usage. Flowchart <NUM> is described as follows with reference to <FIG> and <FIG>.

Flowchart <NUM> begins with step <NUM>. In step <NUM> , the TPM may be initialized. For example, as described above, initialization manager <NUM> of TPM logic <NUM> may be configured to initialize TPM <NUM> when TPM logic <NUM> is newly instantiated or when TPM <NUM> is restarted (e.g., after SOC <NUM> has been powered on). During initialization, initialization manager <NUM> may be configured to update and/or clear information stored in on-die RAM <NUM>.

In step <NUM>, in response to the blown-fuse count being greater than the TPM state fuse count, the TPM state PIN-attempt-failure count may be incremented. For example, as part of the initialization process, initialization manager <NUM> may be configured to increment TPM state PIN-attempt-failure count <NUM> in response to determining that the value of blown-fuse count <NUM> is greater than the value of TPM state fuse count <NUM>. In one example, TPM state PIN-attempt-failure count <NUM> may be incremented based on the value of a difference between blown-fuse count <NUM> and TPM state fuse count <NUM>. As described in more detail above, with respect to step <NUM> of flowchart <NUM>, by detecting the difference and incrementing TPM state PIN-attempt-failure count <NUM>, a state replay attack may be discovered and a penalty imposed. Additional steps of initialization are described with respect to <FIG>.

In step <NUM>, a PIN is received in a first PIN attempt for accessing a system protected by the TPM. For example, a user may enter a PIN for verification by TPM logic <NUM> in order to access a system that is PIN protected by TPM <NUM>. As described above, TPM logic <NUM> may be configured to process multiple PINs and may receive different valid PIN values in different PIN entry attempts.

In step <NUM>, it may be determined whether the TPM state PIN-attempt-failure count satisfies a PIN-attempt-failure count policy. For example, as described in more detail above, with respect to step <NUM> of flowchart <NUM>, TPM logic <NUM> may determine whether TPM state PIN-attempt-failure count <NUM> satisfies PIN-attempt-failure count policy <NUM>. If the policy is satisfied, the TPM logic <NUM> may continue the PIN verification process for the received PIN. However, if the policy is not satisfied a penalty may be enforced.

In step <NUM>, a fuse is blown. For example, independent fuse blow manager <NUM> may blow a fuse of plurality of programmable fuses <NUM> for each received PIN, regardless of whether the received PIN is verified to be correct or deemed incorrect. In this manner, the fuses may be utilized in a less efficient way than in the first embodiment for Fused Based Replay Protection with Conservative Fuse Usage (as described above with respect to <FIG>). However, blowing a fuse for each PIN attempt may prevent fuse voltage cut attacks where an attacker determines whether they have entered a correct PIN versus an incorrect PIN based on whether extra voltage is drawn for blowing a fuse, and may cut the voltage before the fuse is blown. For example, if a fuse is blown only when a PIN is incorrect, as described above with respect to steps <NUM>-<NUM> of flowchart <NUM>, an attacker may monitor the input voltage that feeds the plurality of programmable fuses <NUM>, and when the voltage begins to increase the user may reason that the entered PIN was incorrect (PIN entries that do not elicit an increase voltage level may be considered to be correct by the attacker). Also, the attacker may cut or diminish fuse voltage <NUM> before the input voltage reaches a high enough level to blow the fuse, thereby stopping the fuse blow even when the received PIN was incorrect. When the extra voltage is drawn, the attacker may restart the system before the fuse is blown, and begin the PIN entry process all over again. However, since blown-fuse count <NUM> may not have been incremented due to the fuse voltage cut attack, step <NUM> of flowchart <NUM> may not increment TPM state PIN-attempt-failure count <NUM>, and the cut voltage attack may go undetected. Thus, the attacker may continue this fuse voltage cut process repeatedly until one or more correct PINs are discovered. By blowing a fuse for each received PIN in the aggressive fuse blow embodiment, the attacker is denied the knowledge of whether an entered PIN was correct or incorrect, and the fuse voltage cut attacks are rendered useless.

In step <NUM>, the blown-fuse count stored in the on-die RAM is incremented. For example, independent fuse blow manager <NUM> may be configured to increment the value stored in blown-fuse count <NUM> in response to blowing a fuse of the plurality of programmable fuses <NUM>.

In step <NUM>, in instances where the fuse blow was unsuccessful, independent fuse blow manager <NUM> may proceed to step <NUM>.

In step <NUM>, TPM activity may be halted. For example, independent fuse blow manager <NUM> may be configured to halt TPM <NUM> activity and place TPM <NUM> in a failure state, in response to a fuse failing to blow after independent fuse blow manager <NUM> attempted to blow it. In some embodiments, independent fuse blow manager <NUM> may be configured to shut down PIN verification in response to the fuse blow failure. As described above, an unsuccessful fuse blow may indicate occurrence of a fuse voltage cut attack.

In step <NUM>, in instances where the fuse blow was successful, independent fuse blow manager <NUM> may proceed to step <NUM>.

In step <NUM>, in instances where the received PIN was correct, independent fuse blow manager <NUM> may proceed to step <NUM>.

In step <NUM>, independent fuse blow manager <NUM> may be configured to clear TPM state PIN-attempt-failure count <NUM>. For example, TPM state PIN-attempt-failure count <NUM> may be set to zero.

In step <NUM>, in instances where the received PIN was incorrect, independent fuse blow manager <NUM> may proceed to step <NUM>.

In step <NUM>, independent fuse blow manager <NUM> may be configured to increment TPM state PIN-attempt-failure count <NUM>. In some embodiments, independent fuse blow manager <NUM> may be configured to determine the difference between the blown-fuse count <NUM> and TPM state fuse count <NUM>, and increment TPM state PIN-attempt-failure count <NUM> based on the difference.

From steps <NUM> and <NUM>, independent fuse blow manager <NUM> may proceed to step <NUM>.

In step <NUM>, TPM state fuse count may be set equal to the blown-fuse count in the on-die RAM. For example, independent fuse blow manager <NUM> may be configured to write the value of blown-fuse count <NUM> to TPM state fuse count <NUM>.

In step <NUM>, the TPM state may be saved to an off-die NV memory to update a NV state stored in the off-die NV memory. For example, independent fuse blow manager <NUM> may be configured to save one or more values of TPM state <NUM> to NV state <NUM> of off-die NV memory <NUM>. In this regard, TPM state fuse count <NUM>, TPM state PIN-attempt-failure count <NUM>, and/or TPM state PIN-key table <NUM> may be saved to off-die NV memory <NUM> as NV state fuse count <NUM>, NV state PIN-attempt-failure count <NUM>, and NV state PIN-key table <NUM>.

As described above, TPM logic <NUM> may be configured to handle a plurality of PINs, and TPM state PIN-attempt-failure count <NUM> may comprise an array comprising PIN-attempt-failure counts for the plurality of PINs.

In general, this embodiment of fuse based replay protection with dynamic fuse usage and countermeasures for fuse voltage cut attacks is able to keep track of whether a PIN has been successfully entered before (e.g., during a current session), and if it has been, the more conservative fuse usage method is used, which only blows a fuse when a received PIN is incorrect. However, in the case where a received PIN has not been successfully entered before, the more secure method is applied, which includes blowing a fuse for each PIN attempt. This method leverages an always-on state to conserve fuse usage while also keeping the TPM secure against replay attacks.

As described above, fuse based replay protection may be implemented in various ways. For instance, <FIG> is a block diagram of a system <NUM> comprising a TPM implemented on a SOC for implementing fuse based replay protection with dynamic fuse usage, according to an example embodiment. As shown in <FIG>, system <NUM> comprises TPM <NUM>, off-die NV memory <NUM>, fuse voltage <NUM>, and an always-on (AO) power rail <NUM>. TPM <NUM> comprises plurality of programmable fuses <NUM>, TPM logic <NUM>, an always-on (AO) RAM <NUM>, and an on-die RAM <NUM>. On-die RAM <NUM> comprises blown-fuse count <NUM>, TPM state <NUM>, and temporary external-save count <NUM>. TPM state <NUM> comprises TPM state fuse count <NUM>, TPM state PIN-attempt-failure count <NUM>, a TPM state external-save count <NUM>, a TPM state previously-passed-PIN indicator <NUM>, and TPM state PIN-key table <NUM>. AO RAM <NUM> comprises an AO state external-save count <NUM>. Off-die NV memory <NUM> comprises NV state <NUM>. NV state <NUM> comprises NV state fuse count <NUM>, NV state PIN-attempt-failure count <NUM>, a NV state external-save count <NUM>, a NV state previously-passed-PIN indicator <NUM>, and a NV state PIN-key table <NUM>. In some embodiments, TPM state PIN-attempt-failure count <NUM>, NV state PIN-attempt-failure count <NUM>, TPM state previously-passed-PIN indicator <NUM>, and NV state previously-passed-PIN indicator <NUM> may each comprise an array of counts or indicators, each count or indicator corresponding to a particular PIN handled by TPM logic <NUM>.

Moreover, <FIG> is a block diagram of a system <NUM> comprising the TPM logic of <FIG>, according to an example embodiment. As shown in <FIG> system <NUM> comprises TPM logic <NUM>. TPM logic <NUM> comprises PIN-attempt-failure count policy <NUM>, initialization manager <NUM>, dependent fuse blow manager <NUM>, independent fuse blow manager <NUM>, and countermeasure manager <NUM>.

As shown in system <NUM>, SOC <NUM> may comprise TPM <NUM> and CPU <NUM>, and may be communicatively coupled to off-die NV memory <NUM>. In systems <NUM> and <NUM>, TPM <NUM> and off-die NV memory <NUM> may be configured to implement the third embodiment described herein that provides dynamic fuse usage and countermeasures for fuse voltage cut attacks. Systems <NUM> and <NUM> are described in more detail as follows.

AO RAM <NUM> may store AO state external-save count <NUM>. AO state external-save count <NUM> may be utilized to record a counter (e.g., an always-on monotonic counter) for detecting state replay attacks. AO state external-save count <NUM> may be cleared (e.g., revert to zero) when power is lost to AO RAM <NUM>.

AO RAM <NUM> may comprise a portion of on-die RAM of TPM <NUM>, which receives power from always-on power rail <NUM> that may provide voltage or stand-by voltage. AO RAM <NUM> may comprise any suitable AO memory such as AO static RAM (SRAM) or AO dynamic RAM (DRAM). In some embodiments, AO power rail <NUM> may be configured to provide stand-by voltage to AO RAM <NUM> even while SOC <NUM> and/or a device hosting SOC <NUM> (e.g., a phone, computer, etc.) are "switched off" (according to an electronic interface), but may be plugged into an AC power source or may have batteries (e.g., coin battery, laptop battery, etc.) connected to AO power rail <NUM>. Thus, AO RAM <NUM> may retain its state even when the hosting system and/or SOC <NUM> are in a sleep or standby mode, and may retain state when most of the system is off. Loss of power to AO power rail <NUM> may be a rare event but the longer power can be preserved, the fewer fuses needed to be blown to perform the embodiment described herein.

AO RAM <NUM> may be accessible only by TPM logic <NUM>. TPM logic <NUM> may be configured such that any data written to this area of RAM cannot be maliciously modified by an attacker, nor can it be replayed. However, the attacker may be able to withdraw power to the always-on power rail <NUM>, and thus cause always-on RAM <NUM> to lose its state. When this happens, AO state external-save count <NUM> may be cleared (e.g., revert to zero).

AO state external-save count <NUM> may comprise a variable (e.g., a four byte value) stored in on-die AO RAM <NUM> and may be utilized as a counter (e.g., a monotonic counter). AO state external-save count <NUM> may be incremented each time TPM state <NUM> values are saved to NV state <NUM> in off-die NV memory <NUM>. By keeping this count in an always-on memory, replay attacks may be detected and penalized during TPM <NUM> initialization (e.g., when AO state external-save count <NUM> is greater than TPM state external-save count, described below in steps <NUM>-<NUM> with respect to <FIG>). This count may also be used during TPM <NUM> initialization to detect and apply a penalty for a fuse voltage cut attack. For example, AO state external-save count <NUM> may be cleared before the PIN verification process in order to set a trap for detecting a fuse voltage cut attack during a following TPM <NUM> initialization process (e.g., steps <NUM>-<NUM> described below with respect to <FIG>).

Temporary external-save count <NUM> may comprise a variable stored in on-die RAM <NUM> and used to temporarily hold AO state external-save count <NUM> before AO state external-save count <NUM> is cleared to set the trap for detecting a fuse voltage cut attack. Temporary external-save count <NUM> may be incremented each time TPM state <NUM> values are saved to NV state <NUM> in off-die NV memory <NUM> and may be saved to AO state external-save count <NUM>.

TPM state external-save count <NUM> may comprise a variable of TPM state <NUM> stored in on-die RAM <NUM> and may be used as a counter (e.g., a monotonic counter). The value of TPM state external-save count <NUM> may be utilized to detect a replay attack during the TPM initialization process (e.g., when TPM state external-save count <NUM> is less than AO state external-save count <NUM>, described below with respect to steps <NUM>-<NUM> of <FIG>).

TPM state previously-passed-PIN indicator <NUM> may comprise a variable of TPM state <NUM> stored in on-die RAM <NUM>, such as a Boolean flag or an array of such flags (e.g., each flag corresponding to a PIN handled by TPM logic <NUM>). TPM state previously-passed-PIN indicator <NUM> may be used indicate whether a specific PIN has already been successfully used (e.g., verified to be correct) during a current always-on session (e.g., since SOC <NUM> or a device hosting SOC <NUM> has lost power or been rebooted). In instances when TPM state previously-passed-PIN indicator <NUM> is set to "true," TPM logic may utilize the conservative fuse blow method and when it is set to "false" the aggressive fuse blow method may be utilized for PIN verification.

NV state external-save count <NUM> may comprise a variable of NV state <NUM> stored in off-die NV memory <NUM>, which may be available to TPM logic <NUM> for storing TPM <NUM> state information. As described above with respect to TPM logic <NUM>, TPM logic <NUM> may be configured to encrypt and integrity protect TPM state <NUM> information, and store it to off-die NV memory <NUM> to prevent the disclosure or modification of the state information. Although the state information may be encrypted, an attacker may be able to replay previously signed state information in TPM <NUM>, by copying state information from off-die memory <NUM>, and after newer state information is written to off-die memory, the attacker may re-write the earlier state over the newer state in off-die NV memory <NUM>, such that the next time TPM <NUM> initializes, TPM logic <NUM> may read the rewritten earlier state information from off-die memory <NUM> into TPM state <NUM>. In this manner, the attacker may be able to lower a count of blown fuses indicated in the state information (e.g., TPM state fuse count <NUM>).

NV state previously-passed-PIN indicator <NUM> may comprise a variable of NV state <NUM> stored in off-die NV memory <NUM>, which may be available to TPM logic <NUM> for storing TPM state previously-passed-PIN indicator <NUM>.

PIN-attempt-failure count policy <NUM> (<FIG>) may be similar or substantially the same as PIN-attempt-failure count policy <NUM>. In one embodiment, PIN-attempt-failure count policy <NUM> may comprise a PIN attempt threshold and/or a rule for determining whether PIN authentication is allowed to proceed for a received PIN entry based on how many PIN entry attempts have already been tried. For example, TPM logic <NUM> may determine whether TPM state PIN-attempt-failure count <NUM> for a particular received PIN satisfies PIN-attempt-failure count policy <NUM>. The penalty for entering too many incorrect PINs may vary depending on the rule. For example, TPM logic <NUM> may deny access to the system protected by TPM <NUM>, and enforce a rule indicating no more PIN attempts will be accepted or processed, or a user must wait a specified amount of time to try another PIN attempt.

TPM logic <NUM> may operate in various ways to perform its functions. For instance, <FIG> is a flowchart <NUM> of a method for implementing fuse based replay protection with dynamic fuse usage, according to an example embodiment. In an embodiment, TPM logic <NUM> may operate according to flowchart <NUM>. Flowchart <NUM> is described as follows with reference to <FIG> and <FIG>.

Flowchart <NUM> begins with step <NUM>. In step <NUM>, the TPM may be initialized. For example, as described above, initialization manager <NUM> of TPM logic <NUM> may be configured to initialize TPM <NUM> when TPM logic <NUM> is newly instantiated or when TPM <NUM> is restarted (e.g., after SOC <NUM> has been powered on). During initialization, initialization manager <NUM> may be configured to update and/or clear information stored in on-die RAM <NUM>.

In step <NUM>, in response to the blown-fuse count being greater than the TPM state fuse count, the TPM state PIN-attempt-failure count may be incremented. For example, as described above with respect to step <NUM> of flowchart <NUM>, as part of the initialization process, countermeasure manager <NUM> may be configured to increment TPM state PIN-attempt-failure count <NUM> in response to determining that the value of blown-fuse count <NUM> is greater than the value of TPM state fuse count <NUM>. For example, TPM state PIN-attempt-failure count <NUM> may be incremented based on the difference between blown-fuse count <NUM> and TPM state fuse count <NUM>. If blown-fuse count <NUM> is greater than TPM state fuse count <NUM>, this may indicate that a state replay attack has occurred. Countermeasure manager <NUM> may be configured to impose a penalty for the attack by incrementing TPM state PIN-attempt-failure count <NUM> so that the impact of the attack may be rendered useless the next time the PIN-attempt-failure count policy <NUM> is applied. This portion of the initialization process may be similar or substantially the same as described in the previous two embodiments (e.g., the conservative fuse usage method and aggressive fuse usage method).

Whereas steps <NUM> and <NUM> of <FIG> may be part of the initialization process, steps <NUM> through <NUM> may be part of a PIN verification process, which may be repeated for each PIN entry. Additional steps of the initialization process are described with respect to flowchart <NUM> (<FIG>) and flowcharts <NUM> and <NUM> (<FIG>) as performed by initialization manager <NUM>, described below).

In step <NUM>, a PIN may be received in a PIN attempt for accessing a system protected by the TPM. For example, a user may enter a PIN in order to access a system that is PIN protected by TPM <NUM> (e.g., CPU <NUM>, a computer device, a phone, an application, etc.). As described above, TPM logic <NUM> may be configured to authenticate multiple PINs and may handle different PIN values in different PIN entry attempts.

In step <NUM>, in instances where the received PIN satisfies PIN-attempt-failure count policy <NUM>, TPM logic <NUM> may proceed to step <NUM>.

In step <NUM>, in instances where the value of the received PIN was previously received and verified to be correct during the current session (e.g., since SOC <NUM> or a device hosting SOC <NUM> has lost power or been rebooted), TPM logic <NUM> may be configured to proceed to step <NUM>. For example, TPM logic <NUM> may proceed to step <NUM> if it determines that TPM state previously-passed-PIN indicator <NUM> is set to true.

In step <NUM>, dependent fuse blow manager <NUM> may be configured to determine whether the received PIN is correct. In this regard, if TPM state previously-passed-PIN indicator <NUM> is set to true, dependent fuse blow manager <NUM> may be configured to blow a fuse or not blow a fuse depending on whether the received PIN is incorrect or correct respectively. In instances when the received PIN is not correct, dependent fuse blow manager <NUM> may proceed to step <NUM>.

In step <NUM>, a fuse may be blown and blown-fuse count <NUM> may be incremented. For example, if the received PIN is incorrect, dependent fuse blow manager <NUM> may be configured to blow a fuse of the plurality of fuses <NUM> (e.g., control fuse voltage <NUM> to blow the fuse) and increment blown fuse count <NUM> in on-die RAM <NUM>.

In step <NUM>, in instances where the received PIN is correct, dependent fuse blow manager <NUM> may not blow a fuse as shown in step <NUM>.

As can be seen in steps <NUM>-<NUM>, if TPM state previously-passed-PIN indicator <NUM> is set to true, dependent fuse blow manager <NUM> is configured to blow a fuse dependent on whether a received PIN is incorrect, and may not blow a fuse when the received PIN is correct (e.g., using the conservative fuse usage method).

In step <NUM>, in instances where the value of the received PIN has not been previously received and verified as correct during the current session, TPM logic <NUM> may be configured to proceed to step <NUM>. For example, TPM logic <NUM> may proceed to step <NUM> if TPM state previously-passed-PIN indicator <NUM> is set to false.

In step <NUM>, a fuse may be blown and the blown fuse count may be incremented. For example, independent fuse blow manager <NUM> may be configured to blow a fuse of plurality of programmable fuses <NUM> and increment blown-fuse count <NUM>.

As can be seen in steps <NUM>-<NUM>, if TPM state previously-passed-PIN indicator <NUM> is set to false, independent fuse blow manager <NUM> is configured to blow a fuse independent of whether a received PIN is correct or incorrect (e.g., using the aggressive fuse usage method).

Subsequent to performing steps <NUM>, <NUM>, or <NUM>, TPM logic <NUM> may proceed to step <NUM>.

In step <NUM>, the TPM state fuse count may be set based on the blown fuse count in the on-die RAM. For example, TPM logic <NUM> may be configured to set TPM state fuse count <NUM> based on (e.g., equal to) the value of blown-fuse count <NUM>.

Dependent fuse blow manager <NUM> may operate in various ways to perform its functions. For instance, <FIG> is a flowchart <NUM> of a method for dynamically implementing conservative fuse usage, according to an example embodiment. Flowchart <NUM> may be performed as part of flowchart <NUM> (<FIG>), such as after step <NUM> results in a "true" output, and before step <NUM>. In an embodiment, dependent fuse blow manager <NUM> of TPM logic <NUM> may operate according to flowchart <NUM>. Flowchart <NUM> is described as follows with reference to <FIG> and <FIG>.

Flowchart <NUM> begins with step <NUM>. In step <NUM>, in instances where dependent fuse blow manager <NUM> determines that the received PIN is correct, dependent fuse blow manager <NUM> may proceed to step <NUM>.

In step <NUM>, dependent fuse blow manager <NUM> may be configured to clear TPM state PIN-attempt-failure count <NUM>.

In step <NUM>, in instances where dependent fuse blow manager <NUM> determines that the received PIN is incorrect, dependent fuse blow manager <NUM> may proceed to step <NUM>.

In step <NUM>, dependent fuse blow manger <NUM> may be configured to blow a fuse of plurality of programmable fuses <NUM> in response to the PIN being incorrect.

In step <NUM>, dependent fuse blow manager <NUM> may increment blown-fuse count <NUM> in response to blowing the fuse of the plurality of programmable fuses.

In step <NUM>, in instances where the fuse blow is fails, dependent fuse blow manger <NUM> may be configured to proceed to step <NUM>.

In step <NUM>, dependent fuse blow manger <NUM> may be configured to halt activity of TPM <NUM>. For example, as described above, dependent fuse blow manager <NUM> may be configured to halt TPM <NUM> activity and may place TPM <NUM> in a failure state, in response to a fuse failing to blow. As described above, an unsuccessful fuse blow may indicate a fuse voltage cut attack has occurred.

In step <NUM>, in instances where the fuse blow is successful, dependent fuse blow manger <NUM> may be configured to proceed to step <NUM>.

In step <NUM>, dependent fuse blow manger <NUM> may be configured to increment TPM state PIN-attempt-failure count <NUM> in response to blowing the fuse for the incorrect PIN.

In step <NUM>, dependent fuse blow manger <NUM> may be configured to set TPM state previously-passed-PIN indicator <NUM> to false.

Independent fuse blow manager <NUM> may operate in various ways to perform its functions. For instance, <FIG> is a flowchart <NUM> of a method for dynamically implementing aggressive fuse usage, according to an example embodiment. Flowchart <NUM> may be performed as part of flowchart <NUM> (<FIG>), such as after step <NUM> results in a "false" output and before step <NUM>. In an embodiment, independent fuse blow manager <NUM> of TPM logic <NUM> may operate according to flowchart <NUM>. Flowchart <NUM> is described as follows with reference to <FIG> and <FIG>.

In step <NUM>, independent fuse blow manager <NUM> may be configured to blow a fuse of plurality of programmable fuses <NUM> independent of whether a received PIN may be deemed correct or incorrect. For example, independent fuse blow manager <NUM> may be configured to control fuse voltage <NUM> to blow the fuse. However, the disclosure is not limited with respect to how the fuse is blown.

In step <NUM>, independent fuse blow manager <NUM> may be configured to increment blown-fuse count <NUM> in response to blowing the fuse of the plurality of programmable fuses <NUM>.

In step <NUM>, in instances where the fuse blow fails, independent fuse blow manger <NUM> may be configured to proceed to step <NUM>.

In step <NUM>, independent fuse blow manger <NUM> may be configured to halt activity of TPM <NUM>. For example, independent fuse blow manger <NUM> may be configured to halt TPM <NUM> activity and may place TPM <NUM> in a failure state, in response to a fuse failing to blow. As described above, an unsuccessful fuse blow may indicate a fuse voltage cut attack has occurred.

In step <NUM>, in instances where the fuse blow is successful, independent fuse blow manger <NUM> may be configured to proceed to step <NUM>.

In step <NUM>, in instances where independent fuse blow manger <NUM> determines that the received PIN is correct, independent fuse blow manger <NUM> may proceed to step <NUM>.

In step <NUM>, independent fuse blow manger <NUM> may be configured to clear TPM state PIN-attempt-failure count <NUM> (e.g., to zero) in response to the received PIN being correct.

In step <NUM>, independent fuse blow manger <NUM> may be configured to set TPM state previously-passed-PIN indicator <NUM> to true for the received PIN in response to the received PIN being correct. In this manner, in the next cycle of receiving the same PIN, the conservative fuse usage method may be utilized rather than the aggressive fuse usage method.

TPM logic <NUM> may operate in various ways to perform its functions. For instance, <FIG> is a flowchart <NUM> of a method for setting a trap to catch a fuse voltage cut attack during a subsequent TPM logic initialization, according to an example embodiment. Flowchart <NUM> may be performed as part of flowchart <NUM> (<FIG>), such as after step <NUM>. In an embodiment, TPM logic <NUM> may operate according to flowchart <NUM>. Flowchart <NUM> is described as follows with reference to <FIG> and <FIG>.

Flow chart <NUM> begins with step <NUM>. In step <NUM>, TPM logic <NUM> may be configured to set temporary external-save count <NUM> based on the AO state external-save count <NUM>. For example, temporary external-save count <NUM> may be set equal to AO state external-save count <NUM>.

In step <NUM>, TPM logic <NUM> may be configured to clear AO state external-save count <NUM>. For example, AO state external-save count <NUM> may be set to zero.

TPM logic <NUM> may operate in various ways to perform its functions. For instance, <FIG> is a flowchart <NUM> of a method for saving TPM state variables to NV memory and updating external-save counts, according to an example embodiment. Flowchart <NUM> may be performed as part of flowchart <NUM> (<FIG>), such as after step <NUM>. In an embodiment, TPM logic <NUM> may operate according to flowchart <NUM>. Flowchart <NUM> is described as follows with reference to <FIG> and <FIG>.

Flow chart <NUM> begins with step <NUM>. In step <NUM>, TPM logic <NUM> may be configured to increment temporary external-save count <NUM>.

In step <NUM>, TPM logic <NUM> may be configured to set TPM state external-save count <NUM> based on temporary external-save count <NUM>. For example, TPM state external-save count <NUM> may be set equal to temporary external-save count <NUM>.

In step <NUM>, TPM logic <NUM> may be configured to save TPM state <NUM> to off-die NV memory <NUM> as NV state <NUM>. In some embodiments, if TPM state fuse count <NUM>, PIN-attempt-failure count <NUM>, or previously-passed-PIN indicator <NUM> have not been changed since the last save to NV state <NUM>, TPM logic may be configured to skip step <NUM>.

In step <NUM>, TPM logic <NUM> may be configured to set AO state external-save count <NUM> based on temporary external-save count <NUM>.

The initialization process for TPM logic <NUM> may begin with the steps described with respect to steps <NUM>-<NUM> of flowchart <NUM> if an NV state <NUM> read is successful. In this regard, initialization manager <NUM> may be configured to perform the steps of flowchart <NUM> and may read NV state <NUM> comprising NV state fuse count <NUM>, NV state PIN-attempt-failure count <NUM>, NV state external-save count <NUM>, NV state previously-passed-PIN indicator <NUM>, and NV state PIN-key table <NUM> from off-die NV memory <NUM>, and update TPM state <NUM> with the NV state <NUM> values.

Moreover, the initialization process for TPM logic <NUM> may begin with the steps described with respect to steps <NUM>-<NUM> of flowchart <NUM> if the NV state <NUM> read fails. In this regard, initialization manager <NUM> may be configured to perform the steps of flowchart <NUM> including reading NV state <NUM> from off-die NV memory <NUM>. If the NV state <NUM> read fails, initialization manager <NUM> may be configured to clear TPM state <NUM> (e.g., clear TPM state fuse count <NUM>, TPM state PIN-attempt-failure count <NUM>, TPM state external-save count <NUM>, TPM state previously-passed-PIN indicator <NUM>, and TPM state PIN-key table <NUM> to zero or to a nulled state), and set TPM state fuse count <NUM> based on blown fuse count <NUM>. These initialization steps may precede the steps described below with respect to <FIG>.

Countermeasure manager <NUM> may operate in various ways to perform its functions. For instance, <FIG> is a flowchart <NUM> of a method for initializing the TPM and enforcing penalties for state replay attacks and fuse voltage cut attacks, according to an example embodiment. Flowchart <NUM> may be performed as part of flowchart <NUM> (<FIG>), such as before step <NUM> of the initialization process, and after the initialization steps described above with respect to flowcharts <NUM> and <NUM> (as performed by initialization manager <NUM>). In an embodiment, TPM logic <NUM> may operate according to flowchart <NUM>. Flowchart <NUM> is described as follows with reference to <FIG> and <FIG>.

Flow chart <NUM> begins with step <NUM>. In step <NUM>, countermeasure manager <NUM> may be configured to determine whether AO external-save count <NUM> is set to zero. In instances where AO external-save count <NUM> is set to zero, countermeasure manager <NUM> may proceed to step <NUM> (this may indicate that a fuse voltage cut attack occurred).

In step <NUM>, countermeasure manager <NUM> may be configured to set TPM state previously-passed-PIN indicator <NUM> to false.

In step <NUM>, countermeasure manager <NUM> may be configured to set AO state external-save count <NUM> based on TPM state external-save count <NUM>. For example, AO state external-save count <NUM> may be set equal to TPM state external-save count <NUM>.

In step <NUM>, countermeasure manager <NUM> may be configured to determine whether the value of AO external-save count <NUM> is greater than the value of TPM state external-save count <NUM>. In instances where the value of AO external-save count <NUM> is greater than the value of TPM state external-save count <NUM>, countermeasure manager <NUM> may proceed to step <NUM> (this may indicate a state replay attack).

With reference to flowchart <NUM>, if an attacker perpetrates an attack for a PIN that has previously passed verification in a current session (e.g., previously verified to be correct), the attacker may get one free PIN attempt. The attacker may achieve this by cutting fuse voltage <NUM> to prevent TPM logic from blowing a fuse before step <NUM> in flowchart <NUM>. When the TPM system starts up again, since the fuse was not blown and blown-fuse count <NUM> was not incremented, step <NUM> is not executed (to increment TPM state PIN-attempt-failure count <NUM>). However, because in step <NUM>, AO state external save count <NUM> was cleared (which occurs before step <NUM> of <FIG>), steps <NUM>-<NUM> may be executed during initialization, upon restart of TPM <NUM> (e.g., where TPM state previously-passed-PIN indicator <NUM> is set to false). This will force subsequent PIN tries to go into the aggressive fuse usage method described with respect to flowchart <NUM>, where a fuse may be blown ahead of the determining whether a PIN is correct. At this point, the attacker may be forced to blow a fuse for each and every PIN attempt and eventually will get caught by the PIN-attempt-failure count policy <NUM>.

The following steps are performed upon TPM initialization:.

This method uses NVState. FuseCounter (e.g., TPM state fuse count <NUM>) to also store the counter value from the blown fuses. Step <NUM> covers the case where an attacker is replaying an old NVState (TPM state <NUM>) to lower the PINFailCount (TPM state PIN-attempt-failure count <NUM>). In a NVState replay scenario, the Fuse. Counter (e.g., blow-fuse count <NUM>) value will have advanced to a larger number than the replayed NVState. FuseCounter (e.g., TPM state fuse count <NUM>). Thus, the replay attacker is penalized by adding (Fuse. Counter - NVState. FuseCounter) (e.g., blown-fuse count <NUM> - TPM state fuse count <NUM>) to every NVState. PINFailCount (TPM state PIN-attempt-failure count <NUM>), thus making the attacker gain nothing by replaying NVState (TPM state <NUM>).

However, the attacker can monitor voltage draw for the fuse blow in step 5b and cut power to prevent the fuse blow from happening. The fact that the extra voltage draw happened, tells the attacker that the PIN was incorrect. The attacker can then restart the system before the fuse gets blown and start all over again. Since Fuse. Counter (e.g., blown-fuse count <NUM>) was never incremented, step <NUM> doesn't catch the attacker, and thus the attacker can keep repeating this process until the correct PIN is eventually discovered.

This algorithm is secure against attacks but utilizes a fuse blow every time a PIN is tried, even if the PIN is correct.

This method leverages the always on state to conserve fuse usage while also keeping the algorithm secure against replay attacks.

The scope of this method is to keep track of whether a PIN has been successfully verified before, and if it has, use the less secure algorithm that doesn't require a fuse blow for each PIN try. But in the case of a PIN that has not been successfully verified before, use the more secure algorithm that blows a fuse for each PIN attempt.

MonotonicCounter is also used to record a monotonic counter so that NVState (e.g., TPM state <NUM>) rollback can be detected. MonotonicCounter (e.g., AO state external-save count <NUM>) should revert back to <NUM> if always-on power is lost.

If an attacker tries to attack with a PIN that has previously passed, the attacker will get one free PIN try. The attacker can achieve this by pulling power to prevent fuse blow in step 9b. When the system starts up again, the Fuse. Counter (e.g., blown-fuse count <NUM>) was not incremented so step 5a does not get executed. However, because step <NUM> cleared the AOState. MonotonicCounter (e.g., AO state external-save count <NUM>) value before step <NUM>, step <NUM> will be executed upon restart. This will force subsequent PIN tries to go into step <NUM> where a fuse is blown ahead of the test. At this point, the attacker may be forced to blow a fuse for each and every PIN try, and will get caught in step <NUM> sooner or later.

Embodiments described herein may be implemented in hardware, or hardware combined with software and/or firmware. For example, embodiments described herein may be implemented as computer program code/instructions configured to be executed in one or more processors and stored in a computer readable storage medium. Alternatively, embodiments described herein may be implemented as hardware logic/electrical circuitry.

As noted herein, the embodiments described, including but not limited to, systems <NUM>, <NUM>, <NUM>, and <NUM> along with any components and/or subcomponents thereof, as well any operations and portions of flowcharts/flow diagrams described herein and/or further examples described herein, may be implemented in hardware, or hardware with any combination of software and/or firmware, including being implemented as computer program code configured to be executed in one or more processors and stored in a computer readable storage medium, or being implemented as hardware logic/electrical circuitry, such as being implemented together in a system-on-chip (SOC), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a trusted platform module (TPM), and/or the like. A SOC may include an integrated circuit chip that includes one or more of a processor (e.g., a microcontroller, microprocessor, digital signal processor (DSP), etc.), memory, one or more communication interfaces, and/or further circuits and/or embedded firmware to perform its functions.

Embodiments described herein may be implemented in one or more computing devices similar to a mobile system and/or a computing device in stationary or mobile computer embodiments, including one or more features of mobile systems and/or computing devices described herein, as well as alternative features. The descriptions of computing devices provided herein are provided for purposes of illustration, and are not intended to be limiting. Embodiments may be implemented in further types of computer systems, as would be known to persons skilled in the relevant art(s).

<FIG> is a block diagram of an example processor-based computer system <NUM> that may be used to implement various embodiments. Systems <NUM>, <NUM>, <NUM>, and <NUM> may each include any type of computing device, mobile or stationary, such as a desktop computer, a server, a video game console, etc. For example, systems <NUM>, <NUM>, <NUM>, and <NUM> may each comprise any type of mobile computing device (e.g., a Microsoft® Surface® device, a personal digital assistant (PDA), a laptop computer, a notebook computer, a tablet computer such as an Apple iPad™, a netbook, etc.), a mobile phone (e.g., a cell phone, a smart phone such as a Microsoft Windows® phone, an Apple iPhone, a phone implementing the Google® Android™ operating system, etc.), a wearable computing device (e.g., a head-mounted device including smart glasses such as Google® Glass™, Oculus Rift® by Oculus VR, LLC, etc.), a stationary computing device such as a desktop computer or PC (personal computer), a gaming console/system (e.g., Microsoft Xbox®, Sony PlayStation®, Nintendo Wii® or Switch®, etc.), etc..

Systems <NUM>, <NUM>, <NUM>, and <NUM>, may each be implemented in one or more computing devices containing features similar to those of computing device <NUM> in stationary or mobile computer embodiments and/or alternative features. The description of computing device <NUM> provided herein is provided for purposes of illustration, and is not intended to be limiting. Embodiments may be implemented in further types of computer systems, as would be known to persons skilled in the relevant art(s).

A number of program modules may be stored on the hard disk, magnetic disk, optical disk, ROM, or RAM. These programs include operating system <NUM>, one or more application programs <NUM>, other programs <NUM>, and program data <NUM>. Application programs <NUM> or other programs <NUM> may include, for example, computer program logic (e.g., computer program code or instructions) for implementing TPM logic <NUM> or <NUM>, initialization manager <NUM>, dependent fuse blow manager <NUM>, independent fuse blow manager <NUM>, TPM state <NUM>, programmable fuses <NUM>, NV state <NUM>, always-on RAM <NUM>, PM state <NUM>, NV state <NUM>, PIN-attempt-failure count policy <NUM>, initialization manager <NUM>, dependent fuse blow manager <NUM>, countermeasure manager <NUM>, and any one or more of flowcharts <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> (including any step thereof), and/or further embodiments described herein. Program data <NUM> may include, blown-fuse count <NUM>, TPM state <NUM>, TPM state fuse count <NUM>, PIN-attempt-failure count <NUM>, NV state <NUM>, NV state fuse count <NUM>, NV state PIN-attempt-failure count <NUM>, AO state external-save count <NUM>, temporary external-save count <NUM>, TPM state <NUM>, TPM state external-save count <NUM>, TPM state previously-passed-PIN indicator <NUM>, NV state external-save count <NUM>, NV state previously-passed-PIN indicator <NUM>, and/or further embodiments described herein.

A user may enter commands and information into computing device <NUM> through input devices such as keyboard <NUM> and pointing device <NUM>.

Accordingly, such computer programs represent controllers of computing device <NUM>.

In an embodiment, a system for thwarting personal identification number (PIN) retry attacks in a trusted platform module (TPM) comprises a system on a chip (SOC). The SOC comprises: a plurality of programmable fuses, one or more processors, and one or more memory devices. The one or more memory devices comprise an on-die random access memory (RAM) storing a TPM state comprising a TPM state PIN-attempt-failure count and a TPM state fuse count. The one or more memory devices store program code to be executed by the one or more processors. The program code comprises the TPM logic. The TPM logic is configured to initialize the TPM. The on-die RAM stores a blown-fuse count comprising a count of currently blown fuses of the plurality of programmable fuses. To initialize the TPM, the TPM logic is configured to at least: in response to the blown-fuse count being greater than the TPM state fuse count, increment the TPM state PIN-attempt-failure count and receive a PIN in a first PIN attempt for accessing a system protected by the TPM. Also, in response to the TPM state PIN-attempt-failure count satisfying a PIN-attempt-failure count policy: in response to the received PIN being correct, the TPM logic is configured to clear the TPM state PIN-attempt-failure count. In response to the received PIN being incorrect, the TPM logic is configured to blow a fuse and increment the blown-fuse count in the on-die RAM. In response to the fuse blow failing, the TPM logic is configured to halt TPM activity. In response to the fuse blow succeeding, the TPM is logic configured to increment the TPM state PIN-attempt-failure count and set the TPM state fuse count equal to the blown-fuse count in the on-die RAM. The TPM logic is further configured to save the TPM state to an off-die non-volatile (NV) memory to update a NV state stored in the off-die NV memory.

In an embodiment of the foregoing system, to increment the TPM state PIN-attempt-failure, the TPM logic is configured to increment the TPM state PIN-attempt-failure count based on a difference between the blown-fuse count and the TPM state fuse count.

In an embodiment of the foregoing system, to initialize the TPM, the TPM logic is further configured to read the NV state from the off-die NV memory, and update the TPM state PIN-attempt-failure count and the TPM state fuse count based on the NV state.

In an embodiment of the foregoing system, to initialize the TPM, the TPM logic is further configured to read the NV state from the off-die NV memory. In response to a failure in the reading the NV state from the off-die NV memory, the TPM logic is configured to reset the TPM state to a cleared initial state and set the TPM state fuse count equal to the blown-fuse count in the on-die RAM.

In an embodiment of the foregoing system, the TPM logic is further configured to receive a PIN in a second PIN attempt for accessing the system protected by the TPM during the same session as the first PIN attempt. In response to the TPM state PIN-attempt-failure count satisfying a PIN-attempt-failure count policy, the TPM logic is configured to: in response to the received PIN being correct, clear the TPM state PIN-attempt-failure count. In response to the received PIN being incorrect, the TPM logic is configured to blow a fuse and increment the blown-fuse count in the on-die RAM. In response to the fuse blow failing, the TPM logic is configured to halt TPM activity, increment the TPM state PIN-attempt-failure count, set the TPM state fuse count equal to the blown-fuse count in the on-die RAM, and save the TPM state to the off-die non-volatile (NV) memory.

In an embodiment of the foregoing system, the TPM state comprises a TPM state PIN-attempt-failure count for a plurality of different PIN values and the PIN received in the first PIN attempt and the PIN received in the second PIN attempt are different PIN values.

In an embodiment of the foregoing system, the SOC further comprises an on-die central processing unit (CPU).

In an embodiment, a method for thwarting personal identification number (PIN) state replay attacks in a trusted platform module (TPM) is implemented in a system on a chip (SOC). The SOC comprises a plurality of programmable fuses, an on-die random access memory (RAM) storing a TPM state comprising a TPM state PIN-attempt-failure count and a TPM state fuse count. The method comprises initializing the TPM, where the on-die RAM stores a blown-fuse count comprising a count of currently blown fuses of the plurality of programmable fuses. The initializing comprises at least: in response to the blown-fuse count being greater than the TPM state fuse count: incrementing the TPM state PIN-attempt-failure count. The method further comprises receiving a PIN in a first PIN attempt for accessing a system protected by the TPM. In response to the TPM state PIN-attempt-failure count satisfying a PIN-attempt-failure count policy, and in response to the received PIN being correct, the method comprises clearing the TPM state PIN-attempt-failure count. In response to the received PIN being incorrect the method comprises blowing a fuse and incrementing the blown-fuse count in the on-die RAM. In response to the fuse blow failing, the method comprises halting TPM activity. In response to the fuse blow succeeding, the method comprises incrementing the TPM state PIN-attempt-failure count and setting the TPM state fuse count equal to the blown-fuse count in the on-die RAM. The method further comprises saving the TPM state to an off-die non-volatile (NV) memory to update a NV state stored in the off-die NV memory.

In an embodiment of the foregoing method, the incrementing of the TPM state PIN-attempt-failure count comprises incrementing the TPM state PIN-attempt-failure count based on a difference between the blown-fuse count and the TPM state fuse count.

In an embodiment of the foregoing method, the initializing the TPM further comprises reading the NV state from the off-die NV memory and updating the TPM state PIN-attempt-failure count and the TPM state fuse count based on the NV state.

In an embodiment of the foregoing method, initializing the TPM further comprises reading the NV state from the off-die NV memory. In response to a failure in the reading the NV state from the off-die NV memory, the method comprises resetting the TPM state to a cleared initial state and setting the TPM state fuse count equal to the blown-fuse count in the on-die RAM.

In an embodiment of the foregoing method, the TPM state comprises a TPM state PIN-attempt-failure count for a plurality of different PIN values.

In an embodiment of the foregoing method, the method further comprises receiving a PIN in a second PIN attempt for accessing the system protected by the TPM during the same session as the first PIN attempt. In response to the TPM state PIN-attempt-failure count satisfying a PIN-attempt-failure count policy, the method comprises: in response to the received PIN being correct, clearing the TPM state PIN-attempt-failure count. In response to the received PIN being incorrect, the method comprises blowing a fuse and incrementing the blown-fuse count in the on-die RAM. In response to the fuse blow failing the method comprises: halting TPM activity, incrementing the TPM state PIN-attempt-failure count, setting the TPM state fuse count equal to the blown-fuse count in the on-die RAM, and saving the TPM state to the off-die non-volatile (NV) memory.

In an embodiment of the foregoing method, the PIN received in the first PIN attempt and the PIN received in the second PIN attempt are different PIN values.

In an embodiment, a computer readable medium having program code recorded thereon that when executed by at least one processor causes the at least one processor to perform a method for thwarting personal identification number (PIN) state replay attacks in a trusted platform module (TPM) implemented in a system on a chip (SOC). The SOC comprises a plurality of programmable fuses and an on-die random access memory (RAM) storing a TPM state. The TPM state comprises a TPM state PIN-attempt-failure count and a TPM state fuse count. The method comprises initializing the TPM, where the on-die RAM stores a blown-fuse count comprising a count of currently blown fuses of the plurality of programmable fuses. The initializing comprises at least: in response to the blown-fuse count being greater than the TPM state fuse count, incrementing the TPM state PIN-attempt-failure count. The method further comprises receiving a PIN in a first PIN attempt for accessing a system protected by the TPM. In response to the TPM state PIN-attempt-failure count satisfying a PIN-attempt-failure count policy the method comprises: in response to the received PIN being correct: clearing the TPM state PIN-attempt-failure count, and in response to the received PIN being incorrect: blowing a fuse and incrementing the blown-fuse count in the on-die RAM. In response to the fuse blow failing, the method comprises halting TPM activity. In response to the fuse blow succeeding, the method comprises incrementing the TPM state PIN-attempt-failure count and setting the TPM state fuse count equal to the blown-fuse count in the on-die RAM. The method comprises saving the TPM state to an off-die non-volatile (NV) memory to update a NV state stored in the off-die NV memory.

In an embodiment of the foregoing computer readable medium, the incrementing of the TPM state PIN-attempt-failure count comprises incrementing the TPM state PIN-attempt-failure count based on a difference between the blown-fuse count and the TPM state fuse count.

In an embodiment of the foregoing computer readable medium, the initializing of the TPM further comprises reading the NV state from the off-die NV memory and updating the TPM state PIN-attempt-failure count and the TPM state fuse count based on the NV state.

In an embodiment of the foregoing computer readable medium the initializing the TPM further comprises reading the NV state from the off-die NV memory, and in response to a failure in the reading the NV state from the off-die NV memory, resetting the TPM state to a cleared initial state and setting the TPM state fuse count equal to the blown-fuse count in the on-die RAM.

In an embodiment of the foregoing computer readable medium, the TPM state comprises a TPM state PIN-attempt-failure count for a plurality of different PIN values.

In an embodiment of the foregoing computer readable medium, the method further comprises receiving a PIN in a second PIN attempt for accessing the system protected by the TPM during the same session as the first PIN attempt. In response to the TPM state PIN-attempt-failure count satisfying a PIN-attempt-failure count policy, the method comprises, in response to the received PIN being correct clearing the TPM state PIN-attempt-failure count. In response to the received PIN being incorrect, the method comprises blowing a fuse and incrementing the blown-fuse count in the on-die RAM. In response to the fuse blow failing, the method comprises halting TPM activity and incrementing the TPM state PIN-attempt-failure count. The method further comprises setting the TPM state fuse count equal to the blown-fuse count in the on-die RAM and saving the TPM state to the off-die non-volatile (NV) memory.

Claim 1:
A system (<NUM>, <NUM>) for thwarting personal identification number, PIN, retry attacks in a trusted platform module, TPM, the system comprising:
a system on a chip (<NUM>), SOC, comprising:
a plurality of programmable fuses (<NUM>);
one or more processors (<NUM>);
one or more memory devices, the one or more memory devices comprising an on-die random access memory (<NUM>), RAM, storing a TPM state (<NUM>) comprising a TPM state PIN-attempt-failure count (<NUM>) and a TPM state fuse count (<NUM>); and the one or more memory devices storing program code to be executed by the one or more processors, the program code comprising:
TPM logic (<NUM>), the TPM logic configured to:
initialize the TPM, wherein the on-die RAM stores a blown-fuse count (<NUM>) comprising a count of currently blown fuses of the plurality of programmable fuses, wherein to initialize the TPM, the TPM logic is configured to at least:
in response to the blown-fuse count being greater than the TPM state fuse count:
increment the TPM state PIN-attempt-failure count;
receive a PIN in a first PIN attempt for accessing a system protected by the TPM;
in response to the TPM state PIN-attempt-failure count satisfying a PIN-attempt-failure count policy:
in response to the received PIN being correct:
clear the TPM state PIN-attempt-failure count;
in response to the received PIN being incorrect:
blow a fuse;
increment the blown-fuse count in the on-die RAM;
in response to the fuse blow failing:
halt TPM activity; and
in response to the fuse blow succeeding:
increment the TPM state PIN-attempt-failure count;
set the TPM state fuse count equal to the blown-fuse count in the on-die RAM; and
save the TPM state to an off-die non-volatile, NV, memory to update a NV state stored in the off-die NV memory.