지문 로그인이나 FaceId 결제 및 기타 수요 시나리오의 사용은 이제 매우 일반적이므로 기본적으로 Android, iOS 또는 RN이든 모바일 단말기 개발이 관련되어 있는 한 Flutter는 생체 인증에 익숙해야 합니다. 이 비즈니스 시나리오에 다소 노출될 수 있습니다.
물론 플랫폼 기능이나 인터페이스 기능에 대한 친숙도에 차이가 있을 수 있으므로, 이 글에서는 주로 Android와 iOS에서 시스템의 생체 인증을 사용할 때 주의해야 할 점과 구체적인 프로세스가 무엇인지 소개합니다 .
⚠️참고: 이 글은 API 사용법 튜토리얼 보다는 리서치 데이터의 관점에서 접근해야 하는 방향에 적합하거나 접근 과정에서 의문점이 있는 글이므로 긴 경고입니다~
먼저 Android인지 iOS인지 지문인지 FaceId인지 모두 시스템에서 제공하는 API를 사용 하는 한 개발자로서 얻을 수 없는 개념에 대해 간략히 말씀드리겠습니다. 모든 사용자의 생체 데이터이므로 간단히 말해 시스템 API만 호출하고 성공 또는 실패 결과를 얻을 수 있습니다 .
1. 안드로이드
Android에서 생체 인증의 역사는 매우 울퉁불퉁하다고 할 수 있으며 간략하게 두 단계를 거쳤습니다.
FingerprintManager
(API 23)BiometricPrompt
(API 28)
따라서 아래 그림과 같이 실제로 하단 레이어에 생체 인증을 지원하는 두 Service
가지 가 있음을 알 수 있지만 androidx의 호환성 패키지 를 포함하여 FingerprintManager
Api28(Android P)이 @Deprecated
표시되어 있다는 점은 주목할 가치가 있습니다. , 공식 제안이 더 확실하고 즉시 사용 가능하기 때문FingerprintManagerCompat
@Deprecated
androidx.biometrics.BiometricPrompt
입니다.
1.1 생체 인식 프롬프트 사용
액세스에 대한 간략한 소개 BiometricPrompt
, 첫 번째 단계는 권한을 추가하는 것입니다.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.test.biometric">
<uses-permission android:name="android.permission.USE_BIOMETRIC" />
<uses-permission android:name="android.permission.USE_FINGERPRINT" />
</manifest>
复制代码
接着调用 BiometricPrompt
构建系统弹出框信息,具体内容对应可见下图:
最用设置 AuthenticationCallback
和调用 authenticate
,然后等待授权结果进入到成功的回调:
biometricPrompt = new BiometricPrompt(activity, uiThreadExecutor, authenticationCallback);
biometricPrompt.authenticate(promptInfo);
复制代码
当然上述代码还少了很多细节:
-
比如需要是
FragmentActivity
; -
检测设备是否支持生物认证(还有不支持的现在?);
-
判断支持哪种生物认证,当然默认
BiometricPrompt
会帮你处理,如果有多种会弹出选择;
而认证不成功的时候可以在 onAuthenticationError
里获取到对应的错误码:
onAuthenticationError | Type |
---|---|
BIOMETRIC_ERROR_LOCKOUT | 操作被取消,因为 API 由于尝试次数过多而被锁定(一般就是在一次 authenticate 里例如多次指纹没通过,锁定了, 但是过一会还可以调用) |
BIOMETRIC_ERROR_LOCKOUT_PERMANENT | 由于 BIOMETRIC_ERROR_LOCKOUT 发生太多次,操作被取消,这个就是真的 LOCK 了。 |
BIOMETRIC_ERROR_NO_SPACE | 剩余存储空间不足 |
BIOMETRIC_ERROR_TIMEOUT | 超时 |
BIOMETRIC_ERROR_UNABLE_TO_PROCESS | 传感器异常或者无法处理当前信息 |
BIOMETRIC_ERROR_USER_CANCELED | 用户取消了操作 |
BIOMETRIC_ERROR_NO_BIOMETRIC | 用户没有在设备中注册任何生物特征 |
BIOMETRIC_ERROR_CANCELED | 由于生物传感器不可用,操作被取消 |
BIOMETRIC_ERROR_HW_NOT_PRESENT | 设备没有生物识别传感器 |
BIOMETRIC_ERROR_HW_UNAVAILABLE | 设备硬件不可用 |
BIOMETRIC_ERROR_VENDOR | 如果存在不属于上述之外的情况,Other |
1.2、BiometricPrompt 自定义
简单接入完 BiometricPrompt
之后, 你可能会有个疑问: BiometricPrompt
是很方便,但是 UI 有点丑了,可以自定义吗?
抱歉,不可以 ,是的,BiometricPrompt
不能自定义 UI,甚至你想改个颜色都“费劲”, 如果你去看 biometric 的源码,就会发现官方并没有让你自定义的打算,除非你 cv 这些代码自己构建一套,至于为什么会有这样的设计,我个人猜测其中一条就是屏下指纹。
在官方的 《Migrating from FingerprintManager to BiometricPrompt》里也说了:丢弃指纹的布局文件,因为你将不再需要它们,AndroidX 生物识别库带有标准化的 UI。
什么是标准化的 UI ?如下所示是使用 BiometricPrompt
的三台手机,可以看到:
- 第一和第二台除了位置有些许不同,其他基本一致;
- 第三胎手机是屏下指纹,可以看到整个指纹输入的 UI 效果完全是厂家自己的另外一种风格;
所以使用 BiometricPrompt
你将不需要关注 UI 问题,因为你没得选,甚至你也不需要关注手机上的生物认证类型的安全度问题,因为不管是 CDD 还是 UI ,OEM 厂商的都会直接实现好,例如三星的 UI 是如下图所示:
Android 兼容性定义文档 (Android CDD)_里描述了生物认证传感器安全度的强弱,而在 framework 层面
BiometricFragment
和FingerprintDialogFragment
都是@hide
,甚至你单纯去翻androidx.biometric:biometric.aar
的库,你都看不到BiometricFragment
的布局,只能看到FingerprintDialogFragment
的 layout。
那就没办法自定义 UI 了吗?还是有的,有两个选择:
-
继续使用
FingerprintManager
,虽然标注了弃用,但是目前还是可以用,在 Android 11 上也可以正常执行对应逻辑,下图是同一台手机在 Android 11 上使用FingerprintManager
和BiometricPrompt
的对比: -
使用腾讯的 soter ,这个我们后面讲;
1.3、Login + BiometricPrompt
介绍完调用和 UI ,那就再结合 Login 场景聊聊 BiometricPrompt
,官方针对 Login 场景提供了一个 Demo ,这里主要介绍整个业务流程,具体代码可以看官方的 BiometricLoginKotlin ,前面说过生物认证只提供认证结果,那么结合 Login 业务,在官方的例子中 BiometricPrompt
主要是用于做认证和加密的作用:
如上图所示,场景是在登陆之后,我们获取到了用户的 Token 信息,这个 Token 信息可能是服务器基于用户密码合并后的内容,所以它包含了一些敏感隐私,为了安全期间我们不能直接存储,而是利用 BiometricPrompt
去实现加密后存储:
- 首先通过
KeyStore
,主要是得到一个包含密码的SecretKey
,当然这里有一个关键操作,那就是setUserAuthenticationRequired(true)
,后面我们再解释; - 然后利用
SecretKey
创建Clipher
,Clipher
就是 Java 里常用于加解密的对象; - 利用
BiometricPrompt.CryptoObject(cipher)
去调用生物认证授权; - 授权成功后会得到一个
AuthenticationResult
,Result 里面包含存在密钥信息的cryptoObject?.cipher
和cipher.iv
加密偏移向量; - 利用授权成功后的
cryptoObject?.cipher
对 Token 进行加密,然后和cipher.iv
一起保存到SharePerferences
,就完成了基于BiometricPrompt
的加密保存;
是不是觉得有点懵? 简单说就是:我们通过一个只有用户通过身份验证时才授权使用的密钥来加密 Token ,这样不管这个 Token 是否泄漏,对于我们来说都是安全的。
然后在 KeyStore
逻辑里这里有个 setUserAuthenticationRequired(true)
操作,这个操作的意思就是:是否仅在用户通过身份验证时才授权使用此密钥,也就是当设置为 true
时:
用户必须通过使用其锁屏凭据的子集(例如密码/PIN/图案或生物识别)向此 Android 设备进行身份验证,才能够而授权使用密钥。
也就是只有设置了安全锁屏时才能生成密钥,而一旦安全锁屏被禁用(重新配置为无、不验证用户身份的模式、被强制重置)时,密钥将不可逆转地失效。
另外可以设置了
setUserAuthenticationValidityDurationSeconds
来要求密钥必须至少有一个生物特征才可用,而一但它设置为 true,如果用户注册了新的生物特征,它也将不可逆转地失效。
所以可以看到,这个流程下密钥会和系统安全绑定到一起,从而不害怕 Token 等信息的泄漏,也因为授权成功后的 CryptoObject
和 KeyStore
集成到一起,可以更有效地抵御例如 root 的攻击。
而反之获取的流程也是类似,如下图所示:
- 在
SharePerferences
里获取加密后的 Token 和 iv 信息; - 同样是利用
SecretKey
创建Clipher
,不过这次要带上保存的 iv 信息; - 利用
BiometricPrompt.CryptoObject(cipher)
去调用生物认证授权; - 通过授权成功后的
cryptoObject?.cipher
对 Token 进行加密,得到原始的 Token 信息;
所以可以看到,基本思路就是利用 BiometricPrompt
认证后得到 CryptoObject?.Cipher
去加解密,通过系统的安全等级要保护我们的隐私信息。
最后补充一个知识点,虽然一般我们不关心,但是在 BiometricPrompt
里有 auth-per-use 和 time-bound 这两个概念:
- auth-per-use 密钥要求每次使用密钥时,都必须进行认证 ,前面我们通过
BiometricPrompt.CryptoObject(cipher)
去调用授权方法就是这类实现; - time-bound 密钥是一种在一定的时间段内有效的密钥,可以通过
setUserAuthenticationValidityDurationSeconds
设置有效时长,如果你设置为很短,例如 5 秒,那行为上和 auth-per-use 基本类似;
更多资料可以参考官方的 biometric-authentication-on-android
1.4、Tencent soter
前面说到 Android 上还有 soter ,腾讯在微信指纹支付全流程之上,将它的流程抽象为一套完备的生物识别标准:SOTER。
SOTER 会与手机厂商合作,在系统原有的接口能力之上提供安全加固,通过业务无关的安全域(TEE,即独立于手机操作系统的安全区域,root或越狱无法访问到)应用程序(TA)降低开发难度和适配成本,做到即使外部环境不可信,依然可以安全授权。
TEE(Trusted Execution Environment)是独立于手机操作系统的一块独立运行的安全区域,SOTER标准中,所有的密钥生成、数据签名处理、指纹验证、敏感数据传输等敏感操作均在 TEE 中进行,并且 SOTER使用的设备根密钥由厂商在产线上烧入,从根本上解决了根密钥不可信的问题,并以此根密钥为信任链根,派生密钥,从而完成,与微信合作的所有手机厂商将均带有硬件TEE,并且通过腾讯安全平台和微信支付安全团队验收,符合SOTER标准。
简而言之,这是一个支持直通厂商,并且具备后台服务对接校验的第三方库,目前最近 5 个月都还有在更新,那它有什么问题呢?
那就是必须是与微信合作的所有手机厂商和机型才能正常使用 ,而且经常在一些厂商系统上出现奇奇怪怪的问题,比如:
- MiUI13 绑定服务异常;
- 鸿蒙系统API层面报错;
- 莫名其妙地出现崩溃;
但是它可以实现基本类似于微信支付的能力,所以如何取舍就看你的业务需求了。
支持机型可查阅 :#有多少设备已经支持tencent-soter
iOS
相对来说 iOS 上的生物认证就舒适不少,相比较 Android 上需要区分系统版本和厂商的 fingerprint
、face
和 iris
,iOS 上的 Face ID 和 Touch ID 就十分统一和简洁。
简单介绍下 iOS 上使用生物认证,首先需要在 Info.plist
文件添加描述信息:
<key>NSFaceIDUsageDescription</key>
<string>Why is my app authenticating using face id?</string>
复制代码
然后导入头文件 #import <LocalAuthentication/LocalAuthentication.h>
,最后创建 LAContext
去执行授权操作,这里也简单展示对应的错误码:
Error Code | Type |
---|---|
LAErrorSystemCancel | 系统取消了授权,比如有其他APP切换 |
LAErrorUserCancel | 用户取消验证 |
LAErrorAuthenticationFailed | 授权失败 |
LAErrorPasscodeNotSet | 系统未设置密码 |
LAErrorBiometryNotAvailable | ID不可用,例如未打开 |
LAErrorBiometryNotEnrolled | ID不可用,用户未录入 |
LAErrorUserFallback | 用户选择输入密码 |
而同样关于自定义 UI 问题上,想必大家都知道了,iOS 生物认证没有自定义 UI 的说法,也不支持自定义 UI ,系统怎么样就怎么样,你可以做的只有类似配置‘是否允许使用密码授权’这样的行为 。
在这一点上相信 Android 开发都十分羡慕 iOS ,有问题也是系统问题,无法修复。
同样,简单说说在 iOS 上使用生物识别的 Login 场景流程:
- 获取到 Token 信息后,验证用户的 TouchID/FaceID ;
- 验证通过后,将 Token 等信息保存到 keychain (keychain 只是一个数据存储,用于存储一些敏感数据如密码、证书等);
- 保存成功后,下次再次登录时通过验证 TouchID/FaceID 获取对应信息;
这里主要有两个关键点:
- 访问级别 : 例如是否需要每次都进行身份验证时才可以访问项目;
- 身份验证级别: 也就是什么场景下可以访问到存储的信息;
举个例子,访问 keychain 首先是需要创建 accessControl ,一般可以通过 SecAccessControlCreateWithFlags
来创建 accessControl ,这里有个关键参数用于指定访问级别:
- kSecAttrAccessibleAfterFirstUnlock 开机之后密钥不可用,需要等用户输入开机密码
- kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly: 开机之后密钥不可用,需要等用户输入开机密码,但是仅限于当前设备
- kSecAttrAccessibleWhenUnlocked: 解锁过的设备密钥会保持可用状态
- kSecAttrAccessibleWhenUnlockedThisDeviceOnly: 解锁过的设备密钥会保持可用状态,仅当前设备
- kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly: 解锁过的设备密钥会保持可用状态,只有用户设置密码后密钥才可用
- kSecAttrAccessibleAlways: 始终可用,已经 Deprecated
- kSecAttrAccessibleAlwaysThisDeviceOnly: 密钥始终可用,但无法迁移到其他设备,已经 Deprecated
类似场景下一般使用 kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly
,另外还有 SecAccessControlCreateFlags
标志,它主要是用于指定希望用户在访问钥匙串时的约束,一般类似场景会使用 userPresence
:
- devicePasscode: 限制使用密码访问
- biometryAny: 使用任何已注册 touch 或 face ID 访问
- biometryCurrentSet: 限制使用当前注册 touch 或 face ID 访问
- userPresence: 限制使用生物特征或密码访问
- watch: 使用手表访问
创建完成 accessControl 之后,通过设置 kSecAttrAccessControl 后正常把信息存储到 keychain 就可以了,在存储 keychain 时也有可选的 kSecClass
,一般选用 kSecClassGenericPassword
:
- kSecClassGenericPassword: 通用密码
- kSecClassInternetPassword: Internet 密码
- kSecClassCertificate:证书
- kSecClassKey:加密密钥
- kSecClassIdentity: 身份认证
当然,此时你是否发现,在谈及 accessControl 和 keychain 时没有说明 LAContext
?
其实在创建 accessControl 时是有对应 kSecUseAuthenticationContext
参数用于设置 LAContext
到 keychain 认证,但是也可以不设置,具体为:
- 如果未指定,并且该项目需要 authentication 认证,那就会自动创建一个新的
LAContext
,使用一次后丢弃; - 如果是使用先前已通过身份验证的
LAContext
,则操作直接成功而不要求用户进行身份验证; - 如果是使用先前未经过身份验证的
LAContext
,则系统会尝试在该LAContext
上进行身份验证,如果成功就可以在后续的钥匙串操作中重用。
iOS에서는 시스템 수준이 추가 기능을 제공하지 않기 때문에 간단하게 구성하기만 하면 됩니다.
3. 마지막으로
이 글에서는 안드로이드나 iOS 생체인증을 사용하는 방법을 가르쳐주지는 않지만, 요약하자면 이 글은 기본적으로 안드로이드나 iOS 생체인증과 관련된 기본적인 개념과 이슈들을 다루고 있기 때문에 이 글이 특히 생체인식 연구에 적합할 것이라고 생각합니다. 개발 파트너.
마지막으로 아직 연습 중인데, 이러한 편의를 위해 궁금한 점이나 건의사항이 있으면 댓글과 교환을 남겨주세요.