TPM Lockout


Hello everyone. It’s Rafal Sosnowski from Microsoft Dubai Security PFE Team. Today, I am going to talk about TPM Lockout state.

TPM (Trusted Platform Module) is a small chip on the motherboard (discrete TPM) or part of the CPU implementation (firmware TPM) which can be used to securely store small amount of information (certificates, private keys, virtual smartcards, Bitlocker keys etc.). That data is completely isolated from HDD and partially from OS thus giving it maximum protection.

To get access to that information from OS level user has to present some kind of authorization value. For example, Bitlocker PIN to get access to the Bitlocker Keys, Virtual smart-card PIN to get access to the certificates and private keys etc.

 

However, TPM has special anti-hammering logic which prevents malicious user from guessing that authorization data indefinitely. Number of possible PIN failures varies across TPM specification:

  • For TPM 1.2 – each vendor has different lockout logic, even different TPM models from the same vendor might have different numbers implemented.
  • For TPM 2.0 – specification created by TCG (Trusted Computing Group), clearly states that maximum number of failed attempts should be defined, after which TPM gets locked out. Microsoft defines that maximum number of failed attempts in Windows is 32 and every single attempt is forgotten after 2 hours. This is configured by the Operating System at the time of taking ownership of the TPM

 

Assuming you failed 32 times to enter correct Bitlocker PIN you will see message saying "Too many PIN entry attempts":

 

TPM can be locked out by any application / software component that uses keys stored in the TPM and protected by PIN/password. For example, we can produce secure data-blobs, encrypted by the keys generated in the TPM. Access to these keys depending on administrator’s configuration will require or request a PIN:

 

Other example is use of Virtual Smartcards, where certificate alongside with private key is stored in the TPM. Starting from Windows 8.1 , Virtual Smartcards have their own lockout logic, where user has only 5 possible tries. Still, each attempt will increment the TPM counter by 1, but it is less possible that TPM gets locked out.

 

If your TPM got locked out, it means it will not accept any authorization data, even if it’s correct (correct PIN).

Now you have 4 solutions:

1) Unlock the TPM using the TPM.msc and TPM Owner Password.

2) Wait some time and enter correct PIN (TPM 2.0 will forget 1 attempt every 2 hours)

3) Wait x hours to completely reset TPM lockout counter (for TPM 2.0: 64 hours)

4) Clear TPM (that means all your data stored in TPM will be lost)

 

If your TPM is locked, you will see its status in the “tpm.msc” as "TPM is locked out" or “Ready for use with limited functionality”. The second status can appear on virtual TPMs and few hardware TPMs which is a glitch.

 

Note: “Ready for use with limited functionality” might also mean that TPM has been initialized by the previous operating system. So it is always better to check the status using PowerShell:

Get-TPM

Since Windows 10 (1511) we have added also lockout counters (for TPM 2.0) shown in above screenshot.

 

To unlock the TPM from tpm.msc you need to be an administrator of the machine and be in possession of the TPM Owner Password. We will talk about TPM Owner Password in details in one of the future posts.

 

Of course this method will not work when TPM is locked out by Bitlocker PIN (before you get into the Windows). For Bitlocker related lockouts you need to wait as there is no working workflow to unlock the TPM in this scenario, except using other protector, for instance 48-digit Recovery Password to get into Windows.

 

Some of you probably have already noticed 3 new GPO policies (added in Windows 8) that supposed to influence the TPM build-in anti-hammering logic by introducing some kind of software layer that would accumulate failed PIN attempts before forcing TPM into hardware lockout. Idea is to reduce number of true, hardware lockouts. However, according to my tests these policies don’t work on any of the tested systems (Win8, Win8.1, Win10) so I am trying to get confirmation from our developers what’s going on. Once I get some information I will update this post.

 

GPO I am talking about can be located in:

Computer Configuration\Administrative Templates\System\Trusted Platform Module Services\

Standard User Individual Lockout Threshold (default: 4)

Standard User Total Lockout Threshold (default: 9)

Standard User Lockout Duration (default 8 hours)

 

Hope this post was informative for you and I wish you good day.

