Skip to content

Fido: Fix check for ScreenLock support - #3919

Open
p1gp1g wants to merge 1 commit into
microg:masterfrom
p1gp1g:fido/fix_biometrics_check
Open

p1gp1g wants to merge 1 commit into
microg:masterfrom
p1gp1g:fido/fix_biometrics_check

Conversation

@p1gp1g

@p1gp1g p1gp1g commented Oct 25, 2026

Copy link
Copy Markdown
Contributor

KeyguardManager.isDeviceSecure shows if the device is protected by any way but our ScreenLock key generation requires a Biometric to be configured

KeyguardManager.isDeviceSecure shows if the device is protected by any way
but our ScreenLock key generation requires a Biometric to be configured
@mar-v-in

Copy link
Copy Markdown
Member

Is it desirable that a biometric screen lock is required? IIRC, most devices and OS allow adding new biometrics (fingerprints) by entering the device password. Shouldn't we allow this to also work when users use a password for screen lock?

@p1gp1g

p1gp1g commented Oct 26, 2026

Copy link
Copy Markdown
Contributor Author

https://developer.android.com/privacy-and-security/keystore#UserAuthentication

If a key only supports biometric credentials, the key is invalidated by default whenever new biometric enrollments are added. You can configure the key to remain valid when new biometric enrollments are added. To do so, pass false into setInvalidatedByBiometricEnrollment().

I think it may be introduced as a setting, but I understand that some users prefer to keep Biometrics only

@mar-v-in

Copy link
Copy Markdown
Member

My point is that I'm pretty certain that Google's passkey implementation allows entering the screen lock PIN/password instead of using biometrics to unlock the passkey. Which makes sense given that with the lock screen pin/password you can even fetch the passkeys from the backup they send in the cloud, so would be weird to not allow that on the local device.

That is likely by using KeyProperties.AUTH_DEVICE_CREDENTIAL. Last time I checked Google also wouldn't use strongbox for passkeys, so maybe their sense of security isn't very high either, but I don't think biometrics are usually more secure than screen lock pin/password, so allowing those seems reasonable to me. We can also make that a setting of course.

@p1gp1g

p1gp1g commented Oct 26, 2026

Copy link
Copy Markdown
Contributor Author

Oh OK I see. But we can't go with a PIN in a non-backward incompatible manner, if we do that, users will lose all their keys.

So the setting is a requirement right now. It may be disabled by default, but only for new installs

@mar-v-in

Copy link
Copy Markdown
Member

Well, especially when users have not set up biometrics, it's very likely they want to go with PIN/password. And in that case isDeviceSecure is probably sufficient. The next step would probably be:

  • Add AUTH_DEVICE_CREDENTIAL when creating keys (potentially optional for users with biometrics set up)
  • Figure out what is needed when using the key

@p1gp1g

p1gp1g commented Oct 26, 2026

Copy link
Copy Markdown
Contributor Author

Are you suggesting to keep the key creation with Biometrics only if BiometricManager.from(activity).canAuthenticate(BIOMETRIC_WEAK) == BiometricManager.BIOMETRIC_SUCCESS and change to Biometrics or PIN (which would be PIN only) else ?

@mar-v-in

Copy link
Copy Markdown
Member

I would probably suggest to always do Biometrics or PIN for new keys, but I guess you can convince me to allow users to disallow use of PIN if biometrics are set up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants