←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. flangola7 ◴[] No.36863811[source]
The TPM gathers various data about the system, including if any user process is running with access permissions that could tamper with memory space. It trusts the OS and drivers to do this because the entire stack is cryptographically verified from boot onwards. If the environment is one where an app could be spoofed, this will be included in the attestation request and the attest will fail.

You might be able to get around it by finding a zero day in the Windows kernel, but as soon as Microsoft discovers and patches it their attest server will stop providing attestations for devices until they install the OS update and reboot to reestablish a trust chain.