Using biometrics in Android

In order to protect privacy and sensitive data, applications often add user login capabilities. If your application uses a traditional login method, its authorization process may be similar to that shown in Figure 1: The user enters a user name and password, and the application generates device credentials based on the entered data, and then sends them to the remote server for processing Verification, after passing the verification, a userToken will be returned to the application, and then the application can use the token to query the restricted user data on the server. Whether users are required to log in every time they open the application, or only one login is required after the installation is started, the process shown in Figure 1 is applicable.

△ Figure 1: Authorization process without biometrics

However, the authorization method in Figure 1 has some drawbacks:

• If authentication is required for each independent session (such as banking applications), then this set of procedures will make users feel very cumbersome, because each time the application is opened, the password needs to be entered once;
• If the verification occurs when the app is opened after the first installation (such as a mail app), anyone who owns the device can view the private content of the device owner, because the app cannot verify whether the current user is the device owner.

In order to make up for these shortcomings, we have introduced a biometric authentication method, which provides a lot of convenience for the end user's identity verification process. Not only that, this set of technologies is also more attractive to developers, even if the business logic may not require users to log in frequently. The most critical benefit of using biometric authentication is that the entire authentication process is very short, and it only needs to tap the sensor or glance at the device to complete. As a developer, you need to determine how often your users must be re-authenticated, whether it is once a day, once a week, or every time you open the application. All in all, the API we provide encapsulates many functions, so that developers and their users can get a more friendly and convenient login experience.

Nowadays, many applications that process personal data (such as mail or social applications) often require only one-time identity verification after installation. This practice has become popular because the way in which the user name and password are required to be entered every time the application is opened has a negative impact on the user experience. But if biometric technology is used, users will no longer worry about the lack of security. Even if your application still uses one-time authentication, you can also consider regular biometric identification to verify whether it is the same user. The length of the verification period depends entirely on the developer's setting.

• If the application requires verification for each independent session (or some more frequent authentication frequency, such as once every 2 hours or once a day, etc.), then take a look at the device instead of manually entering the password for verification every time Or tapping the sensor is just a trivial operation.
• If the application only requires a one-time verification after installation (for example, mail applications), the cost of adding biometrics is only one more operation for the user to pick up the device and take a look, but it also provides more security.
• If the user wants to keep the email open without additional verification, then an option should be provided to allow this behavior.

For users who want more privacy protection, biometrics can provide additional peace of mind. Either way, compared with the increased revenue, the cost to the user is minimal.

Use BiometricPrompt API to achieve biometric recognition

Through the BiometricPrompt API, you can implement authentication with and without encryption. If your application requires stronger security (such as medical or banking applications), you may need to bind the encryption key with the biometric to verify the user's identity. Otherwise, you only need to provide biometric authentication to the user. The code implementation of the two methods is very similar, except that the CryptoObject instance is used when encryption is required.

encryption version:

biometricPrompt.authenticate(promptInfo, BiometricPrompt.CryptoObject(cipher))

In the above code, we passed the Cipher parameter to the CryptoObject. In addition, other encrypted objects are also supported, such as Mac or Signature .

does not use CryptoObject version:

biometricPrompt.authenticate(promptInfo)

To implement biometric authentication in an Android application, please use the AndroidX Biometric code library. Although the API can automatically handle different authentication levels (fingerprints, facial recognition, iris recognition, etc.), you can still use the setAllowedAuthenticators() method to set the biometric authentication level acceptable to the application, as shown in the following code. Class 3 (previously known as Strong ) The level means you want to use biometrics to unlock the credentials stored in the Keystore; Class 2 (previously known as Weak ) To unlock the application without relying on credentials protected by encryption technology for further identity verification. There is also a Class 1 class, but this class is not available in the application. For more details, please check Android compatibility definition document .

fun createPromptInfo(activity: AppCompatActivity): BiometricPrompt.PromptInfo =

   BiometricPrompt.PromptInfo.Builder().apply {

      setAllowedAuthenticators(BIOMETRIC_STRONG)
     //  继续设置其他 PromptInfo 属性，如标题、副标题、描述等。
}.build()

encryption, auth-per-use (every verification) key vs time-bound (time limit) key

auth-per-use key is a key used to perform one-time encryption operations. For example, if you want to perform 10 encryption operations, you must unlock the key 10 times. Therefore, auth-per-use means that every time the key is used, it must be authenticated (that is, the key is unlocked).

time-bound key is a key that is valid for a certain period of time. You pass a time parameter in secret seconds setUserAuthenticationValidityDurationSeconds The key needs to be unlocked again. If the time parameter value you pass is -1, which is the default value, then the system will think that you want to use the auth-per-use key. If you don't want to set it to -1 here, then we recommend that you set it to at least 3 seconds, so that the system will follow the time you set. To learn more about how to create a time-bound key, please refer to Jetpack Security about MasterKeys .

Usually, in the case of -1 mentioned earlier, you request the auth-per-use key by passing a CryptoObject parameter to the BiometricPrompt.authenticate() method. However, instead of using CryptoObject, you can set a very short time parameter (such as 5 seconds) to use the time-bound key as the auth-per-use key. These two methods are actually equivalent to verifying the identity of the user, and the choice depends on how you design the application interaction.

Let's see how these two different types of keys work: When you use CryptoObject, only a certain operation can unlock the key. This is because Keymint (or Keymaster) has acquired a HardwareAuthToken (HAT) with a specific operationId. When the key is unlocked, you can only use the key to perform operations defined as Cipher/Mac/Signature, and only once, because this is a auth-per-use key. If CryptoObject is not used, then the HAT sent to Keymint does not have an operationId. At this time, Keymint will look for a HAT with a valid timestamp (timestamp + key expiration> current time). Within the valid time, you Both can use this key because it is a time-bound key.

In this way, it seems that any application can use the time-bound key within the valid time window. But in fact, as long as the user-space is not compromised, there is no need to worry about a X application using the key or operation Y The Android framework does not allow other applications to obtain or initialize another application's operations.

summary

In this article, we introduced:

• Only the user name + password authentication method has the cause of the problem;
• Reasons for choosing to use biometric authentication in the application;
• Points to note when designing authentication methods for different types of applications;
• BiometricPrompt or without encryption enabled;
• auth-per-use and time-bound are different.

In the next article, we will show you how to reasonably integrate the biometric authentication process into the UI and business logic of the application. stay tuned!