zlacker

[return to "Web Environment Integrity API Proposal"]
1. hamish+Z71[view] [source] 2023-07-21 23:54:24
>>reacto+(OP)
How can the “attesters” verify the integrity of the user agent? Sure the attestation is signed, but why can’t we mess with the data sent to the attester and just nullify the entire point of the proposal? The “browser acceptance criteria” in the spec, that would presumably contain this info, is just “TODO”. Thanks Google for conveniently omitting that key detail.

Also interesting that its implied in the explainer that attesters are just HTTP endpoint dealing with “billion-qps” traffic. Again, point above, but also how can we trust any attester to not use the (completely unobfuscated) information the user agent is sending them?

I guarantee that big websites will host their own attesters, only allow use of their attester, and require attestation for every request, allowing them to fingerprint every single user.

◧◩
2. anders+xb1[view] [source] 2023-07-22 00:23:47
>>hamish+Z71
You don't send any data to the attester. It runs locally on your device, or rather is part of its core functionality. Building a chain of trust from the TPM hardware module, validating secure boot is enabled, validating the kernel and drivers have not been tampered with, eventually validating the browser has not been tampered with.

You can't run your own attester - these are implemented by the companies who provide the hardware, such as Microsoft or Apple.

◧◩◪
3. maxloh+d22[view] [source] 2023-07-22 10:46:00
>>anders+xb1
Could this be reverse engineered so that third-party browsers sent the same hash as Chrome?
◧◩◪◨
4. kevinc+fN5[view] [source] 2023-07-23 20:38:00
>>maxloh+d22
Not without exploits. This is a cryptographically signed chain of trust from hardware to booloader to kernel to the OS to Chrome. If any of these are tampered with the signature will not validate and they won't load. If you try to run an unsigned version the layer above you will refuse to sign the attestation. The only solution is finding exploits in the chain. If at any point you get unsigned code running or manage to get a signature outside of the signed environment then you can "spoof" the attestation. But while it is a big stack it is explicitly designed to prevent this exact issue, so it won't be easy and it will be quickly patched.

This is the same setup as SafetyNet on Android. SafetyNet can be worked around right now for "Basic Integrity" but this works by making your device claim to be an older device. Newer devices support hardware backed attestation for which there is no general work around. You can be sure that this proposal will be using hardware-backed attestation from the start.

[go to top]