Need for attestation?

[jackevans43]

From the Chromium blog:

We are committed to developing this standard in a way that ensures it will not be abused to segment users based on client hardware. For example, we may consider supporting software keys for all users regardless of hardware capabilities.

Should the implication of this design choice be fully explained? I know attestation can be a controversial topic, e.g. in WebAuthn, but currently the server will never know if the private key is hardware backed and cannot be extracted. While DBSC meets the aim of stopping "smash and grab" cookie theft, it wouldn't prevent malware from deleting the authentication cookie so forcing a reauthentication (visible to the user, but not obviously malicious) after patching the browser to use software to store the private key (which it can then steal).

This is related, but subtly different from #2 - where malware had access to the device before the sessions were authenticated - this case is where malware arrives after the sessions were authenticated.

[danmarg]

Yep, this is a good point. There's certainly such a risk (that malware forces the user to create a new session, but via tampering with the browser/TPM causes it to be unbound or bound to an attacker's TPM).

I want to argue here--and I think I'm right ;)--that DBSC cannot itself protect against this threat, however. I'll make a few observations, and tell me if they make sense:

1. TPM attestation ("it's a real TPM") without identity ("it's the expected TPM") doesn't do anything for this threat. (This seems self-evident: real, attesting TPMs are not in limited supply!)
2. TPM identity is a concern of authentication, not post-authentication session binding. That is, if you could prove "this is the trusted TPM", you wouldn't need the user to sign in at all, because you would presumably have already done some sort of proof of identity (e.g. pre-establish some keys).

DBSC doesn't aim to solve for (2) because it's not an "authentication" protocol, so to speak. But since (1) alone isn't useful, I think it's correct to say that DBSC cannot solve for this threat.

I do think there are DBSC-adjacent solutions here:

a. FIDO sort of solves for this already (in the sense that FIDO is an authentication protocol, and thus provides a way to prove that a user does have a pre-established key). I think it would be cool to enable FIDO users to prove that their DBSC session is tied to their trusted FIDO key (e.g. when the FIDO keys live in the TPM) to protect against this sort of attacker-bootstraps-a-new-session attack, but it seems to me somewhat hard to do and definitely out of scope for the near term.

b. I think it would be reasonable for enterprise users to have some sort of pre-established DBSC keys for specific domains (like intranet sites or whatever), and use it to enforce that their users only login from trusted devices (and of course make sure those keys are stored in "the right" TPM), but obviously that could never be (mis)used in a consumer context (since the entire point of DBSC, for consumers, is to generate ephemeral "trust on first use" keys) and it wouldn't require any sort of attestation.

So I think I agree that the design choice should be explained. My way-too-long explanation is that basically DBSC cannot solve for that because it's not an authentication protocol. Does that ring true to you?

[arnar]

Do clarify slightly what Dan said, it's not a user authentication protocol.

The "session restart" attack (for lack of a better name), where malware deletes the session/cookie and forces a new session to be set up, and then either ensures it is not bound or bound to attacker controlled keys, is a thing. In our prototyping, it's made us very carefully consider how session restart (i.e. re-issuing session cookies) is handled from the user's PoV.

The key thing here is that DBSC is meant to be a solution for non-interactive session authentication. Answering "is the key in the right TPM?", whether with attestation or other methods, does seem to clearly call for user-interactive authentication ceremonies, at least in some cases. It's our view that in such cases, we should look to WebAuthn for general non-enterprise use cases at least.

We are exploring ways that e.g. WebAuthn and DBSC can be tied together - such that e.g. a login with a passkey can vet that the key used for the subsequent DBSC session comes from the same device. But we first need to prove the overall viability of the refresh mechanism, I think, which is why it is not the first priority right now.

[venkyg-sec]

Thanks for the details and for this great initiative. offering my 2c here :-) To @danmarg's comment,

I think it would be reasonable for enterprise users to have some sort of pre-established DBSC keys for specific domains (like intranet sites or whatever), and use it to enforce that their users only login from trusted devices (and of course make sure those keys are stored in "the right" TPM)

Agree - this would be extremeley useful and alleviate the concern raised here and in #2 to some extent. It'll give Enterprises better control on validating the association of those cryptographic keys to their own definitions of "genuine device" :-) The validation could simply be Trust on first use based (or) fancier attestation schemes like TPM 2.0 TCG credential activation - but that choice could be given to the consumer and there could be a default which falls-back to the current approach in DBSC to register ephemeral keys.

I agree DBSC isn't User authentication protocol - but since it intends to provide session<>device binding - I see how it could create hesitation for adoption when the proof for "device bound" isn't validatable.

[jackevans43]

Thanks @danmarg @arnar for the explanation.

On the subject of binding WebAuthn and DBSC to the same device - I think this would be best eventual solution. There will be some complications with someone using a physical token to initially login but not wanting to have it plugged in all the time (e.g. phone), but to use the platform authenticator instead, but hopefully this is solvable with some thought.

In the case of a "session restart" attack due to malware being unable to extract hardware protected keys - there will now be two sessions, which may make it easier for the server to detect badness and force a reauthentication or warn the user they're logged in on X devices and encourage them to review them?

In the absence of WebAuthn integration, I can see an organisation (or something like Advanced Protection Programme) would want to provide some kind of option, enabled before malware appears on the user device, to configure that only hardware backed is good enough for DBSC, and maybe a way of enrolling trusted hardware devices?

[danmarg]

That's fair. I think my answer was over-indexing on Google's use case to some extent. For the case where a provider a) limits users to bound sessions and b) limits users to a single session at a time--two things Google is unlikely to do in the general case!--there is indeed a security gain from simply knowing the bound sessions are really bound to a real TPM.

So I concede that point. :)

I still don't favor DBSC supporting attestation, though; I think it's an area of potentially significant complexity, and as we are all agreeing, in many cases a FIDO linking is probably actually better anyway. But I agree there are use cases.

I personally think we should document this argument (i.e. why attestation is itself of limited value in DBSC, what the remaining use cases could be, and why we want to not pursue it for now as part of the protocol) and leave it there, though. Curious if that makes sense! :)