We should also document somewhere what circumstances will lead to this situation.

Good idea!
A few tiny questions:
1. What reasons do we have for it going into defensive mode? Is it only too many failed attempts?
2. Do we always know the amount of time left? Can we update it as a counter (every second)?

My thinking is that it would be nice to have the same thing for this and the upcoming messaging for failures of new unlock methods. (e.g. if PIN fails it will show the password UI and should have a message explaining why).

Thoughts?

TPM experts, please help with Omri's questions.

I'm just starting working on TPM, so far from being an expert. But will try to help with the tiny questions anyways:

1. From the TPM point of view it's too many failed authorization attempts for any of the protected objects including various keys and other TPM-internal data. It's a separate question how it translates to user actions: it's not necessarily login attempts. If some sw unsuccessfully continuously tries to access the protected objects, it may also trigger the attack defense regardless of the user logins.

2. In short: It's vendor-specific. It seems like all current TPMs support it (same capabilities are used for Platform.TPM.DictionaryAttackCounter metric in src/third_party/trousers/init/tcsd.conf), but that's not guaranteed.

Some details: There is an optional capability in the TPM spec that among other things returns the remaining lockout time in seconds. Not all vendors support it, though. In fact, Infineon doesn't. But it has its own vendor-specific capability for that. Haven't tried on the actual hw, so far all the information is just from reading the specs and code.

Additional notes:
- It's also possible using the same mechanism to get the current failed authorization counter and the threshold when the attack is detected. And warn the user if the threshold is near. It's especially important as the counter slowly decrements with time. You can have 9 failed attempts an hour ago, and then after 
- At least in some cases (Infineon), the thresholds, the initial and max lockout times, etc are configurable.

In #4 the first note should have read:
- It's also possible using the same mechanism to get the current failed authorization counter and the threshold when the attack is detected. And warn the user if the threshold is near. It's especially important as the counter slowly decrements with time. You can have 9 failed attempts an hour ago, and then after a single failed attempt an hour later the device goes into the defense mode.

Hold on please.  I am not sure that we're starting with the correct premises here.

The initial comment says:

--------
Right now, if the TPM on a Chrome OS device goes into defensive mode the machine will simply reject login requests with no feedback.
--------

This may be true, but it's usually worse.  Typically the device won't boot.  It's possible that the TPM enters defensive mode in the middle of a boot session, but I have never seen that happen.

Furthermore, wrong passwords should NOT increase the dictionary attack counters.

A child playing with the laptop in a very precise manner CAN cause DA counter increases (on some TPM models).  The child would have to power the laptop on, then hold the power button down for 10s while it boots.  But in this case, the chromebook will enter recovery mode at the next boot.

Corruption of certain keys stored on disk may cause DA counter increases, but that should have been fixed by Darren, by checksumming those keys.  It is possible that we don't recover well from a failed checksum, but that's a pretty different situation.

This bug was opened following a huge, mind-numbing thread which should be taken out and shot.  I will do that now.  I recommend closing this bug.

OK, sorry---I now see you're referring to issue 341358, which is indeed TPM_E_DEFEND_LOCK_RUNNING.  Should we just use that bug then?

Alright, thanks both for the answers and details.

My recommendation would be to solve the main issue which is informing the user that he/she can't enter, and why.

Warning the user that if they fail this time it will move to defensive mode is a rare case and could also be confusing as it changes over time (it's not as if you have exactly 10 attempts ever, is it?).

I plan to go to UI review with the following two recommendations:
a) block the user from submitting the password (greying out the password field)?
b) inform the user with a subtext along the lines of "Try again in X seconds" where X is a counter with accuracy of single seconds. 

Does this make sense?

#CBC-RS/TC-watchlist

We can do a) after a failed auth since login screen does not poll cryptohome status and only knows about the defensive mode after a failed auth (cryptohome needs to return a new error to indicate defensive mode). Would that be okay?

