←back to thread

596 points pimterry | 1 comments | | HN request time: 0s | source
Show context
sam0x17 ◴[] No.36862821[source]
But signing necessarily is happening on the user's device... what is to stop brave/etc from also signing their outgoing requests with the same key your local Chrome install is using? On a mobile device I can see how this would work but how would this ever work on (non-apple) PCs without exposing the key to anyone willing to poke around a bit?
replies(2): >>36863017 #>>36864099 #
ReactiveJelly ◴[] No.36863017[source]
I think the idea is, there is a chain of trust from a TPM (So you don't have access to the private key, ever) through the bootloader, OS kernel, Windows Update, and vendor-blessed web browser, to the server.

So Brave would fail when Windows says, "hm, your hash doesn't match any recent Edge version, so you don't get to issue a key signing request to the TPM."

Or it will allow the request but when it arrives at the server as "Windows, non-Edge browser" they'll hit you with the endless CAPTCHAs or just boot you out as a hacker.

It's not the web I grew up in.

replies(1): >>36863116 #
sam0x17 ◴[] No.36863116[source]
Right but how does edge prove itself to the TPM, what's to stop [insert alt browser here] from performing the exact same actions [insert blessed browser here] performs when it interacts with the TPM. It could even emulate a legitimate browser internally for the sake of argument, but it seems like anything could just pretend to be a blessed browser. Sure, you can hash binaries, but you can just as easily mess with their memory space at runtime after the fact so to the TPM (or whatever system checks the hash) the binary checks out because all the modifications are side-loaded after the binary runs.

It seems to me like you can only guarantee no tampering in an actually locked down system, like modern mobile devices.

replies(4): >>36863197 #>>36863550 #>>36863712 #>>36863811 #
1. alex7734 ◴[] No.36863550[source]
> but you can just as easily mess with their memory space at runtime after the fact

You can only do that because Windows lets you do that. That's something that can change.

> It seems to me like you can only guarantee no tampering in an actually locked down system, like modern mobile devices.

Yes, the whole point of remote attestation is to be able to prove to the other party that your device is running an approved and fully locked down OS+browser combo before it sends you any content.

It does this by putting the code that creates this guarantee in the only place that you can't (easily) change: in the silicon of your CPU.