crowbahr
While I'm limited in the amount of details I can share I can say that we're requiring MEETS_STRONG_INTEGRITY for our sensitive actions. I appreciate the API checker output for your GOS device - that's good to see. Having a PLAY_RECOGNIZED verdict along with the build number and sha256 of the build are all part of the required checks. It looks like you'd only be failed for the MEETS_STRONG_INTEGRITY check - which is what I'd expect.
The entire purpose of the strong integrity level is that it uses the hardware key attestation API in a very weak way not using or enforcing most of what's provided such as a reasonable patch level.
The hardware key attestation API provides a signed result including the app's package name, version code and signing key fingerprints. That's how you're meant to chain trust to the app with it, and it's done by our Auditor app provided as an example.
For the MEETS_STRONG_INTEGRITY portion obviously there are issues on Android SDK <= 32 where the Strong verdict is returned purely based on hardware boot integrity with no recent security patch requirements. We're monitoring how this goes to see if we still have issues with camera spoofing on those devices, in which case we'll lock all SDK <= 32 out of the sensitive actions in app.
It allows being out-of-date by up to a whole year for recent devices and indefinitely for older devices. The key attestation API provides the patch levels signed by the hardware for you to enforce what you want. You can use the hardware key attestation API to verify any stock OS including patch levels too through the green boot state. It doesn't mean that this is a useful thing to do, but it's more useful than the Play Integrity API strong integrity level.
Again I'm trying not to dox myself here but we're a luxury product and we deal with PII so we have to take customer data very, very seriously. The security review on these kind of changes might take over a month on its own. So it's a not inconsiderable headache to support this when the Google Play API covers 99.999% of our customers, most of whom are nowhere near tech savvy enough to install a custom rom, and Security signs off on that for free since it's as simple as having the device perform the check then sending the token off to Google on our backend and getting a verdict. No chains to look into, it uses the existing GCM project etc etc.
GrapheneOS is not a custom ROM. That's an inaccurate term and shouldn't be used to refer to it.
The hardware key attestation API is the official Android API for this and it's not that hard to use it.
Play Integrity API is rate limited and doesn't always work so it adds reliability issues to an app. The hardware key attestation API has no rate limits.
Play Integrity API device integrity level is easily bypassed and the strong integrity level is simply supplementing that with the key attestation API and very incomplete, lax checks for patch level.
THAT SAID - It sounds like I could add the attestation key certificate chain into the attestation step up and just have the server check that in the case that the device fails STRONG_INTEGRITY, allowing only the GrapheneOS boot key fingerprints. Where do you post revocation status btw? Is it in the Google maintained list?
They're Google certified devices with the Google key attestation root keys and therefore the Google maintained revocations are the relevant ones. With our own hardware, we could have our own key attestation root, our own remote key provisioning and our own revocation list but that's not relevant right now.
You can use key attestation to verify the stock OS and your app on any device launched with Android 8 or later including checking patch levels. You can check your app's integrity via the key attestation metadata for the package name, version code and signing key fingerprints. The attestation is for a hardware backed key which can then be used to sign messages including gathering more data in your app and sending it in a signed message to prove it came from the app since the OS doesn't allow anything else to use the key.
You're meant to tie login sessions to hardware keystore keys with attestation enabled. You can also generate attest purpose keys for signing attestations of other keys.