Reason for TPM lockout

Question

We have several Surface Pro 3 devices deployed with BitLocker enabled in TPM + PIN mode. The devices have a TPM 2.0 chip and are running Windows 8.1 Pro.

We have an issue where users are occasionally presented with the "Too many incorrect PIN attempts" error when they enter the correct PIN. They must then enter the recovery key to be able to continue the boot process. They then need to enter the recovery key every time they boot the device until we manually reset the TPM lockout using tpm.msc, which is obviously inconvenient.

For some reason the TPM is entering the lockout state, but it doesn't seem to be because of repeated incorrect PIN attempts. The fact the lockout doesn't eventually time out if you leave the device running also suggests it's for some other reason other than reaching the maximum number of incorrect authentication attempts. I understand the TPM 2.0 spec states that this should be the case, unlike the TPM 1.2 spec which left the exact behaviour to the vendor.

Running Get-Tpm indicates that the TPM is definitely in a locked state, but doesn't provide any information about the cause.

Does anyone know if there is anything I could do to try and determine the root cause of the lock outs?

Answer 1

The explanation I've read is that the TPM has no access to write any kind of log or cause for the lockout to the drive to which it's denying access. Sensible. Giving a reason could also present a security flaw.

The only information I've been able to find along these lines is the number of bad passwords entered. Open an elevated powershell prompt and enter:

get-tpm

Unlike the normal command shell, you'll have entries for LockoutCount and LockoutMax. This will give you a count of how many bad passwords were entered. I'm sure the users are convinced they're always entering the correct pin, but I've found there's usually a miscommunication.

That being said, there are MANY other lockout reasons. https://technet.microsoft.com/en-us/library/dn383583(v=ws.11).aspx Specifically "What causes Bitlocker recovery?" Anything from inserting a CD to letting the device's battery completely discharge can cause a lockout. This is something I'm attempting to resolve through a mixture of user education, helpdesk education, and evaluating which group/local policy settings to change. https://technet.microsoft.com/en-us/library/jj679890(v=ws.11).aspx

Answer 2

I managed to make quite a bit of progress troubleshooting this in the end. I'll try my best to remember the details, but it's been a while...

Unfortunately, the machines in question were Windows 8 machines, so the Get-Tpm cmdlet doesn't return information regarding the lockout counters. I eventually managed to put together a custom script to read these counters directly from the TPM, and sure enough, the lockout counter had hit the lockout threshold value. This was the case even though we hadn't entered the PIN incorrectly.

After a lot of digging, I eventually stumbled across a section in the TPM 2.0 specification that describes a mechanism that is almost certainly causing the problem. Before I go into detail, a little bit of background would be useful... Before an OS can make use of the TPM, it must call the TPM's startup routine. This seems to happen prior to the BitLocker PIN screen being displayed. Conversely, once the OS has finished using the TPM, it should call the TPM's shutdown routine. Windows seems to do this during the OS shutdown sequence.

The problem comes when the system powers down without the OS shutting down cleanly. In this scenario, the TPM's shutdown routine hasn't been called prior to the chip being powered down. The TPM 2.0 specification states that if the TPM's startup routine is called without a previous call to the TPM's shutdown routine, it should increment the lockout counter by one. This feature exists to protect against a particular type of attack against the TPM. Therefore, when the device is powered on again, the lockout counter gets incremented by one, even if the user enters the correct BitLocker PIN.

In my particular case, the devices in question were all Microsoft Surface Pro 3 tablets. My hunch was that users were holding the power button down to power the machine off without shutting it down cleanly. Usually, this isn't a big issue as the lockout counter will eventually decrement again after two hours. However, if they do this often enough, the lockout counter does not have time to decrement. The problem is compounded by the fact that the timer used to track when to decrement is reset if the machine is power cycled, meaning it must be left on continuously for two hours before it decrements. Some users only get their machine out for short periods.

The Surface Pro 3 supports something Microsoft calls "Connected Standby" or "InstantGo". This is a feature which makes the device behave more like a mobile device in terms of power management. Tapping the power button causes the device to go into a low power mode, rather than traditional standby or sleep. However, we had switched the power plan to "High Performance", which has the effect of disabling the Connected Standby mode, making the device behave like a traditional PC. I think this may be a factor in the problem.