Mark Android SafetyNet attestation as deprecated.

[agl]

Google have announced the deprecation of SafetyNet in general, and specifically for WebAuthn.

This change adds a note in the SafetyNet section that it may be removed in a future revision of the spec.

---

Preview | Diff

[Firehed]

Is there any word on how this may impact re-verifying existing attestations (as noted in the credential record section)?

Given the nature of the upstream changes there's probably not much actionable here, though it may be worth keeping the procedure documented and adjust the messaging to indicate deprecation without removal.

[agl]

Is there any word on how this may impact re-verifying existing attestations (as noted in the credential record section)?

SafetyNet involves a server-side call to validate, I think? In which case revalidation won't be possible once the SafetyNet service is shutdown.

[timcappalli]

@Firehed I don't believe the credential record definition says anything about re-validating an attestation after a registration ceremony, it just states that it can be referenced. So I don't think this will be an issue.

[emlun]

@timcappalli credential record/attestationClientDataJSON says:

Storing this in combination with the above attestationObject item enables the Relying Party to re-verify the attestation signature at a later time.

---

SafetyNet involves a server-side call to validate, I think?

The verification procedure in WebAuthn doesn't require any in-procedure server call, the attestation statement is self-contained. It might no longer be possible to obtain the root certificate of the attestation trust chain, though.

Does SafetyNet have a single root certificate, or at least a small number of them? If so, then maybe we could inline it (them) in the WebAuthn spec as a way to keep attestation signatures verifiable.

Also, our links to "the steps indicated by the SafetyNet online documentation" no longer lead to the verification steps, but instead to a page describing the deprecation timeline. Is there some way we can still access the verification steps so that we could inline them into WebAuthn (I'm not sure we should, just wondering if we can)?

[MasterKale]

Does SafetyNet have a single root certificate, or at least a small number of them? If so, then maybe we could inline it (them) in the WebAuthn spec as a way to keep attestation signatures verifiable.

The certificate labeled "GlobalSign Root CA" as downloaded from https://pki.goog/roots.pem should still be valid through 2028-01-28 @ 04:00 PST for verifying SafetyNet attestation certificate chains:

# Operating CA: GlobalSign
# Issuer: CN=GlobalSign Root CA O=GlobalSign nv-sa OU=Root CA
# Subject: CN=GlobalSign Root CA O=GlobalSign nv-sa OU=Root CA
# Label: "GlobalSign Root CA"
# Serial: 4835703278459707669005204
# MD5 Fingerprint: 3e:45:52:15:09:51:92:e1:b7:5d:37:9f:b1:87:29:8a
# SHA1 Fingerprint: b1:bc:96:8b:d4:f4:9d:62:2a:a8:9a:81:f2:15:01:52:a4:1d:82:9c
# SHA256 Fingerprint: eb:d4:10:40:e4:bb:3e:c7:42:c9:e3:81:d3:1e:f2:a4:1a:48:b6:68:5c:96:e7:ce:f3:c1:df:6c:d4:33:1c:99
-----BEGIN CERTIFICATE-----
MIIDdTCCAl2gAwIBAgILBAAAAAABFUtaw5QwDQYJKoZIhvcNAQEFBQAwVzELMAkG
A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv
b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05ODA5MDExMjAw
MDBaFw0yODAxMjgxMjAwMDBaMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i
YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT
aWduIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaDuaZ
jc6j40+Kfvvxi4Mla+pIH/EqsLmVEQS98GPR4mdmzxzdzxtIK+6NiY6arymAZavp
xy0Sy6scTHAHoT0KMM0VjU/43dSMUBUc71DuxC73/OlS8pF94G3VNTCOXkNz8kHp
1Wrjsok6Vjk4bwY8iGlbKk3Fp1S4bInMm/k8yuX9ifUSPJJ4ltbcdG6TRGHRjcdG
snUOhugZitVtbNV4FpWi6cgKOOvyJBNPc1STE4U6G7weNLWLBYy5d4ux2x8gkasJ
U26Qzns3dLlwR5EiUWMWea6xrkEmCMgZK9FGqkjWZCrXgzT/LCrBbBlDSgeF59N8
9iFo7+ryUp9/k5DPAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E
BTADAQH/MB0GA1UdDgQWBBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0B
AQUFAAOCAQEA1nPnfE920I2/7LqivjTFKDK1fPxsnCwrvQmeU79rXqoRSLblCKOz
yj1hTdNGCbM+w6DjY1Ub8rrvrTnhQ7k4o+YviiY776BQVvnGCv04zcQLcFGUl5gE
38NflNUVyRRBnMRddWQVDf9VMOyGj/8N7yy5Y0b2qvzfvGn9LhJIZJrglfCm7ymP
AbEVtQwdpf5pLGkkeB6zpxxxYu7KyJesF12KwvhHhm4qxFYxldBniYUr+WymXUad
DKqC5JlR3XC321Y9YeRq4VzW9v493kHMB65jUr9TU/Qr6cf9tveCX4XSQRjbgbME
HMUfpIBvFSDJ3gyICh3WZlXi/EjJKSZp4A==
-----END CERTIFICATE-----

[MasterKale]

Also, our links to "the steps indicated by the SafetyNet online documentation" no longer lead to the verification steps, but instead to a page describing the deprecation timeline. Is there some way we can still access the verification steps so that we could inline them into WebAuthn (I'm not sure we should, just wondering if we can)?

As for this, we might have to fall back to consulting existing verification implementations in WebAuthn libraries. For what it's worth, here's mine:

https://github.com/MasterKale/SimpleWebAuthn/blob/dc70416e781c9ab11625ba9afbf092809391874e/packages/server/src/registration/verifications/verifyAttestationAndroidSafetyNet.ts#L15

I'd link to py_webauthn's implementation but it's pretty much the same. I'm sure other libraries can be used to independently verify the logic if we wanted to map it to spec speak.

[MasterKale]

Might there be a way instead to leverage the IANA registry to maintain links to whatever validation logic and root certs are needed for maintaining support for SafetyNet? Enshrining vendor-specific attestation statement formats in the spec after they're being deprecated feels wrong...

[Firehed]

I found the current spec for SafetyNet attestation verification pretty woefully deficient as it is, even before the link broke and moved to the deprecation timeline (in fact, I'm pretty sure I referenced yours @MasterKale since Google's docs were leading me in circles).

IMO retaining the procedure in the spec, even after deprecation, is fine - if not ideal. apple is also completely unused now AFAIK since they've stripped attestation data for passkeys in iCloud Keychain and only use the none format[^1]. Having the actual certs in a registry of some kind seems reasonable (I'd also consider the FIDO metadata service as a candidate). So long as RPs maintain the timestamp of the credential registration, they should have no trouble checking that the attestation was valid at the time.

[^1]: If anyone knows this not to be the case, I'd love to learn what situation the apple format is still used by!

[MasterKale]

Here's a Wayback Machine link to a version of SafetyNet statement verification logic from July 28, 2023:

https://web.archive.org/web/20230728190311/https://developer.android.com/training/safetynet/attestation

It's a little too native-app-centric for our context here; for example there's no indication in there that in WebAuthn nonce bytes will be a concatenation of authData bytes and the SHA-256 hash of clientDataJSON bytes. However there's probably enough guidance on things like the use of JWS and the structure of PAYLOAD to help get RPs most of the way there.