Pixel Binary Transparency: verifiable security for Pixel devices

https://security.googleblog.com/2023/08/pixel-binary-transparency-verifiable.html

by transpute • 3 years ago

205 114 3 years ago

security.googleblog.com

WirelessGigabit• 3 years ago

Pretty soon Android will be as locked down as Android.

Gh0stRAT• 3 years ago

It already is

Vt71fcAqt7• 3 years ago

I think we're well past that point ;)

Chabsff• 3 years ago

Perhaps, but this has little to do with it.

In what scenario is user-auditable traceability of firmware images anything but a good thing?

mschuster912• 3 years ago

I love on the one side that Google takes security serious. On macOS, Windows and Linux I can easily set up a device in a way that makes it (a decent passphrase required) all but impossible for any attacker to retrieve the data on the device or modify the OS if the device is at rest. LUKS/Bitlocker/FileVault encryption and UEFI Secure Boot (x86)/SIP (Apple) make sure of that.

The problem is that way too many mobile applications these days take extraordinary difficult steps to make sure it's impossible to exercise the freedoms granted by the GPL in practice. If you "root" your phone, it's a constant game of whack-a-mole to keep banking, Netflix, Google Pay and other applications running.

On top of that it's impossible to put a new root of trust in place... I don't want a secure boot warning message if a firmware is running that I flashed on the device, I want it visible when someone else placed a manipulated firmware on it. And that point applies to Apple just as well.

Waterluvian• 3 years ago

Part of the issue there is that they’re focused on the 99% of users who aren’t flashing firmware onto their phones.

JohnFen3• 3 years ago

This is probably the largest (but far from the only) reason why I'm ditching smartphones entirely.

fsflover2• 3 years ago

Perhaps you might like GNU/Linux phones, which have no such problem (and also solve many other problems).

sznio• 3 years ago

It's the corporations that get to trust your device. You get nothing.

londons_explore• 3 years ago

I don't want a secure boot warning message if a firmware is running that I flashed on the device, I want it visible when someone else placed a manipulated firmware on it.

And how exactly do you propose achieving that, when that someone else might have tampered with the phone before you got it?

The goal of Google's security architecture is that a dodgy phone seller/repair shop can't pre-root the phone and siphon all your private data to Mr Evil unless they have access to a silicon fab to remake the main CPU with a new trust root.

figmert• 3 years ago

Mr Evil

Erm, it's Dr. Evil to you sir.

mschuster912• 3 years ago

And how exactly do you propose achieving that, when that someone else might have tampered with the phone before you got it?

Wipe the device as a condition of unlocking the bootloader root trust keyset. Easy, and more secure than any classic x86 UEFI bootloader. That gets rid of the threat of dodgy repair shops.

The only issue will be manipulating devices before they're sold the first time, but tamper-proof packaging resolves that.

sudosysgen• 3 years ago

That's an easily solved problem. We already have the pre-boot warning. It fixes that problem just fine. Add a reboot on initial setup and make it scarier if you're just setting up the phone and you'll be fine. A week after you've setup the phone there's no reason why you'd keep it.

e2le• 3 years ago

And how exactly do you propose achieving that

A signed-by-google first-stage bootloader could display a message warning the user before handing off to an unsigned second-stage bootloader.

The goal of Google's security architecture is that a dodgy phone seller/repair shop can't pre-root the phone

I'm curious how big a problem this was with refurbished second-hand laptops that often come with a pre-installed OS. At the very least, I have the freedom to reinstall Windows/Linux.

We need to find real solutions to the e-waste problem, it's unacceptable to be throwing away so many working phones simply because their manufacturer has decided to stop publishing OS updates after 2/3/4 years. I own a few older computers that are almost a decade old and run the latest version of Debian/Ubuntu. There is no reason phones should be treated any different.

devit• 3 years ago

On Google Pixel devices you can load your own verified boot key into the "avb_custom_key" partition and then it will only boot OSes signed by it (it will also say that you are running a different operating system in the boot screen).

GrapheneOS for instance uses this mechanism.

Unfortunately you can only register one key and you have to wipe the device to change it, but that's still fine for most use cases.

codethief3• 3 years ago

Your phone will still display a warning during bootup, though.

DistractionRect• 3 years ago

Some devices allow you sign your own images and relock the bootloader [0].

This allows you to modify your image, sign it, flash it and relock your bootloader. If you have the infrastructure in place, future updates could be rolled out as OTA updates for your custom rom.

You'll still fail hardware attestation and afaik whatever api that returns the boot status differentiates between a vendor signed and a custom signed image.

So not perfect, but you lose the bootloader unlocked nag.

[0] https://android.googlesource.com/platform/external/avb/+/pie...

folmar• 3 years ago

Sadly those devices are only Google and Nexus, so expensive.

dishsoap2• 3 years ago

Seems like a bit of a nothingburger, now you have two ways to verify your binaries came from google and are unmodified instead of one way, doesn't change much.

nwh5jg56df• 3 years ago

what is the other way?

dishsoap2• 3 years ago

https://source.android.com/docs/security/features/verifiedbo...

https://source.android.com/docs/core/ota/sign_builds

fidotron• 3 years ago

The elephant in the room, for Google and Microsoft, is verifiable security is worthless if no one actually trusts the organization that released the verified firmware.

Android should be have been split off from Google a long time ago.

judge20203• 3 years ago

If you're using Pixel with stock OS, you trust them anyways - it's about making sure your phone hasn't been tampered with by another party.

benatkin4• 3 years ago

It doesn't mean that, it just means you selected it out of the available options.

fulafel• 3 years ago

Trust isn't binary, there are several dimensions and varying levels of trust along those.

pkaye• 3 years ago

And who would fund that version of Android?

pshirshov2• 3 years ago

That sounds like a nothingburger. The bootloader always shows a warning if the image isn't signed by Google.

Google itself should be able to sign whatever code they want and mount whatever attack they want.

Could someone explain if this provides any value over signature check in the bootloader?

I believe that the bootloader can't be updated with a non-Google-signed version. And if there is a vulnerability and a malicious actor does that there would be no way to safely get the hash to verify against the log.

michaelt• 3 years ago

Could someone explain if this provides any value over signature check in the bootloader?

If every release has its checksum entered into an immutable log, and can't be installed if it's not in the log, it makes it somewhat detectable if someone infiltrates, tricks or forces Google into signing a backdoored version for a targeted attack.

It's unlikely anyone would infiltrate Google to make a custom-signed image to target me - but if you were Obama or Trump or Snowden or Khashoggi you might be worried about that.

I say "somewhat detectable" because if there was an unexplained signed update logged, Google could just say "sorry, bug/misclick/new guy" and that'd sound plausible to a lot of us.

pshirshov2• 3 years ago

if there was an unexplained signed update logged, Google could just say "sorry, bug/misclick/new guy" and that'd sound plausible to a lot of us.

Precisely. And, practically, you won't be able to audit such update, at least audit it quickly. Even if you find some malicious code they can always blame it to a rogue engineer.

1vuio0pswjnm74• 3 years ago

Hypothetical: Computer owner modifies software to make it more secure. Google falsely declares computer is now less secure.

Who should win the argument and why.

(Note: Google is not the owner of the computer in this hypothetical.)

candiddevmike• 3 years ago

Neither. The security profile is the same, device is still used or managed by a human, and (most?) humans hate rubber hoses.

(Therefore all security should be based on the users preferences, as you can't protect a user 24/7)

hedora• 3 years ago

Being more secure for Google and [ad-/tracking-supported] app-vendors is more-or-less independent of being more secure for computer owners.

If some change happens to benefit both groups, I assume it's a happy coincidence. I like to think that most Google employees try to implement win-win stuff like that, but it's pretty clear that they frequently worsen user security/privacy to improve their bottom line (nearly all their revenue comes from spying on people, and preventing them from effectively opting out).

verytrivial• 3 years ago

Presumably there's something special about ro.boot.vbmeta.digest that would prevent a malicious ROM from lying about it? As in the ADB protocol being served by literal ROM code?

marcjuul• 3 years ago

Yeah this seems to be a fairly important missing piece. Is there some special boot mode with a ROM-hosted unmodifiable adb?

teaearlgraycold6• 3 years ago

That value comes from the firmware and is not writable by Android. As for whether the daisy-chain of strcpy() calls are robust, and without a rich history of 0-days, that is something I don't know.

grishka• 3 years ago

That value comes from the firmware and is not writable by Android.

But it's returned to the host by adbd that's part of Android. What's stopping someone from creating a modified adbd that would lie about this value?

megraf• 3 years ago

Call me a skeptic, but I see this as political theater. If Google themselves wanted to peek-at-you, they would never have to look as deep as the firmware. If a _foreign_ government wanted to, and they could 'poison the well' this obviously helps.

I feel like this is part of Apple's cover story for excessive serialization 'we just want to make sure the parts in your phone are the parts we own'.

1vuio0pswjnm74• 3 years ago

This is how the Jargon File defines "malware":

   malware
    n.

[Common] Malicious software. Software intended to cause consequences the unwitting user would not choose; especially used of {virus} or {Trojan horse} software.

What if a program installed by Google causes consequences the user would not choose. For example, "Google Play" or Chrome.

Google has been fined 4.125 billion euros because it forces computer manufacturers to install these programs by agreement. Imagine if Google had to pay computer owners (ad targets) not to modify/remove the spyware.

https://ec.europa.eu/competition/antitrust/cases/dec_docs/40...

https://curia.europa.eu/jcms/upload/docs/application/pdf/202...

https://theplatformlaw.blog/2022/10/03/general-court-largely...

https://www.clearygottlieb.com/news-and-insights/publication...

Also in India, Google was fined for these agreements.

https://pib.gov.in/PressReleseDetailm.aspx?PRID=1869748

https://www.thehindu.com/sci-tech/technology/indias-antitrus...

https://indianexpress.com/article/technology/tech-news-techn...

https://www.bqprime.com/business/google-loses-appeal-against...

Also in South Korea, Google was fined for these agreements.

https://www.reuters.com/technology/skorean-antitrust-agency-...

https://www.aljazeera.com/economy/2021/9/14/south-korea-fine...

Projects exist to remove the spyware, so-called "de-Googled" Android. Clearly some computer owners would not choose these programs.

These are "witting users" under the malware definition.

Proponents of Google's practices will sometimes argue that witting users, e.g., people commenting on HN of their dissatisfaction with Google's practices, are not relevant. Only the "majority" is relevant. They will frequently use the phrase "most people".

However, these are "unwitting users" according to the malware definition. They are not "choosing" Google Play or other Google spyware pre-installed on their computers. Rather, they are not presented with a choice.

"Millions of users trust Google." Well, considering Google pays other companies to pre-install their software on millions of computers and to set the default search to Google, that's not surprising. We are all forced to "trust" the things we cannot change. What other choice do we have.

thorncorona• 3 years ago

People buy Android phones with the expectation of using the play store to install applications lol

temac• 3 years ago

> Google has been fined 4.125 billion euros because it forces computer manufacturers to install these programs by agreement.
People buy Android phones with the expectation of using the play store to install applications lol

Maybe the people having decided that fine did not thought about that and the corresponding lol-factor.

pizzalife2• 3 years ago

This is cool for Pixels, but the problem with the Android ecosystem is that most people are running customized OS images from the manufacturer (Samsung, Huawei etc). These images will also frequently contain insecure bloatware from telcos that can't be installed.

saltyoutburst• 3 years ago

* ...can't be _un_installed

pizzalife2• 3 years ago

Yes, ty

jmprspret• 3 years ago

Agreed. This really is the biggest issue in regard to security consistency on Android-based phones. It's really quite a shame.

Personally, I use Pixel devices and install GrapheneOS on them.

xg15• 3 years ago

The details page [1] of the transparency log explains the exact threat model that they are trying to address with this:

Transparency systems can be used to detect—and thus deter—supply chain attacks. Let's address some examples:

Suppose an attacker maliciously modifies a Pixel image and even manages to sign it with the key that Google owns. Anyone who receives the malicious image can query the binary transparency log to verify the image's authenticity. The user will find that Google has not added the corresponding image metadata to the log and will know not to trust the compromised image. Since publishing to the log is a separate process from the release process with signing, this raises the bar for the attacker beyond just compromising the key.

So effectively, this seems to secure against malicious actors messing with Google's (or AOSP's) own build process, i.e. by somehow inserting an MITM between the build and the signing stage.

I don't know how Google's or AOSP's build systems are set up, but I'd suspect that not many entities are able to mount a successful supply chain attack on internal networks. So (conspiracy hat on), I wonder if there is something more behind this, i.e. some recent hacking incident or a warning of one.

[1] https://developers.google.com/android/binary_transparency/ov...

codethief3• 3 years ago

I don't know how Google's or AOSP's build systems are set up, but I'd suspect that not many entities are able to mount a successful supply chain attack on internal networks.

This classic article might be worth your while:

https://medium.com/@alex.birsan/dependency-confusion-4a5d60f...

piecerough• 3 years ago

Too bad it's paywall'ed

saagarjha• 3 years ago

It’s much better than that.

anon84873628• 3 years ago

Maybe just lessons learned from SolarWinds

confiq2• 3 years ago

for those who don't know: https://en.wikipedia.org/wiki/2020_United_States_federal_gov...

userbinator• 3 years ago

I wonder if there is something more behind this, i.e. some recent hacking incident or a warning of one.

They may just be trying to get people to "trust" them more.

Remember that according to Google and the rest of Big Tech, "malicious actors" also includes the user.

mjg59• 3 years ago

One option is that it's not Google protecting you against Google, it's Google attempting to drive other Android vendors towards the same infrastructure in order to protect users against vendors being compelled to produce targeted backdoored firmware images.

confiq2• 3 years ago

not only that, but it also protects you from law enforcement or any state actor.

This mainly protects journalists and human right lawyers. I think this is the idea here after NGO shitstorm.

biogene• 3 years ago

Pixel Binary Transparency responds to a new wave of attacks targeting the software supply chain—that is, attacks on software while in transit to users. These attacks are on the rise in recent years, likely in part because of the enormous impact they can have.

They say its "on the rise", but the linked report in the blog talks about transient OSS dependencies (among other related things), and not binary/firmware level tampering. Can someone explain how this would help avoid the Log4j vulnerability?

benatkin4• 3 years ago

So the phone has none of Google's spyware on it? Finally, a secure phone! /s

predictabl3• 3 years ago

SMH at the lack of though or understanding some ppl have for layered device security...

This has an obvious clear benefit: all of the people who have said "oh well Google could be compelled to sign a malicious update for a single user"... This is an attempt at solving that via a transparency log.

Granted, I think for this to matter much all-up, it would need to apply to PSF, Apex, general app updates, etc.... Which I'm pretty sure this doesn't even attempt to touch.

I'd love to hear Google speak to that but that seems like a huge can of worms compared to the image based hashing, signing, verification that is already part of the tooling, ecosystem and consciousness.

kats• 3 years ago

This is awesome and a great job by google's android/pixel devs.

amluto4• 3 years ago

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.

combat-banana• 3 years ago

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.

muppetman• 3 years ago

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"

eru2• 3 years ago

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.)

mszcz• 3 years ago

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...

xvector• 3 years ago

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

amluto4• 3 years ago

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.

1vuio0pswjnm74• 3 years ago

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.

teaearlgraycold6• 3 years ago

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

sollewitt• 3 years ago

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.

teaearlgraycold6• 3 years ago

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.

zimmerfrei• 3 years ago

> 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?

Osiris2• 3 years ago

My concern is over e-waste. If it becomes impossible to install custom firmware on a device then a lot of electronics will just become garbage when support ends or the company disappears.

pptr• 3 years ago

How many people actually extend the lifetime of their phone via custom firmware? I imagine most people with old phones simply continue using their devices after support ends.

paulryanrogers• 3 years ago

I used to do this for as long as the batteries and soldered flash would last. Though I've given up trusting randos on XDA devs and fiddling with ROMs to keep everything working.

FrostKiwi2• 3 years ago

I used the OnePlus One way past its EOL. Replaced battery and screen multiple times, custom ROMs based on linageOS tuned by the community to revive important features like RAW, 60s Shutter Speed and introduce some new ones not unlocked by the OEM, like manual focus. This included firmware modifications of various subsystems to improve the QoL, like introducing Stereo Playback via the speaker and tuning the Speaker curves to sound acceptable.

There is a lot that can be done and there is a lot that people do.

indymike• 3 years ago

More people would do this if it was easier to do.

realusername2• 3 years ago

That's kind of a circular reasoning, nobody uses them because Google and manufacturer made them as inconvenient as possible.

amluto4• 3 years ago

This is firmware verification done right: it lets you verify that you have Google firmware, but it does not force you to run Google firmware.

Vogtinator• 3 years ago

Yeah, but it's enforced to run stock firmware in other ways. SafetyNet for once.

Having mechanisms like this in place unfortunately makes it easier for others to abuse them for DRM.

1MachineElf2• 3 years ago

Recently I developed a presentation* about immutability as a design concept in computer security. As part of it, I have slides which cover Certificate Transparency implementation[0], which uses Trillian[1] as a distributed ledger. Part of Trillian's documentation includes a Firmware Transparency[2] example. For the year or so I've been aware of it, I've thought that it's a great idea, and wondered if it would ever grow as a project/practice. Digging through the links in this announcement, it appears Trillian is the basis for the distributed ledger here. Glad to see the idea has been taken further by Google!

* Sorry, the presentation is non-public.

[0] https://certificate.transparency.dev/

[1] https://transparency.dev/

[2] https://github.com/google/trillian-examples/tree/master/bina...

Haemm0r• 3 years ago

Am I getting old if for me Trillian is an instant-messaging app? 0o

1MachineElf2• 3 years ago

You're not alone. My initial reaction was the same.

walteweiss• 3 years ago

Yeah, it was irc or icq something, like 15 years ago :)

sneak• 3 years ago

I wonder how much of the inspiration for these append-only merkle trees of attestations came from blockchains.

We now have certificate transparency and also this that work this way. They seem to be direct logical descendants.

pravus• 3 years ago

I think it could be argued that the basic form of this was around as X.509 certificates far before blockchains. I'm not sure what the history would be before that, though.

Also, in my mind at least, the idea for doing secure attestable history comes from git. Once you have a crypto-DAG it's a fairly easy transition into other data structures although ordering becomes an issue with trees. I'm almost sure something else must have existed because it's not a far leap to a crypto-DAG when you are doing things like HMAC.

stiray• 3 years ago

Well, any security aware owner of Pixel phone is already on GrapheneOS, not only to be protected from attacks but also to be protected from Google itself. So I dont consider this as some huge benefit.

https://grapheneos.org/features

Pixel Binary Transparency: verifiable security for Pixel devices

Related Stories