Clarify SafetyNet / Play Integrity row

[D3SOX]

I was wondering why it says Yes for CalyxOS as I'm running the latest build on my Pixel 8 Pro and I get neither SafetyNet nor Play Integrity.

Do you mean Basic Integrity here? If yes I think the field should be split up into

• SafetyNet basic integrity
• CTS Profile match
• Play Integrity

As far as I know it's not possible to fully pass both on a custom ROM without using something like Magisk and a module that fixes it (not sure about Graphene)

[eylenburg]

I think you're right. The table needs to be changed because it's not as compatible as stock Android.

For GrapheneOS [1] it says that only basicIntegrity is passed although it doesn't mention Play Integrity here but only Safetynet.

For microG I believe it's the same (only basicIntegrity) and the additional issue that Play Integrity depends on the Play Store? [2] [3] [4] [5] [6]

What would you propose is the right way to show it?

	GrapheneOS Play Services	MicroG	MicroG + root
SafetyNet basic integrity	OK	OK	OK
CTS Profile match	No	No	OK ???
Play Integrity	No	???	???

I don't have any personal experience because I don't use either Play Services or microG.

[matchboxbananasynergy]

SafetyNet is obsolete and has been replaced by Play Integrity API. SafetyNet is largely no longer relevant. GrapheneOS passes MEETS_BASIC_INTEGRITY, but not MEETS_DEVICE_INTEGRITY or MEETS_STRONG_INTEGRITY, as that requires a Google-certified OS.

[eylenburg]

Thank you @matchboxbananasynergy

Do you know if that's the same for microG?

[matchboxbananasynergy]

I know that it can't pass MEETS_DEVICE_INTEGRITY or MEETS_STRONG_INTEGRITY on devices not running a Google-certified OS unless you spoof, which can pass one of the two, but not in a way that will be possible for a long time.

I don't think microG makes any such spoofing attempts. Regarding MEETS_BASIC_INTEGRITY, I don't know how that is handled and it might depend on factors outside of microG's control too.

[matchboxbananasynergy]

By the way, I am against adding information about "root" or magisk modules regarding spoofing this. It's not robust, it's being cracked down, and will cease being possible no matter what people do soon. In addition to that, rooting destroys the Android security model; it's not a valid approach.

[eylenburg]

I agree. I just updated the row to saw "passes only basic integrity" in light green. The only one exception being Stock Android of course.

[ale5000-git]

I haven't tried it but I don't think it is impossible to pass strong integrity (but only if it is done directly by ROM authors).

For ROMs that spoof original details (like model, device, fingerprint, etc.) but also Kernel version strings, and they are even able to relock the bootloader with the cutom ROM; then maybe they can pass without root and without Magisk.

[matchboxbananasynergy]

It's not possible is hardware attestation is used. Play integrity API is moving to that, and it won't be spoofable, not matter what the OS does.

[ale5000-git]

It's not possible is hardware attestation is used. Play integrity API is moving to that, and it won't be spoofable, not matter what the OS does.

If I'm not wrong hardware attestation works without any problem if the ROM relock the bootloader and don't include root or Magisk.

PS: microG in the version 0.3.6 already support Play Integrity.

[thestinger]

@ale5000-git

I haven't tried it but I don't think it is impossible to pass strong integrity (but only if it is done directly by ROM authors).

It is not possible without leaked attestation keys from exploiting a hardware keystore environment on any device.

They're operating systems, not ROMs or custom ROMs. That terminology isn't right and only makes things muddled. The technical details for this are actually important since the topic is verified boot and attestation.

For ROMs that spoof original details (like model, device, fingerprint, etc.) but also Kernel version strings, and they are even able to relock the bootloader with the cutom ROM; then maybe they can pass without root and without Magisk.

No, that's not how it works.

[ale5000-git]

Doesn't Google Pixel devices allow to relock the bootloader without the stock OS?

[thestinger]

@ale5000-git

If I'm not wrong hardware attestation works without any problem if the ROM relock the bootloader and don't include root or Magisk.

