Allow identification of the microG implementation with AAGUID

[restena-sw]

Is your feature request related to a problem? Please describe. Our company policy allows only specific FIDO2 authenticators. I could try to get my FP3 microG FIDO2 token whitelisted, but that requires that the server can actually identify microG. Right now, while supporting attestation in principle, microG sends the AAGUID "00000000000000000000000000000000" which it shares with the rest of the (not FIDO certified) world. So I don't even have a handle to request whitelisting.

Describe the solution you'd like During a FIDO2 registration ceremony, microG should send a unique (made-up, but static) AAGUID. The corresponding attestation should be backed up at least with the attestation level "Self" (the attestation is signed with the private key itself, no external dependencies).

Describe alternatives you've considered The alternative is to not use my e/OS/ phone inside company contexts.

Additional context The attestation mode "Self" for attestations is specified in https://www.w3.org/TR/webauthn-2/#sctn-packed-attestation (need to produce only "alg" and "sig", no x5c).

If the build team were to maintain a self-signed CA to sign the (canned) attestation assertion during build time, microG could even provide an attestation on level "Basic" (signing with that X.509 certificate).

[mar-v-in]

microG already (since version 0.2.25 / commit 304c3522e992a3db641411fd21df4088db579dad) supports attestation using the Android Key attestation format when run on Android 7.0 or newer. Additionally, we also support the Android SafetyNet attesstation format on older Android versions if SafetyNet is passed. In both cases, the AAGUID b93fd961-f2e6-462f-b122-82002247de78 is used, which is the AAGUID for Android Authenticators (the same used by original Google Play Services).

However, this only applies when attestation is requested. If your WebAuthn or FIDO API client does not request attestation (i.e. when the attestation field in PublicKeyCredentialCreationOptions is set to none or unset), microG will use AAGUID set to 16 zero bytes. This is in line with the recommendations from the WebAuthn specification.

[restena-sw]

Thanks, that's how it should be indeed. But it's weird... I was testing with attestation: 'direct' but got the all-zeroes back. I am using 0.2.27 though. Could this be related to SafetyNet not passing (CTS profile mismatch)? Here is the pertinent creation options array in use:

var passwordlessPublicKeyCredentialCreationOptions = {
    publicKey: {
        challenge: ...
        rp: {
            name: "...",
            id: "...",
        },
        user: {
            id: ...,
            name: ...,
            displayName: ...,
        },
        pubKeyCredParams: [{alg: -7, type: 'public-key'},{alg: -257, type: 'public-key'}],
        authenticatorSelection: {
            requireResidentKey: true,
            residentKey: "required",
            userVerification: "required",
            credProtect: "userVerificationRequired",
        },
        timeout: 60000,
        attestation: 'direct',
        extensions: {
            credProps: true,
            credProtect: {
                credentialProtectionPolicy: "userVerificationRequired",
                enforceCredentialProtectionPolicy: true
            }
        }
    }
};

[restena-sw]

BTW, the requireResidentKey / residentKey options are ignored - the registration ceremony succeeds, but the result indicates no resident key was set.

Shouldn't the registration ceremony /fail/ instead, if the residentKey can not be created?

[mar-v-in]

What browser and browser version are you using in your tests? Have you tried with other browsers?

[restena-sw]

That's Firefox 111.1.1 from the e/OS/ 1.9-s app store. Maybe it doesn't support attestation? But then I'd expect the browser itself to not even trigger the registration...? If you can suggest a browser where this is expected to work, happy to try.

[mar-v-in]

Last time I checked, Firefox Android implementation of WebAuthn was very incomplete and they ignored and didn't forward half of the details from the request to microG, so it could well be the problem here. Chromium-based browsers that aren't built without WebAuthn support are much more likely to work correctly.

[restena-sw]

I now tested Samsung Internet app, with android-key attestation turned on and verified. For non-resident credentials, I get a working registration ceremony, with the expected AAGUID.

Trying a UV registration and requesting resident keys makes the browser fail verbosely.

So this is pretty much expected if resident keys aren't supported.

Will install Firefox again (meanwhile on a Murena FP5 with A13), maybe the situation has changed.