David Zeuthen

It's possible some folks are saying that but at least in ISO (where we wrote ISO 18013-5), OpenID Foundation (for OpenID4VP protocol to exchange credentials), and W3C (for the DC API), a lot of these problems are being discussed and protocols designed to mitigate them. For example, relay protection

In both cases, the device needs to have _some_ kind of secure area running immutable code. For the ISO mdoc case, to prevent the user from cloning the credential and ditto for the other case. So in general some trust is needed (from e.g. device manufacturer) and can be broken over time, of course

That said, it's not the only way to do age verification. As a counter-example imagine a piece of software on your phone which counts the number of wrinkles in your face, running in a secure enclave so you can trust it does this correctly (incl secure camera). This can get close and no gov involved.

Government-issued ID can indeed by used for age verification and things like the 3-party model used in e.g. ISO 18013-5 does provide a secure and privacy-preserving way of presenting these credentials, especially when combined with Longfellow, which helps solve the issuer-RP collusion problem.

👀

The situation over here is so messed up 😭

DevicePolicyManager  |  Android Developers

Sounds like this would be useful to add to the attestation, yeah. We'd likely need to limit this to Profile Owner and Device Owner to match the semantics of developer.android.com/reference/an...

OK, yea, I see. Looks like the new "enrollment-specific ID" is the replacement and the problem is that this isn't present in the Android Keystore attestation. I wonder if that's just an oversight. Not sure it'd help much as it would be a SW-enforced field if we were to add this. Shawn, thoughts?

(Actually, I think the chains are actually length 1 in this case, not 2. But the point remains the same, the AttestKey functionality provides a way to prove two keys exist in the same Secure Hardware, specifically the same device.)

... similarly when you create the other key (alias "OK") do the same. The chains for "ID" and "OK" will be of length 2 and for both the root cert is the public key for "AK". This proves "ID" and "OK" is on the same device. Isn't this what you wanted?

Full circle? My original suggestion was to use Attest Key for this: create an AttestKey with alias "AK", this key will have a full standard attestation chain, chaining up to Google's root. Then when you create the key for ID attestation (alias "ID") call setAttestKeyAlias(alias "AK") and ...

Pretty sure that what was removed was the ability to get IMEI from the Key Attestation and it's still in ID Attestation. What I'm saying here is that Key Attest functionality can bind the two together which should solve your problem.

I see. So you're saying the problem is that the IMEI is never attested to since Android 12 even when using ID attestation? I'm not sure that's accurate (but also haven't checked) and certainly conflicts with the information in source.android.com/docs/securit... mentioning multiple IMEI in Android 14

Hi @mjg59.eicar-test-file.zip with regards to mjg59.dreamwidth.org/70630.html I believe Attest Key functionality - see developer.android.com/reference/an... - can be used if you want proof that two keys exist in the same Secure Hardware. Cc @shawnwillden.bsky.social