Comment by amluto | Hacker News Reader

Comment by amluto | Hacker News Reader

On the one hand, this is fantastic — vendors should absolutely publish proper commitments like this of their firmware images.

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:

    FINGERPRINT=$(adb shell getprop ro.build.fingerprint)
    VBMETA_DIGEST=$(adb shell getprop ro.boot.vbmeta.digest)

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.

I worked in Android Security. Pixel phones (and all other phones running Tiramisu+) can attest to the full DICE chain's integrity to any app that requests it. This can be done through the KeyStore API.

>> Pixel phones (and all other phones running Tiramisu+) can attest to the full DICE chain's integrity to any app that requests it. This can be done through the KeyStore API.

I do not see this - the KeyStore API available to apps still only returns an attestation as a normal X509 chain anchored into a local key, which is certified by Google. That is not DICE. Actually, there is no mention of DICE at all in any recent Android API docs.

Or it this documented somewhere else?

IIRC when your phone requests the attestation cert from Google it uploads its DICE chain. Then Google verifies the chain and gives you a 30 day cert (with a chain starting from a Google root, then an intermediary, then your leaf).

You might be able to see some custom Google extensions on the X.509 cert which will have some extra info. But that might get stripped when the cert is shown to an app.

I don’t remember all of the details. I worked on the infrastructure for the key acquisition but most of it was already set up when I joined and I was only on the team for a few months.

It is entirely irrelevant because cell phone companies add “analytics” (spyware) as part of their firmware stack… which Google and anyone else cannot block.

Use no cell towers or agree to be tracked. Lol.

There's a BIG difference between "My mobile carrier, who knows how much I spend with them on a monthly basis and my home address, probably date of birth and other customer details, also happens to know where I physically am" and "This piece of malware on my phone is intercepting every message I send"

> It is entirely irrelevant because cell phone companies add “analytics” (spyware) as part of their firmware stack… which Google and anyone else cannot block.

Who is that third party cell phone company adding spyware when I buy my Pixel phone from Google?

(Of course, Google can add spyware themselves; but they can also block it.)

If you buy your phone from a carrier. If you buy directly from a vendor I don't see how they (carriers) would be able to inject it. Radio firmware however is, as I understand it, a completely different thing...

Radio firmware has been a misnomer for a very long time, because the so-called baseband processor it runs on has access to and can control much more than just the radio. As far as I know, radio firmware on current phone SoCs has full, unlimited read/write access to all of the available RAM and can preempt and modify any process running on the application processor, so any indications regarding authenticity of any software running on the application processor - as provided by software running on that same processor - are effectively moot.

TL;DR: He who controls the radio (firmware) pwns your phone.

That's not true anymore, at least not for all phones: https://grapheneos.org/faq#baseband-isolation

Pretty sure Pixel already verifies the entire boot chain including firmware.

Yes, but the point of binary transparency is to assure device owners that their devices are running official Google firmware, even if Google’s signing key is compromised or if a court orders Google to sign a malicious image.

A verified boot chain does not provide this assurance.

You need source access to verify this. Much of the Pixel firmware is not available to users.

That’s a slightly different issue. Right now, Google could push a customized malicious firmware just to you. No one else would have a copy, and no one would be able to reverse engineer it to detect that it’s malicious.

With a fully functioning binary transparency system, Google would have to publish the fingerprint of the malicious firmware. An even stronger system would require that they publish the entire image as well. Then the attack could be detected.

https://www.wired.com/story/google-pixel-binary-transparency...

According to Wired, Android Verified Boot (AVB) prevents the computer owner from changing their mind about an OS update. No going back to the previous version. Leave no escape from from the latest improvements in Google's data collection to support its advertising services racket.

I believe that's only the case if the update increments the anti-rollback counter.

The point of anti-rollback technology is to make it so security holes are patched permanently: an attacker can't unwind updates back to the point at which the known exploit works.

"Anti-rollback technology" apparently cannot distinguish between an "attacker" and the computer owner.

Such is the nature of evil maid attacks and the like

No technology can.

Reply on news.ycombinator.com