27 ms·
Pixel Binary Transparency: verifiable security for Pixel devices
- WirelessGigabit 3y agoPretty soon Android will be as locked down as Android.
- Chabsff 3y agoPerhaps, but this has little to do with it. In what scenario is user-auditable traceability of firmware images anything but a good thing?
- Gh0stRAT 3y agoIt already is
- Vt71fcAqt7 3y agoI think we're well past that point ;)
- mschuster91 3y agoI 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 3y agoPart of the issue there is that they’re focused on the 99% of users who aren’t flashing firmware onto their phones.
- JohnFen 3y agoThis is probably the largest (but far from the only) reason why I'm ditching smartphones entirely.
- sznio 3y agoIt's the corporations that get to trust your device. You get nothing.
- londons_explore 3y 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.
- dishsoap 3y agoSeems 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 3y agowhat is the other way?
- dishsoap 3y agohttps://source.android.com/docs/security/features/verifiedboot https://source.android.com/docs/security/features/verifiedbo... https://source.android.com/docs/core/ota/sign_builds https://source.android.com/docs/core/ota/sign_builds
- fidotron 3y agoThe 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 3y agoIf 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 3y agoIt doesn't mean that, it just means you selected it out of the available options.
- judge2020 3y agoHow does this relate to verifying that the software running is the same as what google ships to everyone?
- benatkin 3y agoI'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 3y agoIf you don't trust them, why verify the integrity of the software blob they ship with their hardware at all?
- spencerflem 3y agothat was the point of the original comment
- pshirshov 3y agoThat 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 3y 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.
- biini 3y ago[flagged]
- pshirshov 3y 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.
- realusername 3y ago> Even if you find some malicious code they can always blame it to a rogue engineer. And good luck finding anything with something as big as an android rom...
- 1vuio0pswjnm7 3y agoHypothetical: 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 3y agoNeither. 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 3y agoBeing 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 3y agoPresumably 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 3y agoYeah this seems to be a fairly important missing piece. Is there some special boot mode with a ROM-hosted unmodifiable adb?
- teaearlgraycold 3y agoThat 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 3y 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?
- teaearlgraycold 3y agoI don't know that much about the security model. But I think if you really want to verify device integrity you should use an attestation key. That is supposed to be un-spoofable (although bugs can still occur in any software, which would defeat the integrity guarantees).
- megraf 3y agoCall 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'.
- 1vuio0pswjnm7 3y agoThis 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/40099/40099_9993_3.pdf https://ec.europa.eu/competition/antitrust/cases/dec_docs/40... https://curia.europa.eu/jcms/upload/docs/application/pdf/2022-09/cp220147en.pdf https://curia.europa.eu/jcms/upload/docs/application/pdf/202... https://theplatformlaw.blog/2022/10/03/general-court-largely-upholds-the-commissions-decision-in-google-android-case-t-604-18/ https://theplatformlaw.blog/2022/10/03/general-court-largely... https://www.clearygottlieb.com/news-and-insights/publication-listing/general-court-partially-annuls-european-commission-decision-in-google-android 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://pib.gov.in/PressReleseDetailm.aspx?PRID=1869748 https://www.thehindu.com/sci-tech/technology/indias-antitrust-regulators-orders-on-google-are-rushed-legal-expert-says/article66156418.ece https://www.thehindu.com/sci-tech/technology/indias-antitrus... https://indianexpress.com/article/technology/tech-news-technology/google-rs-1337-penalty-upheld-nclat-8525993/ https://indianexpress.com/article/technology/tech-news-techn... https://www.bqprime.com/business/google-loses-appeal-against-competition-regulator 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-fines-google-177-mln-abusing-market-dominance-2021-09-14/ https://www.reuters.com/technology/skorean-antitrust-agency-... https://www.aljazeera.com/economy/2021/9/14/south-korea-fines-google-for-abusing-its-dominant-position 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.
- pizzalife 3y agoThis 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 3y ago* ...can't be _un_installed
- pizzalife 3y agoYes, ty
- jmprspret 3y agoAgreed. 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 3y agoThe 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/overview?hl=en https://developers.google.com/android/binary_transparency/ov...
- codethief 3y 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-4a5d60fec610 https://medium.com/@alex.birsan/dependency-confusion-4a5d60f...
- piecerough 3y agoToo bad it's paywall'ed
- codethief 3y agoHere you go, it wasn't always like that: https://web.archive.org/web/20210227105146/https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610 https://web.archive.org/web/20210227105146/https://medium.co... :)
- biogene 3y 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?
- benatkin 3y agoSo the phone has none of Google's spyware on it? Finally, a secure phone! /s
- predictabl3 3y agoSMH 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 3y agoThis is awesome and a great job by google's android/pixel devs.
- deleted 3y ago[deleted]
- amluto 3y agoOn 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 3y agoIt 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 3y agoThere'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"
- Osiris 3y agoMy 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 3y agoHow 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 3y agoI 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.
- FrostKiwi 3y agoI 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.
- fomine3 3y agoThat's only enthusiast do in developed world. I'm curious does poorer people in developing world uses alternative ROMs. Is there any store that supports ROM flashing?
- FrostKiwi 3y agoWe'll never be able to judge that from the POV of our fast moving first world tech sphere and it's one-time use consumerism. That makes it all the more important to keep those options and avenues of modification not only alive, but strong. As individuals we can of course offer mere anecdotal evidence. Coming from Belarus, I can say that the amount of talented hackers repurposing old tech was always strong there, though I don't have a strong connection there anymore. I recently covered the QuadCore mod for ancient thinkpads and the firmware replacement that entails: https://youtu.be/Fs4GjDiOie8 https://youtu.be/Fs4GjDiOie8 I received multiple requests on Details and Walking through individuals performing similar upgrades from Latin America. To me, the spirit for reviving trash grade tech to our modern sensibilities is alive and well.
- deleted 3y ago[deleted]
- 1MachineElf 3y agoRecently 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/ https://certificate.transparency.dev/ [1] https://transparency.dev/ https://transparency.dev/ [2] https://github.com/google/trillian-examples/tree/master/binary_transparency/firmware https://github.com/google/trillian-examples/tree/master/bina...
- Haemm0r 3y agoAm I getting old if for me Trillian is an instant-messaging app? 0o
- 1MachineElf 3y agoYou're not alone. My initial reaction was the same.
- walteweiss 3y agoYeah, it was irc or icq something, like 15 years ago :)
- sneak 3y agoI 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 3y agoI 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 3y agoWell, 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 https://grapheneos.org/features