To protect privacy and sensitive data, apps often add user logins. If your application uses traditional logins, its authorization process might look like figure 1: After a user enters a user name and password, the application generates a device credential based on the entered data and sends it to a remote server for verification. After verification, the application is returned with a userToken. Then the application can use the token to query the restricted user data on the server. The process shown in Figure 1 applies whether users are required to log in each time they open the application or are required to log in only once after installation starts.

△ Figure 1: Authorization process without biometrics

However, this authorization approach in Figure 1 has some drawbacks:

  • If you need to authenticate each individual session (such as a banking application), this process will be very tedious for the user, because each time you open the application, you need to enter a password.
  • If validation occurs when the application is opened after the first installation (such as a mail application), then anyone who owns the device can see the device owner’s private content because the application cannot verify that the current user is the device owner.

In order to remedy these disadvantages, we introduce biometric authentication, which provides a lot of convenience for the end user’s authentication process. Not only that, but the technology is also more attractive to developers, even though the business logic may not require frequent logins. The key benefit of using biometric authentication is that the authentication process is very short, requiring only a tap of a sensor or a glance at the device. As a developer, you need to determine how often your users must recertify, whether it’s once a day, once a week, or every time they open the app. All in all, we provide apis that encapsulate a lot of functionality to make the login experience more user-friendly for developers and their users.

Today, many applications that handle personal data, such as email or social applications, often require only one-time authentication after installation. The practice has gained popularity because the way you have to enter a username and password every time you open an app has taken a toll on the user experience. But with biometrics, users no longer worry about the lack of security. Even if your application still uses one-time authentication, consider biometrics on a regular basis to verify that you are the same user. The length of the validation cycle is entirely up to the developer.

  • If application requires every independent session need to validate (or some of the more frequent certification frequency, such as every 2 hours at a time or once a day, etc.), then compared validated manually enter a password each time, take a look at the equipment or light press sensor this way is just a minor operation.

  • If the app only needs to be verified once it’s installed (such as an email app), adding biometrics costs the user one more act of picking up the device and looking at it, but adds an additional layer of security.

  • If the user wants to be able to keep the message open without additional validation, an option should be provided to allow this behavior.

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

Use the BiometricPrompt API for biometric identification

With the BiometricPrompt API, you can authenticate with and without encryption. If your application requires greater security (for example, a medical or banking application), you may need to bind the encryption key to the biometric to verify the user’s identity. Otherwise, you simply provide biometric authentication to the user. The code implementation is similar in both ways, except that the CryptoObject instance is used when encryption is required.

Encrypted version:

biometricPrompt.authenticate(promptInfo, BiometricPrompt.CryptoObject(cipher))
Copy the code

In the code above, we pass the Cipher parameter to CryptoObject, in addition to supporting other cryptographic objects, such as using Mac or Signature.

Versions that don’t use CryptoObject:

biometricPrompt.authenticate(promptInfo)
Copy the code

To implement Biometric authentication in Android applications, use the AndroidX Biometric code base. While the API can automatically handle different levels of authentication (fingerprint, face recognition, iris recognition, etc.), you can still set the level of biometric authentication that your application will accept through the setAllowedAuthenticators() method, as shown in the code below. The Class 3 (formerly known as Strong) level indicates that you want to use biometrics to unlock credentials stored in the Keystore; The Class 2 (formerly known as Weak) level means that you only need to use biometrics to unlock the app and do not rely on cryptography to protect credentials for further authentication. There is also a Class 1 level, but this level is not available in the application. For more details, see the Android Compatibility Definition document.

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

   BiometricPrompt.PromptInfo.Builder().apply {

      setAllowedAuthenticators(BIOMETRIC_STRONG)
     // Continue to set other PromptInfo properties, such as title, subtitle, and Description.
}.build()
Copy the code

Encryption, auth-per-use (per-validation) keys vs time-bound (time-bound) keys

Auth-per-use key is a key used to perform a one-time encryption operation. For example, if you want to perform 10 encryption operations, you must unlock the key 10 times. Auth-per-use therefore means that authentication (that is, unlocking the key) must be performed every time the key is used.

Time – bound key is valid for a certain period of time the key, you through to the setUserAuthenticationValidityDurationSeconds method is passed a time parameter in seconds, after which time the key is needs to unlock again. If you pass a time parameter value of -1, which is the default, the system will assume that you want to use the Auth-per-use key. If you don’t want to set it to -1 here, we recommend that you set it to at least 3 seconds so that the system will adhere to the time you set. For more on how to create time-bound keys, see Jetpack Security’s MasterKeys section.

Usually, namely the aforementioned 1, you to BiometricPrompt. Authenticate () method is passed a CryptoObject parameters to request auth – per – use the key. However, instead of using CryptoObject, you can set a very short time parameter (say, 5 seconds) to use the time-bound key as the Auth-per-use key. The two approaches are essentially the same for authenticating a user, and the choice depends on how you design your application interactions.

Let’s take a look at how these two different types of keys work: When you use CryptoObject, only a specific action can unlock the key. This is because Keymint (or Keymaster) gets 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 once, because it is an Auth-per-use key. Without CryptoObject, the HAT sent to Keymint does not have an operationId. In this case, Keymint looks for a HAT with a valid time stamp (timestamp + key life > current time). Within the valid time, You can use this key because it is a time-bound key.

It looks as if the time-bound key can be used by any application within a valid time window. In practice, however, as long as no user-space is compromised, there is no need to worry that some X application uses some Y application’s keys or operations. The Android framework does not allow other applications to obtain or initialize another application’s operations.

conclusion

In this article, we introduced:

  • The user name + password authentication mode is faulty.

  • Reasons for choosing to use biometric authentication in applications;

  • Considerations for different types of applications in the design of authentication methods;

  • How to invoke BiometricPrompt with or without encryption enabled;

  • Auth-per-use and time-bound encryption keys.

In the next article, we’ll show you how to properly integrate biometric authentication processes into your application’s UI and business logic. Stay tuned!