Chrome Origin Trial: Device Bound Session Credentials

Anything that can be done via phone will be done via ai talking to ai.

As long as banks are held accountable or generally blamed for people handing over their savings to foreign scammers, any kind of external access will be considered a threat. Every single time people get scammed by fake apps or fake websites or fake calls, a large section of society goes "the bank should've prevented this!!!".

Here, one particular bank is popular because of their pro-crypto stance, their high interest rates, and their app-only approach. That makes them an extremely easy target for phishing and scamming, and everyone blames the bank for the old men pressing the "yes I want to log in with a QR code" button when a stranger calls them. Of course, banks could stop scams like that, so the calls to maybe delay transferring tens of thousands for human review aren't exactly baseless, but this is how you get the situation where businesses struggle to integrate with banking apps.

There are initiatives such as PSD2, but those are not exactly friendly to the "move fast and break things" companies that you'll find on HN (because moving fast and breaking things is not a good idea when you're talking about managing people's life savings).

The TPM is used here because it's the most secure way to store a keypair like this. But, as the spec says:

> DBSC will not prevent temporary access to the browser session while the attacker is resident on the user’s device. The private key should be stored as safely as modern operating systems allow, preventing exfiltration of the session private key, but the signing capability will likely still be available for any program running as the user on the user’s device.

In other words, if a more secure alternative than TPMs comes into play, browsers should migrate. If no TPM is available, something like a credential service would also suffice.

As for TPM emulation: it already exists. Of course, TPMs also contain a unique, signed certificate from the TPM manufacturer that can be validated, so it's possible for TPM-based protocols to deny emulated TPMs. The Passkey API supports mechanisms like that, which makes Passkeys a nice way to validate that someone is a human during signup, though the API docs tell you not to do that.

I don't think this will be a worthwhile security benefit for most sites, and comes with trade-offs, but we already have trade-offs for higher security around sensitive things like banking and email where most users need a lot of protection.

* Someone inspecting the page with developer tools

* Logs that accidentally (or intentionally) contain the cookie

* A corporate (or government) firewall that intercepts plaintext traffic

* Someone with temporary physical access to the machine that can use the TPM or secure enclave to decrypt the cookie jar.

* A mistake in the cookie configuration and/or DNS leads to the cookie getting sent to the wrong server.

This would protect against those scenarios.

Additionally, the TPM will now need to have a root store of root CAs. Will the TPM manufacturer update the root store? Users won't be able to install a custom root CA. That's going to be a problem, because custom root CAs are needed for a variety of different purposes.

When a user gets an HTTPS certificate error, now it'll be impossible for the user to bypass it.

Ironically the design you propose, juggling headers over to a secure enclave and having the secure enclave form the TLS tunnel, is significantly more complex than just using an asymmetric keypair in a portable manner. That's been standard practice for SSH for I don't even know how long now - at least 2 decades.

Oh also there's a glaring issue with your proposed implementation. The attacker simply initiates the request using their own certificate, intercepts the "secure" encrypted result, and decrypts that. You could attempt mitigations by (for example) having the secure enclave resolve DNS but at that point you're basically implementing an entire shadow networking stack on the secure enclave and the exercise is starting to look fairly ridiculous.

Binding a session cookie to a device is pretty simple though. You just send a nonce header + the cookie signed with the nonce using a private key. What the chrome team is getting wrong here is that there is no need for these silly short lived cookies that need to be refreshed periodically.

First of all, this approach have the nice fact that now we need new TPMs capable of doing that, and even if people could update it, we will need to wait for everybody to update their TPMs. So lets wait another 10 to 15 years before we’re really sure.

Second, the attack vector google’s approach is trying to protect against is assuming someone stole your cookies. Might as well assume that someone has gained root on your machine. Can you protect against that? Google’s approach does regardless of how “owned” your machine is, yours doesn’t.

It’s not like you’re gonna hand off the TLS stream to the tpm to write a bit into it, then hand it back to the OS to continue. The tpm can’t write to a Linux tcp socket. whatever value the tpm is returning can be captured and replayed indefinitely or for the max length of the session.

So you’re back where you started and you need to have a “keep alive” mechanism with the server about these sessions.

Google’s approach is simpler. A private key you refresh your ownership of every X minutes. Even if I’m root on your machine. Whatever I steel from it has a short expiration time. It cuts down the unnecessary step of having the tpm hold the cookie too. Plus it doesn’t introduce any limitations on the cookie size

I get the benefits of restoring a full backup, but in this instance it would seem to lose practical security benefits for theoretical purity.

Many sites already have some protections against that by for example requiring you to enter your password and/or 2fa code to disable 2fa, change privacy settings, update an email address, etc.

In the case of bearer tokens there are many cases where attackers have managed to steal them without achieving full device compromise. Since it's literally sending the key in plaintext (horribly insecure) all it takes is tricking the client software into sending the header to the wrong place a single time.

In the short term it's about economics: Infostealer malware today scales really well because it can a) exfiltrate cookies quickly and clean it self up, mostly evading any client based detection, and b) sit on large stashes of long-lived cookies and carefully "cash them in" in ways that evade server side detections.

A short-lived cookie forces different behavior for b, which we think will make it more detectable server side, and binding in general will force malware to act more locally, which will make it (far) more detectable locally.

In the long term, DBSC also is designed so that the session management and key registration is somewhat decoupled from that short-term cookie business. If and when we can sign more often (perhaps every request), I believe the DBSC API will still be useful for websites to manage the session key and lifetime.

I mean, if my threat model starts with "I have a mal/spyware running alongside my browser with access to all my local files", I would pretty much call it game over.

> The proof of possession should happen at the start of each connection. With HTTP3 you shouldn't need a lot of connections.

That could possibly be workable in some situations, but it would add a lot of complexity to application layer load balancers, or reverse proxies, since they would somehow need to communicate that proof of possession to the backend for every request. And it makes http/3 or http/2 a requirement.

Importantly, the presence of attestation in webauthn could potentially compromise privacy or user choice in certain cases. DBSC has zero support for that.

You could certainly use a webauthn credential to establish a DBSC session though.