1175
Motorola's 2027 flagships will officially support GrapheneOS (www.gsmarena.com)
submitted 2 months ago by to c/technology@lemmy.world
192 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 2 points 2 months ago (5 children)

You believe GrapheneOS is not able protect against Motorola?

Um yes? How do you protect against someone who literally controls the hardware?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 6 points 2 months ago (4 children)

    Ask GrapheneOS. Thats literally their mission.

    Device support

    Devices are carefully chosen based on their merits rather than the project aiming to have broad device support. Broad device support is counter to the aims of the project, and the project will eventually be engaging in hardware and firmware level improvements rather than only offering suggestions and bug reports upstream for those areas. Much of the work on the project involves changes that are specific to different devices, and officially supported devices are the ones targeted by most of this ongoing work.

    Hardware, firmware and software specific to devices like drivers play a huge role in the overall security of a device. The goal of the project is not to slightly improve some aspects of insecure devices and supporting a broad set of devices would be directly counter to the values of the project. A lot of the low-level work also ends up being fairly tied to the hardware.

    Non-exhaustive list of requirements for future devices, which are standards met or exceeded by current Pixel devices:

    • Support for using alternate operating systems including full hardware security functionality
    • Complete monthly Android Security Bulletin patches without any regular delays longer than a week for device support code (firmware, drivers and HALs)
    • At least 5 years of updates from launch for device support code with phones (Pixels now have 7) and 7 years with tablets
    • Device support code updated to new monthly, quarterly and yearly releases of AOSP within several months to provide new security improvements (Pixels receive these in the month they're released)
    • Linux 6.1, 6.6 or 6.12 Generic Kernel Image (GKI) support
    • Hardware accelerated virtualization usable by GrapheneOS (ideally pKVM to match Pixels but another usable implementation may be acceptable)
    • Hardware memory tagging (ARM MTE or equivalent)
    • Hardware-based coarse grained Control Flow Integrity (CFI) for baseline coverage where type-based CFI isn't used or can't be deployed (BTI/PAC, CET IBT or equivalent)
    • PXN, SMEP or equivalent
    • PAN, SMAP or equivalent
    • Isolated radios (cellular, Wi-Fi, Bluetooth, NFC, etc.), GPU, SSD, media encode and decode, image processor and other components
    • Support for A/B updates of both the firmware and OS images with automatic rollback if the initial boot fails one or more times
    • Verified boot with rollback protection for firmware
    • Verified boot with rollback protection for the OS (Android Verified Boot)
    • Verified boot key fingerprint for yellow boot state displayed with a secure hash (non-truncated SHA-256 or better)
    • StrongBox keystore provided by secure element
    • Hardware key attestation support for the StrongBox keystore
    • Attest key support for hardware key attestation to provide pinning support
    • Weaver disk encryption key derivation throttling provided by secure element
    • Insider attack resistance for updates to the secure element (Owner user authentication required before updates are accepted)
    • Inline disk encryption acceleration with wrapped key support
    • 64-bit-only device support code
    • Wi-Fi anonymity support including MAC address randomization, probe sequence number randomization and no other leaked identifiers
    • Support for disabling USB data and also USB as a whole at a hardware level in the USB controller
    • Reset attack mitigation for firmware-based boot modes such as fastboot mode zeroing memory left over from the OS and delaying opening up attack surface such as USB functionality until that's completed
    • Debugging features such as JTAG or serial debugging must be inaccessible while the device is locked

    In order to support a device, the appropriate resources also need to be available and dedicated towards it. Releases for each supported device need to be robust and stable, with all standard functionality working properly and testing for each of the releases.

    The expectation is for people to buy a secure device meeting our requirements to run GrapheneOS. Broad device support would imply mainly supporting very badly secured devices unable to support our features. It would also take a substantial amount of resources away from our work on privacy and security, especially since a lot of it is closely tied to the hardware such as the USB-C port control and fixing or working around memory corruption bugs uncovered by our features. We plan to partner with OEMs to have devices produced meeting all our requirements, providing additional privacy/security features beyond them and ideally shipping with GrapheneOS rather than massively lowering our standards.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 2 months ago* (3 children)

    That's all very nice but not many of us are willing to buy a $1000 phone (or an obsolete Pixel) to get Graphene. They soon won't be able to run it on new Pixels, and also the stuff about AOSP updates stops mattering since AOSP itself is nearly dead. The obsession with security chips (fighting the seized phone attack while comparatively ignoring much more relevant threats) is another misplaced priority. It's the old notion of "fence post security", putting a 100 foot fence post in the middle of the desert expecting the attacker to try to climb over it instead of going around it.^1^ And again, I'm amused at the idea of the US and Chinese governments allowing a Motorola (Lenovo) Graphene to be sold if it's really that secure.

    We need a de-googled Android fork (maybe Lineage is that) on mass market phones using the hardware that those phones have. Otherwise we're acquiescing to the notion that Elon Musk deserves more privacy than Joe Schmoe when it should be the other way around.

    ^1^ hpmor.com chapter 115.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 2 months ago (2 children)

    That's all very nice but not many of us are willing to buy a $1000 phone (or an obsolete Pixel) to get Graphene.

    Pixel "a" series phones typically sell for under $500 and support GrapheneOS.

    They soon won't be able to run it on new Pixels, and also the stuff about AOSP updates stops mattering since AOSP itself is nearly dead.

    Source for this?

    The obsession with security chips (fighting the seized phone attack while comparatively ignoring much more relevant threats) is another misplaced priority. It's the old notion of "fence post security", putting a 100 foot fence post in the middle of the desert expecting the attacker to try to climb over it instead of going around it.1

    The obsession with security chips is what allows Pixels and iPhones to be the most secure devices on the planet. They have some of the most researched technologies being used here. You're literally just throwing it away based on...your link to a harry potter book? Seriously, look at the source you just shared. Its not even relevant 😂

    And again, I'm amused at the idea of the US and Chinese governments allowing a Motorola (Lenovo) Graphene to be sold if it's really that secure.

    What are they going to do, ban security chips like they tried to ban encryption in the 90s?

    We need a de-googled Android fork (maybe Lineage is that) on mass market phones using the hardware that those phones have. Otherwise we're acquiescing to the notion that Elon Musk deserves more privacy than Joe Schmoe when it should be the other way around.

    GrapheneOS and LineageOS are already degoogled.... LineageOS is extremely subpar when it comes to security since they dont enforce it onto their hardware. GrapheneOS actually enforces it and wont work unless it has those specific security features. LineageOS doesnt solve the problem you were concerned about in your post.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 months ago (1 child)

    Source for this?

    This is a start: https://grapheneos.social/@GrapheneOS/117140352254892456

    The obsession with security chips is what allows Pixels and iPhones to be the most secure devices on the planet.

    I remember the govt trying to muscle Apple into unlocking someone's iphone, til they suddenly stopped because they found Cellebrite could unlock it instead. There have been several new iphone generations since then but I haven't heard about govt muscling anytime recently. So I have to infer they can still unlock iphones. As for Pixels, this is in Dutch but very recent: https://www.omroepbrabant.nl/nieuws/6023856/drievoudige-moord-in-oosterhout-telefoon-van-verdachte-gekraakt

    Machine translation of main paragraphs:

    The Netherlands Forensic Institute (NFI) has unlocked the Google Pixel phone belonging to 29-year-old Veronica K., according to the prosecutor. "A large number of images of weapons and stacks of cash were found on her phone. There are also a large number of chat messages that can now be read." K. is alleged to have facilitated the murder by supporting the perpetrators.

    The prosecutor expects to receive the first results from the NFI on Thursday. During the hearing, the prosecutor also said there is good reason to hope that the NFI will be able to unlock the Google Pixel phones belonging to the other two suspects as well.

    So I think you're putting too much faith in this stuff. I will ask my crypto homies if they have any recent info about phone attacks though.

    More relevantly, most secure devices AGAINST WHAT? You're talking about a locked phone attack which is the absolute least of most users' worries. The phone is so insecure in everyday use that the border patrol is near irrelevant. Plus users including paranoids like me don't have any opsec to speak of. When was the last time you crossed a border with an Android phone anyway? I don't think I've ever done that. Like most people I don't leave the country that often. Last time I did was before I switched to Android, IIRC. I might have had an analog or 2G flip phone or something. If I travel somewhere again it's not that big a deal to leave my Android phone at home, as I mentioned before.

    Even in the border patrol picture, Graphene and TPM won't protect you from what used to be called rubber-hose cryptanalysis (xkcd.com/538). They're defending from the wrong threat.

    Look, I understand the advantages of crypto hardware. I've programmed it and written simulators for it. But, the way to really keep cryptography in people's hands is to make it not require special hardware. Thus I'm skeptical that the government hates Graphene, but it really did hate PGP back in the day.

    If I get to add new hardware to phones, TPM would be on my list but not at the top. First might be something like POCSAG (plus build out the pager network again) so you can receive text messages without transmitting anything or revealing your location. Second, third, etc. would be in a similar vein.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 2 months ago

    Your TPM concern here...

    If I get to add new hardware to phones, TPM would be on my list but not at the top. First might be something like POCSAG (plus build out the pager network again) so you can receive text messages without transmitting anything or revealing your location. Second, third, etc. would be in a similar vein.

    ...is literally addressed in your post here:

    This is a start: https://grapheneos.social/@GrapheneOS/117140352254892456

    They mention all the secure enclave type of stuff needed. They have the verified boot. They have the MTP. Its all there.

    As for Pixels, this is in Dutch but very recent: https://www.omroepbrabant.nl/nieuws/6023856/drievoudige-moord-in-oosterhout-telefoon-van-verdachte-gekraakt

    Were they using GrapheneOS?

    Also, keep in mind that Cellebrite slides were leaked and they show that they arent able to tap into GrapheneOS on modern Pixel devices.

    https://www.androidauthority.com/cellebrite-leak-google-pixel-grapheneos-security-platform

    Until GrapheneOS breaks away from AOSP, which they have mentioned they could potentially do so once they have a solid hardware platform, we seem to at least be in a good place where even the DoJ is upset about people using GrapheneOS.

    https://www.theguardian.com/us-news/2026/jul/23/cop-city-protester-phone

  • permalink
  • fedilink
  • source
  • parent