Dead Comment
Dead Comment
By analogy: imagine you want to make an aimbot to shoot people in an online FPS video game. You need your aimbot to calculate not only the vector to shoot at (our game has bullet drop and bullet objects, not hitscan weapons) but also to calculate for the opponent’s motion.
The way people at Google are doing it now, they look at a map of where the players are where when the game starts and try to ammo dump it… with no one there. Lol.
On the other hand, this is completely missing a proof that your device is running the firmware it claims to be running. The check of the device firmware is:
This verifies nothing.The Pixel is (or at least should be [0]) capable of attesting to its running firmware. There would be additional bonus points for having the bootloader stages flash QR codes containing the hashes of the next stages, which would enable very straightforward verification.
With a secure element-based approach, the device would need to be able to convince adb that it has a genuine Google secure element and that the secure element says the fingerprint is such-and-such. The former would likely need additional data in the Merkle tree to avoid a situation in which Google pushes out a targeted, properly signed, but malicious secure element firmware that lies about the fingerprint. (And the entire point of binary transparency is to make this type of attack difficult.)
With a bootloader approach, in principle the entire verification could be chained from ROM and no secure element would be needed.
[0] I haven’t dug through exactly what the Google secure element does. I’m quite confident that it can attest, to Google, something about the running firmware, because this is useful for DRM and the various (horrible and mostly useless) safety checks and attestations available through the Android APIs. But maybe it actually can’t attest to the firmware fingerprint to any party other than Google.
Use no cell towers or agree to be tracked. Lol.