Android: Hardware-backed attestation API support

[alohapersona]

I'm a bit unsure what this row is about. The description says it's a a mandatory feature for all devices shipping with Android 8 or higher. I am using LineageOS on a device that shipped with Android 8 or higher and I can verify using the Key Attestation Demo app that hardware-backed attestation is available on my device (here specifically it will reveal that my bootloader is unlocked, but it still works as intended).

If it depends only on the device, why is it in this table at all? If it depends on bootloader locking and verified boot (as those are revealed via the attestation results), that's essentially the same as the "Verified boot" row.

There's also the "Hardware-based security verification" row, which I'm not referring to here, but where I also have a question: On GrapheneOS, it's referring to the great Auditor app. On Stock it's saying "mandatory since Android 8" - but I haven't seen a feature similar to the Auditor app on any Stock Android. Maybe this got mixed up with the hardware attestation API?

[eylenburg]

"Hardware-based security verification" is indeed meant to refer to the Auditor app. Basically, a way to check that you're running an untampered OS.

"Hardware-backed attestation API support" mainly refers to this guide which contains the verified boot key fingerprints so that app developers can use it for e.g. their banking app. I'm not aware of any others (e.g. LineageOS) having such a guide. But I guess it's not really a matter of API support so the row would need to be renamed.

[thestinger]

Auditor is currently only supported by GrapheneOS and the stock Pixel OS. Other operating systems haven't asked to have support added. We plan to extend it with generic support for stock operating systems on other devices but haven't gotten to that and it's problematic that many devices are missing features it uses and have older versions of KeyMint and attestation. We want to phase our legacy functionality from it.

Supporting hardware-based verification via attestation requires properly supporting verified boot which means more than locking the device but rather properly verifying all of the OS through it. Being able to use the hardware attestation API to see that the device is unlocked or to verify part of the OS without the rest of the OS being verified isn't actual support for it.

[alohapersona]

which contains the verified boot key fingerprints so that app developers can use it

Well, it contains it in a format that is not machine-readable, meaning app developers would need to manually extract it from the page and then also regularly keep an eye on the page (for when e.g. new devices are added).

I mean, it's nice to have a page and so on, but is that really a feature of the OS itself or rather a documentation matter. I agree GrapheneOS documentation is significantly more detailed than those of the other Android-based OS, so maybe "Documentation quality" could become a point on its own (though hard to measure in hard numbers I guess).

Being able to use the hardware attestation API to see that the device is unlocked or to verify part of the OS without the rest of the OS being verified isn't actual support for it.

I would typically say an API is supported when it returns the result expected, no? What else than hardware supporting it and full Verified Boot (which is already covered by a separate row) is needed for support in your opinion?

[thestinger]

Well, it contains it in a format that is not machine-readable, meaning app developers would need to manually extract it from the page and then also regularly keep an eye on the page (for when e.g. new devices are added).

I mean, it's nice to have a page and so on, but is that really a feature of the OS itself or rather a documentation matter. I agree GrapheneOS documentation is significantly more detailed than those of the other Android-based OS, so maybe "Documentation quality" could become a point on its own (though hard to measure in hard numbers I guess).

HTML is a machine readable format and doesn't prevent providing data in a way that's formally structured for extraction by a tool. We haven't formally specified how to extract it but providing a JSON file wouldn't have guarantees on the format not changing either. We plan to provide a signed JSON file with the key fingerprints. The entry in the table isn't there because key fingerprints are provided but rather because hardware attestation is supported and Auditor can be used by end users to monitor device security. Auditor can also be used with the stock Pixel OS. It can't be used with operating systems not providing this functionality. It could be expanded to more devices but we haven't received help with it and there are various issues with how hardware attestation is implemented elsewhere. The entry in the table isn't about documentation.

I would typically say an API is supported when it returns the result expected, no? What else than hardware supporting it and full Verified Boot (which is already covered by a separate row) is needed for support in your opinion?

It's a separate feature from verified boot. Verified boot being present doesn't imply attestation is working. GrapheneOS has better support for both verified boot and attestation than the stock Pixel OS due to various improvements which have been made. As an example, not using chained vbmeta means attestation provides a hash of the entire OS for GrapheneOS which it doesn't do for the stock Pixel OS. In order for attestation to work, there needs to be support for key provisioning and other functionality. GrapheneOS hosts a proxy for key provisioning and for future GrapheneOS hardware we'll have to host a service for it ourselves.

[alohapersona]

Auditor can be used by end users to monitor device security

As I said in the beginning, Auditor is a separate thing, covered by "Hardware-based security verification" row. Let's ignore it for now and focus on the aspect "Hardware-backed attestation API" row. If those two rows mean exactly the same, that's also fine (because it means one can just remove one of them), but if they're not, then we have to make sure it's clear what sets them apart.

We plan to provide a signed JSON file with the key fingerprints.

That's nice to hear.

support for key provisioning [...] GrapheneOS hosts a proxy for key provisioning

There is a column for "Hardware attestation provisioning" already, exactly stating that GrapheneOS has a proxy and everyone else is using Google. Which to me implies that everyone else does indeed have key provisioning as well, no?

Verified boot being present doesn't imply attestation is working.

I assumed so far from your previous message, but it doesn't answer my question, which literally was "What else than hardware supporting it and full Verified Boot (which is already covered by a separate row) is needed for support in your opinion?"

If I use the Key Attestation API on my GrapheneOS device, it will show the verified boot key (as listed on GrapheneOS website, just using base64 instead of hex), correct boot loader lock state and a bunch of device and version information. Doing the same on my LineageOS with unlocked bootloader shows a similar result, except that the boot key is zeroed out and bootloader shown as unlocked, which is exactly as expected.

Now my question is: If I was to do the same on a CalyxOS (I don't have one and this is also not meant as a suggestion to install it) with locked bootloader, will it look exactly like on GrapheneOS except for the different boot key of course?