HarmonyOS:User Authentication Kit简介

一、简介

User Authentication Kit(用户认证服务)提供了基于用户在设备本地注册的锁屏口令、人脸、指纹、伴随设备来认证用户身份的能力。

提供了系统级用户身份认证功能,并提供了多设备统一的、集多种认证方式(锁屏口令、人脸、指纹、伴随设备)于一体的系统级用户身份认证控件。

用户向应用/系统服务请求访问某些个人数据或执行某些敏感操作时,应用/系统服务将调用系统用户身份认证控件对用户身份进行认证,认证通过后,响应用户对于数据或敏感操作的执行请求。

用户身份认证可用于各种鉴权场景,如应用内账号登录、支付认证等。

二、场景介绍

2.1 单设备场景(口令认证、指纹认证、人脸认证)

!在这里插入图片描述(https://i-blog.csdnimg.cn/direct/d66b4b952cb340b7babb59042b2f844f.png)

2.2 伴随设备场景

伴随设备是一种协同认证能力,提供基于用户所持有的伴随设备对用户进行身份认证的功能。伴随设备认证的方式,从API版本26.0.0开始支持,其中代理认证待后续再对生态开放支持。
伴随设备认证三要素:

  1. 设备间建立信任关系:伴随设备被用户在主设备上添加为自己的身份认证凭据。
  2. 伴随设备确认用户身份:伴随设备确认当前佩戴或操作者自己的用户是机主本人。
  3. 主设备确认机主授权:主设备通过伴随设备确认机主在附近或机主手动确认了操作。
    伴随设备无感认证,伴随设备需具有持续跟踪用户能力。


伴随设备代理认证,伴随设备需具备独立认证用户身份的能力。如在多屏协同场景中,PC/2in1设备作为伴随设备,用户可通过PC/2in1设备完成本地人脸或指纹认证,当前该能力仅开放给系统应用。

三、约束与限制

3.1 系统身份认证约束与限制
  • 三方应用调用系统本地身份认证能力,必须使用系统自带的身份认证控件。
  • 不允许三方应用在后台发起身份认证请求。
  • 由于设备硬件差异,系统存在不支持人脸、指纹等认证能力情形,该情形可以通过查询支持的认证能力加以判断,请参考对应的userAuth.getAvailableStatus。
3.2 模拟器支持情况

本Kit支持模拟器。

模拟器与真机存在通用差异

四、能力介绍

  • 归一化认证接口提供多种身份认证能力
    提供系统级身份认证能力:锁屏口令认证、人脸认证、指纹认证、伴随设备认证,核心认证逻辑下沉TEE(Trust Execution Environment,可信执行环境)中。其中伴随设备认证的方式,从API版本26.0.0开始支持。
    屏蔽不同认证因子的差异,调用锁屏口令、人脸、指纹、伴随设备认证的接口归一。
    同一套接口提供人脸、指纹、锁屏口令等组合认证方式。
    同一套接口提供人脸认证、指纹认证、业务自定义认证等组合。
  • 支持感知认证可信等级差异
    支持调用者指定期望的认证可信等级,避免将低安全认证能力应用在高风险操作的用户鉴权场景。例如将防伪能力不够的2D人脸认证用于支付场景。
  • 支持业务自定义认证方式
    支持带导航键的认证界面,用户点击导航键可切换业务自定义认证界面。
  • 支持短时间内复用任意应用的认证结果
    支持选择复用锁屏认证结果或任意应用的身份认证结果,认证后调用者指定的时间范围内(最长5min),可直接返回认证通过结果,无需重复认证。
    支持认证方式无关的复用模式,采用此模式,无论上次认证使用何种方式,只要在认证后调用者指定的时间范围内(最长5min),可直接返回认证通过结果,无需重复认证。
    支持认证方式匹配的复用模式,采用此模式,不仅需要处于调用者指定的认证后时间范围内(最长5min),还需要认证使用的认证方式与调用者指定的一致,才能复用解锁认证结果并返回认证通过。
  • 提供系统级用户身份认证界面
    支持调用者自定义认证界面的标题和导航键文字。
    用户身份认证控件会根据设备屏幕状态自适应调整窗口显示模式。
  • 支持感知注册凭据的变化
    业务开通时,从认证成功结果中获取用户凭据的状态,或者直接查询用户凭据的状态,并存储注册的凭据状态。当调用者需要感知用户凭据变化时,需要从当前认证成功结果获取凭据的状态,或者查询当前凭据的状态,通过对比差异感知凭据状态的变化。

五、运作机制

统一用户认证框架架构如下图所示。

用户认证框架主要包括四个部分:

  1. 统一用户认证API:提供归一化的系统用户身份认证能力调用接口。屏蔽认证差异,便于开发者调用系统能力认证用户身份。
  2. 统一用户认证框架:包括框架层的SA和驱动,负责调度系统上的各种身份认证能力和用户认证控件,来完成业务通过统一用户认证API发起的用户认证请求。
  3. 统一用户认证控件:实现了各种认证方式的用户身份认证交互界面,确保一致的用户身份认证体验,供统一用户认证框架调用。
  4. 各种认证能力:包括口令认证、人脸认证、指纹认证和伴随设备认证,分别实现了基于锁屏口令、人脸、指纹和伴随设备认证用户身份的能力,供统一用户认证框架调度。

用户身份认证通过后,统一用户认证框架会在设备可信执行环境中签发用户身份认证通过证明,简称AuthToken。

从图的左侧,可以看到应用使用用户身份认证功能完成用户鉴权的过程:当应用需要调用通用密钥库服务中需用户授权才能访问的密钥时,应用可以将获取到的AuthToken随密钥调用请求一同提供给通用密钥库服务,作为密钥二次访问控制的用户鉴权证明。通用密钥库服务在可信执行环境中校验了AuthToken的合法性和有效性后,便会响应业务请求,执行对应的密钥操作。

5.1 生物认证可信等级划分原则

认证可信等级评估的是系统用户身份认证能力的安全性,取决于认证方案能力等级(Authentication Capability Level,ACL)和该认证系统的实现安全等级(Authentication Security Level,ASL)。

系统采用三种指标来衡量生物认证方案能力等级,具体定义如下表所示:

  • FRR(False Rejection Rate):将合法用户当做非法用户拒绝的概率。
  • FAR(False Acceptance Rate):将非法用户当做合法用户接受的概率,又称为误闯率。
  • SAR(Spoof Acceptance Rate):接受一个基于合法生物特征复制的、非活体的样本概率。

FAR越低,FRR越高,认证的安全性越高,但合法用户被错误拒绝的概率越高,导致使用便捷性越差;反之FAR越高,FRR越低,则认证安全性越差,使用便捷性越好。

认证方案能力等级 认证能力指标
ACL4 FRR=10%时,FAR≤0.0001%,SAR≤3%
ACL3 FRR=10%时,FAR≤0.002%,SAR≤7%
ACL2 FRR=10%时,FAR≤0.002%,7%<SAR≤20%
ACL1 FRR=10%时,FAR≤1%,7%<SAR≤20%

生物认证系统一般分为以下5个执行单元:生物特征源数据的采集、生物特征的提取、生物特征的存储、生物特征的比对和认证结果的签发。系统将认证过程中的各个执行单元的运行环境安全ESL(Executor Security Level)分为以下4个等级:

执行单元安全等级 定义
ESL3 操作在高安全硬件可信环境中完成,如安全协处理器、安全芯片等。
ESL2 操作在基于硬件可信根隔离的可信执行环境中完成,如TEE、SGX。
ESL1 操作在有访问控制的执行环境中完成,如Linux。
ESL0 操作在无访问控制的运行环境中完成,如单进程的轻量级系统。

整个认证系统的实现安全等级ASL等于生物认证5个执行单元中最低的ESL级别。例如,有一个人脸认证系统,其特征存储和比对都在安全隔离环境TEE中执行(即ESL=2),但特征提取算法运行在普通系统环境中(即ESL=1),则该人脸认证系统的ASL=1。
由认证方案能力等级和认证方案安全等级映射得到认证结果可信等级的具体规则如下表:

认证可信等级 映射规则 说明&举例 典型应用场景
ATL4 ACL≥3,ASL≥2 能高精度地识别用户个体,有很强的活体检测能力,如:有特殊安全增强的指纹与3D人脸认证。 小额支付。
ATL3 ACL≥3,ASL≥1 ACL≥2,ASL≥2 能精确识别用户个体,有较强的活体检测能力,如:有特殊安全增强的2D人脸认证,有TEE环境的伴随设备如智能眼镜。 设备解锁、应用登录、账号登录。
ATL2 ACL≥2,ASL≥1 ACL≥1,ASL≥2 能精确识别用户个体,有一定的活体检测能力,如:使用普通相机采集图像的2D人脸认证,无TEE环境业务特殊安全增强的伴随设备如耳机。 维持设备解锁状态。
ATL1 ACL=1,ASL=1 能识别用户个体,有一定的活体检测能力,如声纹认证。 业务风控、精准推荐、个性化服务。
5.2 支持的认证能力

提供系统级身份认证能力:锁屏口令认证、人脸认证、指纹认证、伴随设备认证,核心认证逻辑下沉TEE中。其中伴随设备认证的方式,从API版本26.0.0开始支持。

5.2.1 锁屏口令认证

锁屏口令输入界面由系统级应用提供,锁屏口令信息在完成数据采集和脱敏处理后,传递给密码认证框架,在TEE中完成密码数据的比对,认证过程密码原文及中间计算结果不外传,也不会被穷举逆推出用户的锁屏口令。密码认证有防暴力破解机制,锁屏口令比对失败,会导致用户的锁屏口令防暴计数增加,并触发防暴惩罚。

5.2.2 人脸认证

提供2D和3D两种人脸认证方案的支持。3D人脸认证方案依赖特殊的深度摄像头实现,2D人脸认证技术则基于普通的前置摄像头实现。3D人脸认证的准确率和防伪能力均显著优于2D人脸认证。3D人脸认证技术可支持支付应用,2D人脸认证技术不能支持支付应用。不同的终端设备型号根据其产品定位选择其搭载的人脸认证类型。
在摄像头和TEE之间建立安全通道,人脸图像信息通过安全通道传递到TEE中,特征提取、活体检测、特征比对等处理也完全在TEE中,基于TrustZone进行安全隔离,外部的人脸框架只负责人脸认证相关任务的调度和人脸认证结果等数据的传递,不接触人脸原始数据。

5.2.3 指纹认证

目前可提供电容指纹和光学指纹的支持。两种技术方案的体验及安全能力基本一致。不同的终端设备根据其产品定位选择其搭载的指纹认证技术类型。
在指纹传感器和TEE之间建立安全通道,指纹图像通过安全通道传递到TEE中,特征提取、活体检测、特征比对等处理也完全在TEE中进行,基于TrustZone进行安全隔离。REE(Rich Execution Environment,普通执行环境)的指纹认证框架只负责指纹认证相关任务的调度和指纹认证结果等数据的传递,不接触指纹原始数据。

5.2.4 伴随设备认证

伴随设备是一种协同认证能力,提供基于用户所持有的伴随设备对用户进行身份认证的功能。
伴随设备认证是系统支持的一种用户认证执行器,按照统一用户认证定义的资源注册接口,将伴随设备认证相关资源信息注册到统一用户认证框架,并根据框架调完成可信设备的注册、删除和认证。
主设备添加伴随设备过程中,主设备和伴随设备会交换各自的认证相关信息,该凭据主要用于保护认证阶段主设备与伴随设备之间交互信息的安全性。因此,主设备侧和伴随设备侧都需要在可信执行环境内保存和使用该凭据信息。

相关推荐
m0_738185822 小时前
Flutter 鸿蒙化实战:qrcode_flutter 适配 OpenHarmony,二维码生成与识别
数码相机·flutter·华为·harmonyos·鸿蒙
万物智能信息科技2 小时前
血氧心跳传感器MAX30100芯片驱动开发—【万物智能之开源鸿蒙OpenHarmony系统实战开发系列教程】
人工智能·驱动开发·华为·开源·harmonyos·鸿蒙
老陈说编程2 小时前
1. 鸿蒙 (HarmonyOS) 2012 至 2026 年的发展历程
分布式·华为·个人开发·harmonyos·鸿蒙·鸿蒙系统·程序员创富
m0_738185823 小时前
Flutter 鸿蒙化实战:open_app_settings 适配 OpenHarmony,一键跳转系统设置
flutter·华为·harmonyos·鸿蒙
Fate_I_C3 小时前
拆解一个鸿蒙化插件:CPF-Ionic 是如何把 43 个 Capacitor 插件搬上 OpenHarmony 的
华为·harmonyos
m0_738185823 小时前
Flutter 鸿蒙化实战:qr_code_scanner 适配 OpenHarmony,相机扫码实时识别
数码相机·flutter·华为·harmonyos·鸿蒙
梦想不只是梦与想16 小时前
HarmonyOS应用分层架构设计
harmonyos·分层架构·一次开发,多端部署
MardaWang18 小时前
当滚动逃离了框架 ——HarmonyOS Web 与原生混排滚动的冲突本质与解法
harmonyos·arkts·鸿蒙·deveco studio