4 ms·

You can root GrapheneOS just fine. Moreover you can even re-lock the bootloader after rooting. See: github.com/chenxiaolong/avbroot

tarruda 1y ago
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?
- chuckadams 1y ago
  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 1y ago
    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 1y ago
    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 1y ago
      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-guide https://grapheneos.org/articles/attestation-compatibility-gu....
- strcat 1y ago
  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 1y ago
    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.
    - scrlk 1y ago
      Pixel devices don't have anything like the Samsung Knox eFuse, which blows after running a third-party bootloader.
      - j4hdufd8 1y ago
        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 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 1y ago
        > For what it is worth, Wikipedia mentions the Pixel 6 on the eFuse page https://en.wikipedia.org/wiki/EFuse 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/verifiedboot/boot-flow#locked-devices-with-custom-root-of-trust https://source.android.com/docs/security/features/verifiedbo...
felurx 1y ago
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 1y ago
  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 1y ago

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?

chuckadams 1y ago
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 1y ago
  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 1y ago
  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 1y ago
    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-guide https://grapheneos.org/articles/attestation-compatibility-gu....
strcat 1y ago
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 1y ago
  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.
  - scrlk 1y ago
    Pixel devices don't have anything like the Samsung Knox eFuse, which blows after running a third-party bootloader.
    - j4hdufd8 1y ago
      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 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 1y ago
        > For what it is worth, Wikipedia mentions the Pixel 6 on the eFuse page https://en.wikipedia.org/wiki/EFuse 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/verifiedboot/boot-flow#locked-devices-with-custom-root-of-trust https://source.android.com/docs/security/features/verifiedbo...

felurx 1y ago

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 1y ago
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.