- From: Daniel Micay via GitHub <sysbot+gh@w3.org>
- Date: Thu, 20 Apr 2023 00:51:15 +0000
- To: public-webauthn@w3.org
@arnar Android key attestation has an older approach based on either a provisioned batch key (unprivileged apps) or unique key (privileged OS components only). The batch keys were to avoid leaking a unique identifier. This was replaced with remote key provisioning and is deployed in production on Pixels. https://android-developers.googleblog.com/2022/03/upgrading-android-attestation-remote.html Key attestation has support for more than only Google certified operating systems and is an API that can also be implemented by non-Google-certified devices with their own attestation roots. GrapheneOS uses key attestation as the basis for our Auditor app and https://attestation.app/ service. We use a pinning-based approach and we requested better support from this from Google which was introduced in Android 12 and first shipped on Pixels in the form of apps being able to generate keys with the attest purpose, which can only be used for signing attestations. This allowed us to continue using a pinning-based approach after the move to remotely provisioned keys, since there is no longer a batch key reused across all apps on the device and across at least 100k other devices. There was the option to use the unique key as a privileged OS component, but having per-pairing keys is a much nicer approach. SafetyNet Attestation API is obsolete and is being removed in the near future. It was replaced with the Play Integrity API. The only reason to use either the legacy SafetyNet Attestation API or the Play Integrity API is if you want weak, easy to bypass software checks used for their basic/device verification. Their strong verification mode is based on key attestation but doesn't provide most of the information and other capabilities it offers. If you only care about hardware verification, why not use the standard Android Open Source Project API? I doubt you care about more than attestation for the fact that keys are hardware backed in which case even the strong verification from SafetyNet or Play Integrity doesn't really do what you need, and the non-strong one certainly doesn't since it's not hardware attestation and is trivially bypassed via spoofing. Many people are bypassing it via spoofing practice. The attestation data has support for verifying alternate operating systems via the yellow verified boot state + verified boot key fingerprint provided in the attestation. Doesn't seem to be relevant to this but it's quite useful. If you drop support for key attestation, you should be aware that you're dropping support for anything but Google certified Android operating systems which rules out using it with an OS like GrapheneOS. If anything, why don't you remove support for completely insecure and essentially useful software-based attestation which unnecessarily requires having Google Play and a Google certified OS even though the underlying hardware-based API works fine with an alternate OS for verifying hardware keystore properties and even supports verifying an alternate OS (don't think that's in scope for this since the hardware keystore handles everything, but it's relevant elsewhere). -- GitHub Notification of comment by thestinger Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1819#issuecomment-1515558510 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 20 April 2023 00:51:17 UTC