通過 BiometricPrompt API，您可以在加密和不加密的情況下實現身份驗證。如果您的應用需要更強安全性的保障 (例如醫療類或銀行類應用)，則可能需要?將加密密鑰同生物特征綁定在一起?來驗證用戶的身份。否則您僅需向用戶提供生物識別身份驗證即可。兩種方式的代碼實現很類似，除了在需要加密時要用到?CryptoObject?實例。

加密版本:

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

復制代碼

在上述代碼中，我們向 CryptoObject 傳遞了?Cipher?參數，除此之外也支持其余加密對象，比如使用?Mac?或?Signature。

不使用 CryptoObject 的版本:

biometricPrompt.authenticate(promptInfo)

復制代碼

若要在 Android 應用中實現生物識別身份驗證，請使用?AndroidX Biometric?代碼庫。雖然 API 可以自動處理不同的認證級別 (指紋、面部識別、虹膜識別等)，但您仍然可以通過?setAllowedAuthenticators()?方法設置應用可以接受的生物認證級別，具體如下面的代碼所示。Class 3?(以前被稱為?Strong) 級別代表您希望使用生物識別來解鎖存儲在 Keystore 中的憑證；Class 2?(以前被稱為?Weak) 級別代表您只需要使用生物識別來解鎖應用，而不依賴于加密技術保護的憑證進一步進行身份驗證。還有一個?Class 1?級別，但此級別在應用中并不可用。更多詳情，請查看?Android 兼容性定義文檔。

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

BiometricPrompt.PromptInfo.Builder().apply {

setAllowedAuthenticators(BIOMETRIC_STRONG)

// 繼續設置其他 PromptInfo 屬性，如標題、副標題、描述等。

}.build()

復制代碼

加密、auth-per-use (每次驗證) 密鑰 vs time-bound (時間限制) 密鑰

---

auth-per-use?密鑰?是一種被用來執行一次性加密操作的密鑰。舉個例子，如果您想執行 10 次加密操作，那么就必須解鎖 10 次密鑰。因此，auth-per-use?就意味著每次使用密鑰時，都必須進行認證 (即解鎖密鑰)。

time-bound?密鑰?則是一種在一定的時間段內有效的密鑰，您通過向?setUserAuthenticationValidityDurationSeconds?方法傳遞一個以秒為單位的時間參數，過了該時間后該密鑰就需要再次進行解鎖。如果您傳遞的時間參數值為 -1，也就是默認值，那么系統會認為您想要使用?auth-per-use?密鑰。在這里若您不想設置為 -1，那么我們建議您至少設置為 3 秒，這樣系統會遵循您所設置的時間。想要了解更多創建 time-bound 密鑰的方法，請參考?Jetpack Security?中關于?MasterKeys?的內容。

通常，即前面提到的 -1 的情況時，您通過向 BiometricPrompt.authenticate() 方法傳遞一個 CryptoObject 參數來請求?auth-per-use?密鑰。然而，您也可以不使用 CryptoObject，而是設置一個很短的時間參數 (比如 5 秒)，來將?time-bound?密鑰當作?auth-per-use?密鑰來使用。這兩種方法對于驗證用戶身份來說實際上是等同的，如何選擇取決于您設計應用交互的方式。

讓我們看看這兩種不同類型的密鑰是如何工作的: 當您使用 CryptoObject 時，只有某個特定操作才能夠解鎖密鑰。這是因為 Keymint (或者是 Keymaster) 獲取了一個帶有特定 operationId 的 HardwareAuthToken (HAT)。當密鑰被解鎖后，您只能使用密鑰去執行那些被定義為 Cipher/Mac/Signature 的操作，并只能執行一次，因為這是一個?auth-per-use?密鑰。若不使用 CryptoObject，那么被發送到 Keymint 的 HAT 就沒有 operationId，此時，Keymint 會去查找一個帶有有效時間戳 (時間戳 + 密鑰使用期限 > 當前時間) 的 HAT，在有效時間內，您都能夠使用該密鑰，因為它是一個?time-bound?密鑰。

這樣看上去，似乎只要在有效的時間窗口內，任何應用都可以使用?time-bound?密鑰。但實際上，只要不是用戶空間 (user-space) 受到損害，不用擔心某個?X?應用使用了某?Y?應用的密鑰或操作。Android 框架不會允許其他應用獲取或者初始化另一個應用的操作。

總結

---

在本篇文章中，我們介紹了:

• 只有用戶名 + 密碼的認證方式存在問題的原因；

• 在應用中選擇使用生物識別身份驗證的原因；

• 不同類型應用在
  設計認證方式時的注意事項；
  原因；

• 在應用中選擇使用生物識別身份驗證的原因；

• 不同類型應用在[外鏈圖片轉存中…(img-yNxSCYSH-1642933162675)]
  設計認證方式時的注意事項；

總結

以上是生活随笔為你收集整理的在 Android 中使用生物识别，kotlin开发思维的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。