So, first off, the entire point of a session cookie is to uniquely identify you. Like, if you log into a website, it should be you, right?

Second, you're close but just a bit off. While the TPM has a secret internally, it wouldn't expose that - it would be used to generate other secrets, or to sign things, basically it's sort of like putting a crypto library into your device so that you can perform cryptographic operations without knowing the secrets involved. But yes, there's a seed that gets soldered into the device itself.

I use TPMs to ensure that no one can access our AWS environments from devices other than those we own, for example. I'm not really an expert on this sort of thing, though I do work in security professionally - hopefully I'm not butchering this. There are quite a few experts on the matter who comment on HN though, maybe one of them can speak more authoritatively on this.

edit: Actually, I misread maybe - you aren't off. The session cookie is tied to the TPM - either existing within it, or requiring re-validation via the TPM.

I don't want most session cookies to know I'm the same person from a previous cookie. And even if they know I'm the same person, I'd prefer they still not know whether the device I just logged in on is the same as a previous device.

Separately from that, using the TPM to lock the session cookie to the device sounds useful.

I think we should differentiate a TPM backed cookie from, say, a tracking cookie. It isn't like an arbitrary website can track you with the TPM. TPMs aren't exposed to the web by any browser, at least to my knowledge - except through intermediary protocols provided by something like webauthn or an extension (Extended Verification, for example).

Again, maybe someone more knowledgeable can explain more - I'm a consumer of TPMs, and I understand the concept, but I'm no expert.

For a web exposed use case: TPMs are used as part of Windows's FIDO2 implementation, to make sure that the secret actually cannot be exfiltrated to other hardware.

That doesn't come with any particular privacy concerns however.

Right, I meant that there's no javascript API to communicate with a TPM directly as far as I know. You can still use a TPM as part of your auth to a website, it just has to go through a protocol where the browser handles the interaction. So a website can't leverage the TPM for tracking purposes afaik.

But web is really not so much my thing, so I'm now at the point where I'm probably going to start saying incorrect things.

It's too low level of an interface to directly expose to web apps tbh.

Ah so the vendors implementing the WebAuthN spec in their browser can use the TPM as "secure storage" for the related keys?

Yes.

Well you can't secure normal cookies against extraction with a TPM, because you have to extract them to use them.

So the question is how a particular protocol works, and whether a site can still identify you after you've deleted your session cookie. As far as I understand it, if you were wantonly using webauthn for all your session cookies, it would be relatively easy for a site to check if you're the same person as before.

> because you have to extract them to use them

Nope, the thing is that you ask the TPM to sign something with the key/secret, but the TPM will not allow you by design to exfiltrate the secret.

Doing that would not be a normal cookie, which is my point.

You would have the TPM hold a secret that's used to repeatedly re-authenticate the session. Though today I don't know that this is often the supported workflow - for example, most of my TPM-based policies only enforce device-authentication on sign-in and not on every API call.

"So, first off, the entire point of a session cookie is to uniquely identify you. Like, if you log into a website, it should be you, right?"

Session cookies (until this) only identify a session, not a person or a piece of hardware.

Sure, but I think most people expect sessions to be tightly tied to identity - especially given the common login process.

> I think most people expect sessions to be tightly tied to identity

There are plenty of people who'd prefer sessions to be as loosely tied to identity as possible / as necessary.

OK? So you log into a website with an email and password and you're OK with moving the cookie to another computer and using it there, rather than having to re-prove that it's you? I don't think you know what a TPM does honestly, there's a clear ignorance in this thread as to how this identity functions - it does not have privacy or tracking implications.

I don't necessarily care about moving a valid session to other hardware as much as I care about being able to create a valid session on any random hardware without having to trust any 3rd parties or rely on any 3rd parties permission.

TPM would be fine if 2 things were true:

1 Only the end user managed the secrets inside. Or at least they could, and without any penalty like "This device is insecure and so you can't use it for X". It's fine if there are default secrets and most people never change them. I'm not sure about this last bit but I think ideally also any factory default secrets should be erasable, no indellible unique serial number.

2 The interior implementation is fully open and disclosed. How the secrets are generated and managed. Not just a description and a promise, but an actual full set of public specs such that any manufacturer can produce a fuctioning device, or even I could out of other parts.

These things would allow the end user to be benefit from the mechanism, while leaving the end user in ultimate final control over their property and their identity and information. And it requires both. 1 is hot air without 2.

Any objections to this are automatically invalid, as they depend something they have no right to.

"I need to know that your computer is not doing something I don't want." is just fundamentally invalid.

I think their might have been some disconnect on how we view the term session cookie (A cookie for a singular browser session vs. one specifically for an authenticated user) but the rest of this is starting to make sense.

Yeah I'm referring to an authenticated session like a login cookie you get when you sign into some site.

That's still just a session. It's just some state that you are remembering out of band to use with a stateless protocol.

I'm not saying otherwise.

No. Every TPM has a factory-supplied unique key called the endorsement key, but every other key on the TPM is randomly generated on the TPM. The keys you actively use /can/ be tied back to the endorsement key, but there's no need for them to be - for most cases, any cryptographic material you generate on the TPM will be indistinguishable from material you generate on the CPU, other than to the local client.

It’s like having a Yubi key soldered into your machine.

Each identity you want to protect has its own key (so its’s not necessarily de-anonymizing) with physical access - pin, biometric verification - required for use.

It’s potentially very useful, although I 100% expect it to be backdoored by every geopolitical block.