Comments (16)
  1. Monty Sinha says:

    Hi Rafal,

    Great Blog, there is not much clear information out there on how TPM chips work especially with lockouts, this is very clear and concise especially around the durations, and attempt failures
    Question around lockouts from entering the wrong Owner Password/File. From my understanding if we put in the wrong Owner Password once it locks out any further attempts to enter the Owener Password is ignored and locks out any Owner password entries, with the error “TPMs prevent guessing the owner password..”, how long does this lockout last for, and is there any way around it?
    I can see that even if the OwnerAuth is lockedout it does not lockout the TPM, as my bitlocker pin attempt still work and the get-tpm does not show the TPM as locked

  2. TPM Owner Password Lock last for 24 hours and only way around it is to clear TPM.

  3. Dan says:

    Hi Rafal,

    Thanks for the post – was very helpful in solving an issue I had. Since solving that problem, I’ve been doing quite a bit of reading about TPM behaviour, and it looks as though the figures of 32 failed attempts and 2 hours are actually set by Windows. The TPM 2.0 spec just refers to variables such as recoveryTime and maxTries that can be set by the platform, and TechNet docs such as this one suggest Windows sets them to those values: https://technet.microsoft.com/en-us/library/jj889441(v=ws.11).aspx

    I’ve come across one other situation that could contribute to a lockout without the user needing to actually enter the PIN wrong 32 times. The TPM 2.0 spec states that a TPM 2.0 chip should increment the number of failed attempts by one when the TPM starts up if it wasn’t shut down cleanly previously. It’s some sort of mechanism to mitigate a possible attack. Details are in section 19.11.6 of the TPM 2.0 Architecture doc from TCG. Section is named “Non-orderly Shutdown”.

  4. Dan this is very valid comment. I agree that TPM anti-hammering is enforced by the Windows for TPM 2.0 (32 attempts, 1 failed attempt cleared every 2 hours). This happens at the time of taking ownership of TPM by the OS and values are written to the NVRAM (NvWriteReserved(NV_MAX_TRIES, &gp.maxTries)). So the values are not hardcoded in the firmware nor in the chip itself. Other operating systems (or even possibly next releases of windows) might have these numbers different. For simplicity purposes I have mentioned only TGT spec but now will update the post. Thanks again and happy reading.

  5. Someo says:

    Did you ever get confirmation about those GPOs?
    It seems they have nothing to do with BitLocker. So what are they for?

  6. Red7 says:

    Also very interested to know if you managed to get the GPOs to work. I am trying to reduce the amount of attempts someone has to guess a bitlocker pin from 32 attempts down to 10

  7. Nick Thompson says:

    I too would like to know why the 3 GPOs don’t work

  8. G.Priarone says:

    I can answer that – we’re having a TPM Lockout problem on Microsoft Surface platform and opened a service request with them, and If i understand correctly those policies only effect the Windows PIN Sign-in option, and NOT the bitlocker PIN interface. So if you set the policies and you’re offering the PIN sign-in option to your users you can rule Windows behavior when entering wrong PINs.

    Gabriele

  9. dude says:

    Is it possible to reduce the PIN attempts lower than 32?

  10. In Windows 10 1703 the TPM Lockout threshold appears to be 10 rather than 32

  11. My misstake. 31 seems to be default for 1703. The 10 attempt threshold must be set by MBAM

  12. @ Fredrik: We improved lockout in Windows 10 1703. Among many changes the lockout max is now 31, TPM forgets 1 attempt every 10 minutes, instead of 2 hours, and unprovisioned TPM has lockout of 10. Hope that helps

  13. Fredrik Jeansson says:

    Can you confirm that MBAM agent overrides Windows default setting and sets LockoutMax to 10?

  14. @Fredrik nope , MBAM agent doesn’t change anything related to the TPM. thanks

  15. Great article but is there a way to leverage GPO and define the maximum number of failed attempts in Windows from 32? I have tried leveraging the GPO to no avail on WIndows 10 1709 and 1803. Anyone else have any luck?

  16. Simon Davies says:

    Hi Rafal Sosnowski,

    It seems that the Virtual Smart Card user lockout policy is restricted to 5 attempts before preventing the user from attempting to send requests to the TPM (when using TPM2.0, which MS’s own documentation states is configurable to meet organization requirements). There are 2 issues here that I would like you to confirm if possible.

    1. The MS documentation indicates that this setting is configurable, but as you mention above, the GPO setting “Standard User Individual Lockout Threshold” does not seem to effect the behaviour and the users still get locked out after 5 failures. I confirmed that the GPO applied by checking the registry key “Software\Policies\Microsoft\Tpm\StandardUserAuthorizationFailureIndividualThreshold” had been changed to 10 after receiving the GP update.

    2. The documentation also indicates that the failure count will automatically decrease, allowing the user to then resume attempts to authenticate to the TPM, in my testing, I have found this to not be true. Using a separate account to access the machine, I can see the results of the Get-TPM command decrease the failed authentication count by 1 every 10 minutes (as per the new 1703 and above Windows behaviour), but even after reaching zero, the user is not allowed to attempt to authenticate again into the TPM with that virtual Smart card.

    The combination of these 2 factors is frustrating because it means that only the user support staff are able to unlock these virtual smart cards after only 5 failures but the end users, placing an extra burden on the support team and disruption for the end users.

    Is this really the current state of Microsoft’s Virtual Smart Card implementation?

Comments are closed.

Skip to main content