search

wultra / powerauth-mobile-sdk

PowerAuth mobile SDK adds capability for authentication and transaction signing into the mobile apps (iOS, tvOS, watchOS, Android).
https://www.wultra.com/product/wultra-mobile-security-suite/
Apache License 2.0
33 stars 13 forks source link

Biometry not working when system biometry set changes #259

Closed kober32 closed 4 years ago

kober32 commented 4 years ago

When user adds another finger for unlocking his phone, it invalidates the current keystore value and makes the biometry factor not working.

This is probably due to a policy specified in https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setInvalidatedByBiometricEnrollment(boolean)

kober32 commented 4 years ago

After discussion with @petrdvorak, this should be false by default and configurable in SDK for developers who want such a feature.

petrdvorak commented 4 years ago

Just a quick comment from my side: The original intended behavior on Android 6 was keeping the key on adding a new biometry element. This was to avoid disabling biometry to the end-user who might not expect it. I do not have a strong option for either way, though. Let's make this option visible in the documentation and highlight it in release notes.

hvge commented 4 years ago

I'll implement that configuration as #260. Then I'll take a look at this particular problem, why the removed key is not detected in the SDK properly.

hvge commented 4 years ago

This issue is specific for our Samsung testing device (Galaxy A5 - SM-A520F, Android 8.0). Normally, when the biometric enrollment is changed, our code fails at getting the key in BiometricAuthentication.prepareSecretKey(). This device has unfortunately a slightly different behavior. The key is provided as usual, then the user is able to authenticate via the legacy authentication dialog and then, finally, the failure happens in attempt to derive our cryptographic key, in FingerprintAuthenticator.protectKeyWithCipher().

We have to change our code to handle also this kind of situations. I guess that this failure may happen also in the new, BiometricPrompt based code. We simply cannot trust the vendor's implementation here.