OK, I'm confused, explain how they can deliver comparable security on a hardware that does not offer the same capabilities, from a vendor who doesn't provide patches.
The hardware capability that GrapheneOS loves to use as a shield to deny support for other devices is the ability to use custom AVB keys. Without custom keys you can't relock the bootloader after installing a custom OS on most phones. The consequences of having an unlocked bootloader are that you are susceptible to an evil maid attack.
This is a real threat, but the reality is that the average person is more likely to be hacked/spied on from the software side, which Graphene would protect you from as effectively as it does on Pixel.
You have a fundamental misunderstanding of what AVB is used for.
Fully supporting and using AVB grants protection against persistence of *all* kinds. If an attacker gains privilege escalation through a remote attack, persistence become much easier if the system is not cryptographically verified every time the device boots.
Keystore and Attestation also rely on the bootloader being locked. If the hardware root of trust reports the device as untrusted, there is a broken chain of trust for biometrics, encrypted app data that uses the hardware keystore, and any form of attestation checks (like AOSP's Hardware Attestion API) will report the device as untrusted.
Going back to the first point, if it is possible to modify the system and gain persistence, there is also the possibility of modifying the kernel, which would allow an attacker to rewrite or patch the kernel, rendering AOSP's sandbox useless.
This would also make it more vulnerable to downgrade attacks because rollback protection is tied to a locked bootloader and AVB.
This could all be accomplished through remote exploitation. The "software side" you speak of is built atop AVB as a minimum requirement to assure that the software you're running is unmodified and intact.
So you're saying that being unable to prove the provenance of the image (whether it's original or not), becoming immediately exposed to downgrade attack, to someone injecting malware to /sys and you being unable to detect it.... That's not a big deal?
:)
Well, go for it, fork and "provide support" to the hardware hostile to non-stock OS, be a hero :)
Unless there is a real market advantage to it, they won't. Consumers prove over and over again they are willing to trade security to save a few dollars. Furthermore, why commit to providing hardware and software support for a device to last 5+ years, when ~25% of Americans report damaging their device each year[0]. Most of a device's population will have been replaced in 3 years.
Yeah unfortunately this is the case. Privacy and security in general are things most average consumers don’t necessarily care for, and especially don’t care for when it provides inconveniences. Even in more tech enthusiast crowds you see this reflected most obviously in people wanting to use Firefox over any Chromium variant of a browser.
Not to mention to reach GOS’ requirements the cost of the phone would have to significantly increase which I imagine only hurts Android phones even more for no real gain since GOS users are minuscule overall.
And the long term support is definitely not the norm yeah. It’s pretty much just Apple and Google doing it for their own devices. Motorola will be a newcomer to this concept with GOS. But we can only wait and see if they actually stick to it, given their track record prior to the collaboration.
Google probably got away with it cause they made the chips and security chips themselves. I read something like Tensor costing $70 vs. a Qualcomm chip with MTE costing $250.
But even with of all this, it wouldn’t make sense for GOS to spend it’s limited resources developing for a less secure platform when appropriate target devices exist (they mentioned something to this effect a few days ago on reddit too): https://www.reddit.com/r/GrapheneOS/comments/1wifsiq/comment...
They can't due to the shortcomings of the hardware (why develop a hardened os to the grossly insecure hardware) or the vendor (no/slow updates, etc).
Anyone is free to fork, add the desired hardware support and flash.
(that's aside of some Moto flagships in 2027)
they can, but don't want to
OK, I'm confused, explain how they can deliver comparable security on a hardware that does not offer the same capabilities, from a vendor who doesn't provide patches.
You say they can. How?
The hardware capability that GrapheneOS loves to use as a shield to deny support for other devices is the ability to use custom AVB keys. Without custom keys you can't relock the bootloader after installing a custom OS on most phones. The consequences of having an unlocked bootloader are that you are susceptible to an evil maid attack.
This is a real threat, but the reality is that the average person is more likely to be hacked/spied on from the software side, which Graphene would protect you from as effectively as it does on Pixel.
You have a fundamental misunderstanding of what AVB is used for.
Fully supporting and using AVB grants protection against persistence of *all* kinds. If an attacker gains privilege escalation through a remote attack, persistence become much easier if the system is not cryptographically verified every time the device boots.
Keystore and Attestation also rely on the bootloader being locked. If the hardware root of trust reports the device as untrusted, there is a broken chain of trust for biometrics, encrypted app data that uses the hardware keystore, and any form of attestation checks (like AOSP's Hardware Attestion API) will report the device as untrusted.
Going back to the first point, if it is possible to modify the system and gain persistence, there is also the possibility of modifying the kernel, which would allow an attacker to rewrite or patch the kernel, rendering AOSP's sandbox useless.
This would also make it more vulnerable to downgrade attacks because rollback protection is tied to a locked bootloader and AVB.
This could all be accomplished through remote exploitation. The "software side" you speak of is built atop AVB as a minimum requirement to assure that the software you're running is unmodified and intact.
So you're saying that being unable to prove the provenance of the image (whether it's original or not), becoming immediately exposed to downgrade attack, to someone injecting malware to /sys and you being unable to detect it.... That's not a big deal?
:)
Well, go for it, fork and "provide support" to the hardware hostile to non-stock OS, be a hero :)
hostile to non-stock OS - where are you getting this from?
If the bootloader cannot be unlocked, relocked, or doesn't provide timely updates to firmware/hardware, it's hostile.
The rest is not (might be lazy, insecure or just silly but not hostile)
It's surprising some vendors still don't support unlocking and/or relocking.
Those Razr phone updates need to start landing sooner ....
More like OEMs need to take security more seriously and add in the capable hardware and commit to firmware updates long term.
Unless there is a real market advantage to it, they won't. Consumers prove over and over again they are willing to trade security to save a few dollars. Furthermore, why commit to providing hardware and software support for a device to last 5+ years, when ~25% of Americans report damaging their device each year[0]. Most of a device's population will have been replaced in 3 years.
[0]: https://www.claimsjournal.com/news/national/2024/03/15/32248...
Yeah unfortunately this is the case. Privacy and security in general are things most average consumers don’t necessarily care for, and especially don’t care for when it provides inconveniences. Even in more tech enthusiast crowds you see this reflected most obviously in people wanting to use Firefox over any Chromium variant of a browser.
Not to mention to reach GOS’ requirements the cost of the phone would have to significantly increase which I imagine only hurts Android phones even more for no real gain since GOS users are minuscule overall.
And the long term support is definitely not the norm yeah. It’s pretty much just Apple and Google doing it for their own devices. Motorola will be a newcomer to this concept with GOS. But we can only wait and see if they actually stick to it, given their track record prior to the collaboration.
Google probably got away with it cause they made the chips and security chips themselves. I read something like Tensor costing $70 vs. a Qualcomm chip with MTE costing $250.
But even with of all this, it wouldn’t make sense for GOS to spend it’s limited resources developing for a less secure platform when appropriate target devices exist (they mentioned something to this effect a few days ago on reddit too): https://www.reddit.com/r/GrapheneOS/comments/1wifsiq/comment...