关于android:在-Android-中使用生物识别

5次阅读

共计 3265 个字符，预计需要花费 9 分钟才能阅读完成。

为了爱护隐衷和敏感数据，利用往往会减少用户登录性能。如果您的利用应用了传统的登录形式，那么它的受权过程可能相似如图 1 中所示: 用户输出用户名和明码，利用会依据输出的数据生成设施凭据，而后将其发送到远端服务器进行验证，通过验证后会返回给利用一个 userToken，随后利用便可应用该 token 去服务器查问受限的用户数据。无论是要求用户每次关上利用都须要登录，还是只要求在装置启动后进行仅此一次的登录，图 1 所示的流程都实用。

△ 图 1: 未应用生物辨认的受权流程

然而，图 1 这种受权形式有一些弊病:

如果对于每次独立的会话都须要进行验证 (比方银行类的利用)，那么这套流程会让用户感到十分繁琐，因为每次关上利用都须要输出一遍明码；
如果验证产生在利用首次装置后关上时 (比方邮件类利用)，那么领有该设施的任何人都能够查看设施所有者的隐衷内容，因为利用无奈验证以后使用者是否为设施所有者自己。

为了补救这些弊病，咱们引入了生物辨认身份验证的形式，为终端用户的身份验证流程提供了诸多便当。不仅如此，这套技术对开发者也更具吸引力，即便业务逻辑可能不须要用户频繁登录。应用生物辨认身份验证带来的最要害的益处在于，整个认证过程非常简短，只须要轻按一下传感器或是看一眼设施就实现了。而作为开发者，您要确定您的用户必须要进行从新认证的频率，是一天一次，一周一次还是每次关上利用都须要从新认证。总而言之，咱们提供的 API 封装了许多性能，使开发者及其用户取得更加敌对不便的登录体验。

现在，许多解决集体数据的利用 (例如邮件或社交利用) 在装置后往往只须要进行一次性身份验证。这种做法遍及起来，是因为每次关上利用都须要输出用户名和明码的形式对用户体验造成了不良影响。但若是应用了生物辨认技术，用户便不再放心安全性的缺失。即便您的利用还是应用一次性的身份验证，也能够思考定期进行生物特色辨认，以验证是否为同一用户。验证周期的长短齐全取决于开发者的设定。

如果利用要求每次独立会话都须要进行验证 (或者是某些较为频繁的认证频率，例如每 2 小时一次或者每天一次等等)，那么相比每次都手动输出明码进行验证的话，看一眼设施或轻按一下传感器这种形式就只是一种微不足道的操作。
如果利用仅需在装置后进行一次性验证 (例如邮件类利用)，那么增加生物辨认性能的代价只是让用户多了一个拿起设施而后看一眼的操作，但却额定提供了更加平安的保障。
如果用户心愿无需额定进行验证，仍可能放弃邮件的关上状态，那么应该提供选项容许这种行为。

对于想取得更多隐衷爱护的用户，生物辨认性能可能提供额定的安心保障。无论哪种形式，同减少的收益相比，用户所付出的老本微不足道。

通过 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 密钥是一种被用来执行一次性加密操作的密钥。举个例子，如果您想执行 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 框架不会容许其余利用获取或者初始化另一个利用的操作。

在本篇文章中，咱们介绍了: