[HN Gopher] Google Pixel Binary Transparency: verifiable securit...
___________________________________________________________________
Google Pixel Binary Transparency: verifiable security for Pixel
devices
Author : transpute
Score : 76 points
Date : 2023-08-21 20:12 UTC (2 hours ago)
(HTM) web link (security.googleblog.com)
(TXT) w3m dump (security.googleblog.com)
| WirelessGigabit wrote:
| Pretty soon Android will be as locked down as Android.
| Gh0stRAT wrote:
| It already is
| Vt71fcAqt7 wrote:
| I think we're well past that point ;)
| Chabsff wrote:
| Perhaps, but this has little to do with it.
|
| In what scenario is user-auditable traceability of firmware
| images anything but a good thing?
| biogene wrote:
| >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?
| mschuster91 wrote:
| 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.
| DistractionRect wrote:
| 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...
| londons_explore wrote:
| > 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.
| e2le wrote:
| >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.
| figmert wrote:
| > Mr Evil
|
| Erm, it's Dr. Evil to you sir.
| mschuster91 wrote:
| > 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.
| [deleted]
| canttestthis wrote:
| Tamper-proof packaging is a poor replacement for a first-
| time boot replacement warning. Not to mention the sheer
| impracticality of properly implementing tamper proof
| packaging (the factory would have to cover the packaging in
| shiny nail polish or something, encrypt and send a high-res
| picture of that somehow to the final buyer across the
| supply chain, at which point the final buyer makes sure the
| glitters align). Much better to do it the way it's
| currently done
| vlakreeh wrote:
| If a repair shops wipes someone's phone they'll be pissed,
| but they aren't going to throw out the phone. As soon as
| they get back that phone they'll reinstall all their apps
| and log back into all their accounts and any malicious
| firmware added by that repair shop will wreak havoc.
|
| I 100% agree that we should have ways of getting rid of
| these warnings on our own devices, but this isn't a simple
| problem.
| Terr_ wrote:
| > If a repair shops wipes someone's phone they'll be
| pissed, but they aren't going to throw out the phone. As
| soon as they get back that phone they'll reinstall all
| their apps [...]
|
| This depends on whether consumers are made aware that a
| repair shop that "accidentally" wipes your phone might be
| trying to steal your bank account etc.
|
| While education is difficult, the consumer has an
| advantage in this scenario because the event itself is
| impossible to miss and very disruptive and could lead
| them to start searching on the internet for advice.
| carbotaniuman wrote:
| Apple frequently tells customers that their data would be
| wiped if they send their devices in for repair, I don't
| see why customers would challenge a repair shops
| assertion - it doesn't seem implausible either!
| Terr_ wrote:
| I guess the lesson is/would-be less "all resets are signs
| of nefarious intent" and more like "if _seems_ reset,
| always reset it again yourself to be safe. "
| sudosysgen wrote:
| 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.
| devit wrote:
| 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.
| codethief wrote:
| Your phone will still display a warning during bootup,
| though.
| Waterluvian wrote:
| Part of the issue there is that they're focused on the 99% of
| users who aren't flashing firmware onto their phones.
| JohnFen wrote:
| This is probably the largest (but far from the only) reason why
| I'm ditching smartphones entirely.
| sznio wrote:
| It's the corporations that get to trust your device. You get
| nothing.
| megraf wrote:
| 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'.
| predictabl3 wrote:
| 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.
| dishsoap wrote:
| 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 wrote:
| what is the other way?
| fidotron wrote:
| 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.
| judge2020 wrote:
| 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.
| benatkin wrote:
| It doesn't mean that, it just means you selected it out of
| the available options.
| judge2020 wrote:
| How does this relate to verifying that the software running
| is the same as what google ships to everyone?
| benatkin wrote:
| I'm responding to "you trust them anyways"
|
| How does using a device mean you trust the vendors?
|
| That's wrong. It's like saying you trust your governor
| because you live in a particular U. S. state.
| judge2020 wrote:
| If you don't trust them, why verify the integrity of the
| software blob they ship with their hardware at all?
| [deleted]
| 1vuio0pswjnm7 wrote:
| 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://www.thehindu.com/sci-tech/technology/indias-antitrus...
|
| https://indianexpress.com/article/technology/tech-news-techn...
|
| 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" accoording 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 wrote:
| People buy Android phones with the expectation of using the
| play store to install applications lol
| temac wrote:
| > > 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.
| benatkin wrote:
| So the phone has none of Google's spyware on it? Finally, a
| secure phone! /s
| pshirshov wrote:
| 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 wrote:
| _> 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.
| pizzalife wrote:
| 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.
| jmprspret wrote:
| 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.
| saltyoutburst wrote:
| * ...can't be _un_installed
| 1vuio0pswjnm7 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Yeah this seems to be a fairly important missing piece. Is
| there some special boot mode with a ROM-hosted unmodifiable
| adb?
| xg15 wrote:
| 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...
| codethief wrote:
| > 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 wrote:
| Too bad it's paywall'ed
___________________________________________________________________
(page generated 2023-08-21 23:00 UTC)