Hardware attestation works fine if the OS is properly signed and doesn't disable verified boot or the security model for it. The signed hardware attestation result shows that the device is in the SelfSigned (yellow) verified boot state where verification is done with a key flashed to the secure element or a similar approach. The hardware attestation metadata includes the OS verified boot key fingerprint which allows verifying an aftermarket OS. It will not pass Play Integrity verification unless Google decides to explicitly allow specific aftermarket operating systems based on their key fingerprints which they are not currently doing. Setting fake properties to mimic the stock OS and spoofing other things would not be required if Google decided to use hardware attestation to permit another OS. Supporting hardware attestation is in no way helpful for passing any of the integrity levels without Google deciding to permit that OS.

GrapheneOS has fully working verified boot and hardware attestation. It can be verified based on the standard Android hardware attestation API tied to the hardware keystore. We provide a guide for app developers at https://grapheneos.org/articles/attestation-compatibility-guide on how they can permit it.

[thestinger]

@ale5000-git Pixels allow flashing an alternate verified boot key to the secure element while unlocked and then locking the device to enable verified boot with support for using that key to verify an aftermarket OS. They fully support using hardware attestation to verify the OS based on it being in the SelfSigned state combined with the public key fingerprint corresponding to the key used to verify the OS successfully. This does not help with passing the Play Integrity API checks in any way. It checks for the stock OS with hardware attestation rather than an aftermarket OS with a specific verified boot key.

[ale5000-git]

It checks for the stock OS with hardware attestation rather than an aftermarket OS with a specific verified boot key.

If the OS itself spoof data of a stock OS and replace yellow with green boot-state info at boot (from apps and droidguard view without Magisk or root) and lock the boot-loader wouldn't it pass?

[thestinger]

@ale5000-git No, definitely not. The hardware keystore receives the verified boot result from the firmware boot stage which verifies the OS. The whole point of hardware attestation is that it's signing the public key certificate of a hardware backed key with metadata including the verified boot state and verified boot key included in that certificate. It's signed data from the hardware keystore. In order to produce a fake hardware attestation, you need to have leaked hardware attestation keys from exploited keystores on any other Google-certified devices. Those keys can be revoked once they detect misuse, which they can do via their fingerprinting techniques especially if the key is used on a device mismatched with what it was provisioned to. Hardware key attestation supports 2 different verification methods: 1) verification based on chaining to a valid root, 2) verification based on a pinned attest key generated in the keystore by an app. Play Integrity API can only really use the first method and that's why it's possible to bypass with leaked keys from elsewhere which also chain to the root.

[ale5000-git]

I'm not too much expert in this field but nothing is really impossible; it is just that many times isn't worth the efforts.

For example another idea is: having the untouched stock OS in the /system partition and than with an exploit during boot unload the OS and load another one in another partition under /data so that /system in untouched.
Just a rough idea, I haven't checked the feasibility and it is unlikely that I will look at it; it is just to clear the point that with enough fantasy and free time anything can be done.

[thestinger]

@ale5000-git

I'm not too much expert in this field but nothing is really impossible; it is just that many times isn't worth the efforts.

It is cryptographically signed information. You need a leaked key from exploiting a hardware keystore environment in order to sign a fake attestation. That key can be detected as being misused based on the fingerprinting and revoked if they choose to do that, although they aren't very actively trying to stop it right now.

For example another idea is: having the untouched stock OS in the /system partition and than with an exploit during boot unload the OS and load another one in another partition under /data so that /system in untouched.

Verified boot verifies every OS image. It makes sure the entire OS is completely unmodified. Exploiting the OS after it's booted via unpatched vulnerabilities is certainly possible but now you're talking about exploiting the OS. The hardware keystore provides the patch level of the OS in the signed result but the Play Integrity API is only planning to phase in a requirement of patches from 1 year ago being deployed for the strong integrity level rather than anything strict. It currently has no minimum requirement.

Just a rough idea, I haven't checked the feasibility and it is unlikely that I will look at it; it is just to clear the point that with enough fantasy and free time anything can be done.

Exploiting the hardware keystore, firmware boot chain or the OS is not spoofing but rather exploiting vulnerabilities. It's not at all the same.

[ale5000-git]

As I said it was just an example that if you cannot enter in one place from a door you can use the window, the final point is just to pass Play Integrity from the app view.
If it is real or fake it doesn't matter.

[thestinger]

The app isn't what checks Play Integrity but rather their service does if they have implemented it correctly. Otherwise, you could just modify or hook what the app is doing to bypass it with no need for any spoofing or leaked keys.