←back to thread

Apple already shipped attestation on the web, and we barely noticed

(httptoolkit.com)
596 points pimterry | 5 comments | 25 Jul 23 14:10 UTC | HN request time: 0.9s | source
Show context
sam0x17 ◴[25 Jul 23 14:32 UTC] 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 ◴[25 Jul 23 14:44 UTC] 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 ◴[25 Jul 23 14:50 UTC] 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. jsnell ◴[25 Jul 23 14:55 UTC] No.36863197[source]▶
The browser doesn't interface directly with any of the hardware, the operating system does. And the integrity of the operating system can be attested to by the hardware via a chain of trust all the way to the secure bootloader.
replies(1): >>36863505 #
2. sam0x17 ◴[25 Jul 23 15:12 UTC] No.36863505[source]▶
Yeah but what's to stop me from spawning a hidden instance of edge, sending keys etc to it to get it to visit some page, and using either window sub-classing (to hack it's memory space and read the request directly) or a local proxy server to steal the attestation it generates before terminating the request?

Likewise what's to stop you from patching the operating system directly (ok secure boot)

You could also just emulate an entire windows OS + TPM and have the emulator do it it sounds like

Like any scenario where I'm allowed to run arbitrary code within the OS with administrator privileges sounds like you could escape this.

replies(1): >>36863786 #
3. alex7734 ◴[25 Jul 23 15:31 UTC] No.36863786[source]▶
> You could also just emulate an entire windows OS + TPM and have the emulator do it it sounds like

Yes, but your emulated TPM is not on the approved list. To impersonate an approved TPM you would need to pull the keys from a real TPM which requires (probably very expensive) semiconductor lab tools and trashing the chip.

replies(2): >>36867133 #>>36868790 #
4. sam0x17 ◴[25 Jul 23 18:30 UTC] No.36867133{3}[source]▶
Such an evil pattern. We need to eliminate this at all costs.

Luckily I think if Chrome were to move forward with this they'd face extreme anti-trust stuff as a result

5. hellojesus ◴[25 Jul 23 20:21 UTC] No.36868790{3}[source]▶
If you did trash the chip whilr managing to successfully pull the tpm keys, could you then use that key to sign requests in an unapproved vm or on metal with a different root tpm?