You can root GrapheneOS just fine. Moreover you can even re-lock the bootloader after rooting.

See: github.com/chenxiaolong/avbroot

As described in the README, the combination of root access and locking the bootloader has the caveat that it's easy to brick your boot partition by accidentally making changes to it. That causes the signature check to fail, and then you have to unlock the bootloader and wipe all your data to re-flash it.

I don't know if there's any good solution to this, since all this seems to be necessary for the security model.

EDIT: Wait, isn't this what A/B partitions are for? (ie, you can brick one partition and still boot from the other) Also, shouldn't it be possible to flash an image signed with the correct keys without unlocking the bootloader and wiping the user data?

	▲	strcat 2 days ago \| parent [-]
		It also has the caveat that protecting against privileged attacker persistence doesn't work by definition, so it only provides protection against physical attacks. The protection against physical attacks is also reduced through having the keys available on a lower security device as would typically be the case.

▲

tarruda 2 days ago | parent | prev [-]

After unlocking and then re-locking, will the phone still pass all necessary attestations to be able to use things like Google wallet and banking apps?

▲

strcat 2 days ago | parent | next [-]

You can use most banking apps on GrapheneOS but a subset block using any alternate OS. GrapheneOS supports hardware attestation and some banking apps explicitly permit GrapheneOS via hardware attestation such as Swissquote which recently added it. Banking app compatibility on GrapheneOS is better than any other alternate OS due to some apps choosing to special case allowing it.

Google will not using their service for tap-to-pay.

▲

tarruda 2 days ago | parent [-]

My only concern is this: Android phones I tried to root so far will be "tainted" if I unlock the bootloader and can never go back to a state where it passes all checks.

I'm okay with losing access to Google wallet while using Graphene os (I can just use plain old credit cards), but I would like to have the option to revert it in the future.

▲

strcat 10 hours ago | parent | next [-]

> My only concern is this: Android phones I tried to root so far will be "tainted" if I unlock the bootloader and can never go back to a state where it passes all checks.

There's no such thing for Pixels, and it also doesn't void the manufacturer warranty.

▲

scrlk 2 days ago | parent | prev [-]

Pixel devices don't have anything like the Samsung Knox eFuse, which blows after running a third-party bootloader.

▲

j4hdufd8 2 days ago | parent [-]

Where are you getting this information? For what it is worth, Wikipedia mentions the Pixel 6 on the eFuse page https://en.wikipedia.org/wiki/EFuse

Myself I have not reverse engineered the Titan M2 security chip, but surely it uses eFuse or OTP memory for anti rollback protection mechanisms and such.

These are really basic hardware security primitives. I'm curious why you're under the impression Pixels wouldn't use eFuse.

▲

Andromxda 2 days ago | parent | next [-]

> For what it is worth, Wikipedia mentions the Pixel 6 on the eFuse page https://en.wikipedia.org/wiki/EFuse

The Pixel 6 is only mentioned in regards to anti-rollback protection. This has nothing to do with unlocking and later relocking the bootloader. Pixels have always supported relocking the bootloader with a custom root of trust, i.e. custom AVB signing keys used by a custom, user-installed operating system.

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

▲

j4hdufd8 2 days ago | parent [-]

The Pixel 6 is mentioned specifically about eFuses which is the technical detail that caught my attention in this thread.

> The Xbox 360, Nintendo Switch, Pixel 6 and Samsung Galaxy S22 are known for using eFuses this way.[8]

Anti-rollback protection is a security feature, eFuses are hardware primitives that can be used to implement it. Bootloader locking is another security feature that can be implemented with eFuses.

If you have any data denying the use of eFuses in the Pixel 6, please share it, that is what I was interested in this sub-thread. I really did not understand the relevance and the correctness of your comment.

	▲	Andromxda 15 hours ago \| parent [-]
		I had the same misunderstanding of your comment, as this other commenter https://news.ycombinator.com/item?id=45256978 I thought you claimed that Pixels also used eFuses to disable certain features after unlocking the bootloder once, like Samsung devices do. That's why I pointed out that Pixel devices have always had support for relocking the bootloader with a custom root of trust. Your response to this comment https://news.ycombinator.com/item?id=45244933 made it seem that way, because you appeared to disagree that "Pixel devices don't have anything like the Samsung Knox eFuse, which blows after running a third-party bootloader". I guess that was a misunderstanding.

▲

scrlk a day ago | parent | prev [-]

You mentioned devices being irreversibly "tainted" after unlocking the bootloader.

On Samsung devices, blowing the Knox eFuse permanently disables features tied to Knox (e.g. Samsung Pay, Secure Folder). ("can never go back to a state where it passes all checks")

Pixels do not have an equivalent eFuse that permanently disables features (discounting the ability to flash previous versions of Android). Restoring stock firmware and relocking the bootloader will give you a normal Pixel.

	▲	j4hdufd8 20 hours ago \| parent [-]
		I was purely focusing on whether or not it uses eFuses, literally, which it 100% absolutely does. I was not making any other such claims. Indeed it may be true today that "restoring stock firmware and relocking the bootloader will give you a normal Pixel", I completely understand what you mean. But that is NOT the same thing as "Pixels do not have eFuses to flag devices that have been modified before". Please share data supporting this claim if you have it. It is possible that existing Pixels have such eFuses that internally flag your device (perhaps bubbling up to the Google Play Integrity APIs) but they don't kill device features per Google's good will. My question is 100% about the hardware inside the Titan M2 and how it is used by Google. I don't think the answer is public, and anyone who has reverse engineered it to such detail won't share the answer either.

▲

chuckadams 2 days ago | parent | prev [-]

Google Pay has never worked on GrapheneOS. GOS supports the attestation API -- a superset of it in fact -- but unless banking apps and Google Pay add GrapheneOS's keys specifically, they're not going to work, locked bootloader or no.

(Google Wallet runs fine for storing cards and tickets and whatnot, you just can't pay with it)

▲

strcat 2 days ago | parent | next [-]

Most banking apps don't disallow GrapheneOS. A growing subset are banning using any alternate OS including GrapheneOS, but there's also progress on convincing those apps to permit GrapheneOS via hardware attestation. Most banking apps do work.

▲

sterlind 2 days ago | parent | prev [-]

it'd be really nice to exert pressure on GPay or at least banking apps to add GOS's keys. accepting only Google's keys is anticompetitive.

	▲	strcat a day ago \| parent [-]
		Most banking apps permit GrapheneOS. We estimate around 10% ban it via the Play Integrity API, which is gradually increasing. The good news is that around a dozen banking apps have added explicit support for GrapheneOS. Swissquote recently implemented it via hardware attestation to check the GrapheneOS verified boot keys per https://grapheneos.org/articles/attestation-compatibility-gu....