A few clarifications:
- You can use 'tpm_status' in crosh to see lockout stats including seconds remaining. The same information is available to chrome via cryptohome APIs.
- A failed password attempt does *not* change the dictionary attack counter -- there is nothing the user can do that will affect this counter. It should *never* be non-zero when using Chrome OS.
- Issue 341358 tracks occurrences of non-zero timers and the resulting lockouts. We've seen various software and hardware issues contribute to this problem and all known problems have been fixed. The bug is still open because there are still cases (though much fewer).
- The best solution for a device which encounters this problem is factory reset. Not only does this reset the lockout and the counter, it also means our latest fixes will come into effect when the TPM is re-owned.

+Elizabeth, Maria for UX.

Here are the mocks for notification and the alert message on the sign in pod. 
Please let me know if you have any questions.

Deleted: TPM-1.png 724 KB

	TPM-1.png 724 KB View Download

Deleted: TPM-2.png 713 KB

	TPM-2.png 713 KB View Download

I think there's a disconnect here. At the moment, PIN can't be used for sign-in (though that's changing).  We should probably decouple the messaging from the authentication method.

There are a few issues here:
1: We shouldn't allow a login attempt at all while the TPM is in defensive mode.
2: We don't have a way of providing a reliable estimate of how long reset will take (it depends on the hardware in the device and it doesn't give us state).
3: Some devices will only process cool-down while the device is turned on, so we should suggest leaving the device on and connected to power while it resets.

We should also provide some info about why this happened (Too many login attempts so we've locked the device for security, or somesuch)

A couple fixes here:
1. The field is inactive in defensive mode.
2. It's frustrating if the users do not know how long they need to wait. I think we need help for the string here.
3: Should we display a message for this as well? If so we need new string.

Deleted: TPM-1.png 741 KB

	TPM-1.png 741 KB View Download

Deleted: TPM-2.png 727 KB

	TPM-2.png 727 KB View Download

What would this look like if there are multiple pods on the start screen?

Would it make sense to not show the pods at all?

zalcorn@ does it make sense to get a few of us in a room and try to nail this down?

Does the TPM lock out all users or just the one that has had too many unsuccessful login attempts? 

Re #20: All users on the device are affected. When TPM gets into defensive mode, it could not be used to decryt any user's keyset.

Is there any way we could change this behavior of the TPM? It would be pretty bad in a school setting for example if one user locks out *everyone* for an undetermined time. 

Regarding the second point in #16 was under the impression from talking to @zalcorn and @tbuckley that we could do something to figure out a time estimate once the TPM has entered defensive mode, is that not right?

Generally it seems like the TPM is a very moody chip, how much influence do we have to change things like requiring power supply for cool down etc?

Unfortunately, my understanding is no, we can't change this behavior for the commonly used TPM 1.2 chips, unless the 3rd party vendors change the firmware on those chips specially for Chrome OS. Iiuc, TCG standard ver 1.2 didn't have a standardized way even to change the number of allowed attempts or the lockout duration. So, the duration is not always known/guaranteed. Spec ver 2.0 includes lockout parameters as a standard feature, so there it can be displayed, if needed.

Attempting multiple unsuccessful logins should not lead to lockouts. But, yes, those lockout incidents do happen in practice (rarely) for other reasons.

And, as already mentioned in c#7, if a defensive lockout happens, and the machine is rebooted / awaken from sleep, the user doesn't even get to the login screen. The firmware fails to boot and shows the recovery screen. This is what's typically seen in the wild for lockouts. 
It's only if the lockout happens while the user is actively using the device and then signs-out & attempts to sign-in again we can catch that state when a login screen should handle it in a special way.

So, quite possibly, the firmware behavior should also be updated to detect such cases and let the OS display this new UI mode being designed here, or do something else.

As discussed with Zach and Albert, the correct solution seems to be that if a user has signed out and the TPM is in defensive mode? We should simply reboot the machine.

Concurrently, we should update the firmware splash screen to detect if the TPM is in defensive mode and display and appropriate message.

Thanks for the update Rahul.

I've created crbug/692838 to track the reboot on update. Rahul, can you assign this to someone to implement?

The firmware screen for TPM is not the only one that needs updating, I'll start a conversation with the platform team about how we should do that.

Maria and Elizabeth, please don't worry about the UI here further, I'll keep you posted on next steps.

Closing this bug as it's no longer actionable, the resulting next steps from this are being tracked elsewhere (namely in crbug/692838 and investigations into reworking firmware screens).