【华为ICT大赛】安全基础平台

00. 目录

文章目录

01. 学习目标

程序访问控制资本规则、接口权限管控方法、安全控件及系统PICKER使用方法

02. 访问控制概述

访问控制概述

默认情况下，应用只能访问有限的系统资源。但某些情况下，应用存在扩展功能的诉求，需要访问额外的系统数据（包括用户个人数据）和功能，系统也必须以明确的方式对外提供接口来共享其数据或功能。

系统通过访问控制的机制，来避免数据或功能被不当或恶意使用。当前访问控制的机制涉及多方面，包括应用沙箱、应用权限、系统控件等方案。

应用沙箱

系统上运行的应用程序均部署在受保护的沙箱中，通过沙箱的安全隔离机制，可以限制应用程序的不当行为（如应用间非法访问数据、篡改设备等）。每个程序都拥有唯一的ID（TokenID），系统基于此ID识别与限制应用的访问行为。

应用沙箱限定了只有目标受众才能访问应用内的数据，并限定了应用可访问的数据范围，具体请参考应用沙箱目录。

应用权限

系统根据应用的APL等级设置进程域和数据域标签，并通过访问控制机制限制应用可访问的数据范围，从而实现在机制上消减应用数据泄露的风险。

不同APL等级的应用能够申请的权限等级不同，且不同的系统资源（如：通讯录等）或系统能力（如：访问摄像头、麦克风等）受不同的应用权限保护。通过严格的分层权限保护，有效抵御恶意攻击，确保系统安全可靠。

应用权限管控的详细介绍，请参考应用权限管控概述。

安全访问机制

OpenHarmony推出安全访问机制，改变应用获取隐私数据的方式，让用户从管理“权限”到管理“数据”，按需授予系统数据。举例而言，当用户想要更换社交平台头像时，应用将无法再获取整个图库的访问权限，用户选择哪张照片，应用就得到哪张照片，将用户的隐私数据与应用之间受控隔离，全面守护用户隐私。

具体来说，安全访问机制主要由系统Picker、安全控件两种系统机制来实现，在特定的场景中，应用无需向用户申请权限也可临时访问受限资源，实现精准化权限管控，更好地保护用户隐私。

• 系统Picker由系统独立进程实现，在应用拉起Picker，并由用户操作Picker后，应用可以获取Picker返回的资源或结果。举例说明，当应用需要读取用户图片时，可通过使用照片Picker，在用户选择所需要的图片资源后，直接返回该图片资源，而不需要授予应用读取图片文件的权限。
• 安全控件由系统提供UI控件，应用在界面内集成对应控件，用户点击后，应用将获得临时授权，从而执行相关操作。举例说明，当应用需要分享当前位置时，可使用位置控件，用户点击后，将会在本次前台期间获得精准定位的授权，可以调用位置服务获取精准定位。当发生灭屏、应用切后台、应用退出等任一情况时，临时授权结束。

03. 应用权限管控

3.1 应用权限管控概述

简介

系统提供了一种允许应用访问系统资源（如：通讯录等）和系统能力（如：访问摄像头、麦克风等）的通用权限访问方式，来保护系统数据（包括用户个人数据）或功能，避免它们被不当或恶意使用。

应用权限保护的对象可以分为数据和功能：

• 数据包括个人数据（如照片、通讯录、日历、位置等）、设备数据（如设备标识、相机、麦克风等）。
• 功能包括设备功能（如访问摄像头/麦克风、打电话、联网等）、应用功能（如弹出悬浮窗、创建快捷方式等）。

权限使用的基本原则

合理的使用场景有助于应用权限申请和使用。开发应用时权限申请需要满足如下原则：

• 应用（包括应用引用的三方库）所需权限必须在应用的配置文件中严格按照权限开发指导逐个声明。参考声明权限。
• 权限申请满足最小化原则，禁止申请非必要的、已废弃的权限。应用申请过多权限，会引起用户对应用安全性的担忧以及使用体验变差，从而也会影响到应用的安装率和留存率。
• 应用申请敏感权限时，必须填写权限使用理由字段，敏感权限通常是指与用户隐私密切相关的权限，包括地理位置、相机、麦克风、日历、健身运动、身体传感器、音乐、文件、图片视频等权限。参考向用户申请授权。
• 应用敏感权限须在对应业务功能执行前动态申请，满足隐私最小化要求。
• 用户拒绝授予某个权限后，应用与此权限无关的其他业务功能应允许正常使用。

授权方式

根据授权方式的不同，权限类型可分为system_grant（系统授权）和user_grant（用户授权）。

system_grant（系统授权）

system_grant指的是系统授权类型，在该类型的权限许可下，应用被允许访问的数据不会涉及到用户或设备的敏感信息，应用被允许执行的操作对系统或者其他应用产生的影响可控。

如果在应用中申请了system_grant权限，那么系统会在用户安装应用时，自动把相应权限授予给应用。

user_grant（用户授权）

user_grant指的是用户授权类型，在该类型的权限许可下，应用被允许访问的数据将会涉及到用户或设备的敏感信息，应用被允许执行的操作可能对系统或者其他应用产生严重的影响。

该类型权限不仅需要在安装包中申请权限，还需要在应用动态运行时，通过发送弹窗的方式请求用户授权。在用户手动允许授权后，应用才会真正获取相应权限，从而成功访问操作目标对象。

例如，在应用权限列表中，麦克风和摄像头对应的权限都是属于用户授权权限，列表中给出了详细的权限使用理由。应用需要在应用商店的详情页面，向用户展示所申请的user_grant权限列表。

权限组和子权限

为了尽可能减少系统弹出的权限弹窗数量，优化交互体验，系统将逻辑紧密相关的user_grant权限组合在一起，形成多个权限组。

当应用请求权限时，同一个权限组的权限将会在一个弹窗内一起请求用户授权。权限组中的某个权限，称之为该权限组的子权限。

权限组和权限的归属关系并不是固定不变的，一个权限所属的权限组有可能发生变化。当前系统支持权限组请查阅应用权限组列表。

权限机制中的基本概念

• TokenID系统采用TokenID（Token identity）作为应用的唯一标识。权限管理服务通过应用的TokenID来管理应用的AT（Access Token）信息，包括应用身份标识APP ID、子用户ID、应用分身索引信息、应用APL、应用权限授权状态等。在资源使用时，系统将通过TokenID作为唯一身份标识映射获取对应应用的权限授权状态信息，并依此进行鉴权，从而管控应用的资源访问行为。值得注意的是，系统支持多用户特性和应用分身特性，同一个应用在不同的子用户下和不同的应用分身下会有各自的AT，这些AT的TokenID也是不同的。
• APL等级为了防止应用过度索取和滥用权限，系统基于APL（Ability Privilege Level，元能力权限等级）等级，配置了不同的权限开放范围。元能力权限等级APL指的是应用的权限申请优先级的定义，不同APL等级的应用能够申请的权限等级不同。
• 应用APL等级应用的等级可以分为以下三个等级，等级依次提高。APL级别说明normal默认情况下，应用的APL等级都为normal等级。system_basic该等级的应用服务提供系统基础服务。system_core该等级的应用服务提供操作系统核心能力。 应用APL等级不允许配置为system_core。
• 权限APL等级根据权限对于不同等级应用有不同的开放范围，权限类型对应分为以下三个等级，等级依次提高。APL级别说明开放范围normal允许应用访问超出默认规则外的普通系统资源，如配置Wi-Fi信息、调用相机拍摄等。 这些系统资源的开放（包括数据和功能）对用户隐私以及其他应用带来的风险低。APL等级为normal及以上的应用。system_basic允许应用访问操作系统基础服务（系统提供或者预置的基础功能）相关的资源，如系统设置、身份认证等。 这些系统资源的开放对用户隐私以及其他应用带来的风险较高。APL等级为system_basic及以上的应用。system_core涉及开放操作系统核心资源的访问操作。这部分系统资源是系统最核心的底层服务，如果遭受破坏，操作系统将无法正常运行。- APL等级为system_core的应用。 - 仅对系统应用开放。
• 访问控制列表（ACL）如上所述，权限APL等级和应用APL等级是一一对应的。原则上，拥有低APL等级的应用默认无法申请更高等级的权限。访问控制列表ACL（Access Control List）提供了解决低等级应用访问高等级权限问题的特殊渠道。系统权限均定义了“ACL使能”字段，当该权限的ACL使能为TRUE，应用可以使用ACL方式跨级别申请该权限。具体单个权限的定义，可参考系统应用可用的权限。场景举例：如开发者正在开发APL等级为normal的A应用，由于功能场景需要，A应用需要申请等级为system_basic的P权限。在P权限的ACL使能为TRUE的情况下，A应用可以通过ACL方式跨级申请权限P。

04. 使用安全控件

安全控件概述

安全控件是系统提供的一组系统实现的ArkUI组件，应用集成这类组件就可以实现在用户点击后自动授权，而无需弹窗授权。它们可以作为一种“特殊的按钮”融入应用页面，实现用户点击即许可的设计思路。

相较于动态申请权限的方式，安全控件可基于场景化授权，简化开发者和用户的操作，主要优点有：

1. 用户可掌握授权时机，授权范围最小化。
2. 授权场景可匹配用户真实意图。
3. 减少弹窗打扰。
4. 开发者不必向应用市场申请权限，简化操作。

安全控件坚持仅采集实现业务功能所必须的个人数据，以服务于用户的需求，帮助开发透明、可选、可控的隐私合规应用。

安全控件列表

目前系统提供三类安全控件：

• 粘贴控件（PasteButton）该控件对应剪贴板读取特权。应用集成粘贴控件后，用户点击该控件，应用读取剪贴板数据时不会弹窗提示。建议使用场景：粘贴控件可以用于任何应用需要读取剪贴板的场景，避免弹窗提示对用户造成干扰。
• 保存控件（SaveButton）该控件对应媒体库写入特权。应用集成保存控件后，用户点击该控件，应用会获取10秒内访问媒体库特权接口的授权。建议使用场景：保存控件可以用于任何应用需要保存文件到媒体库的场景（保存图片、保存视频等）。与Picker需要拉起系统应用再由用户选择具体路径保存的方式不同，保存控件将直接保存到指定媒体库路径，操作更快捷。
• 位置控件（LocationButton）该控件对应精准定位特权。应用集成位置控件后，用户点击该控件，无论应用是否申请过或者被授予精准定位权限，都会在本次前台期间获得精准定位的授权，可以调用位置服务获取精准定位。建议使用场景：应用不是强位置关联应用（如导航、运动健康等），仅在部分前台场景需要使用位置信息（如定位城市、打卡、分享位置等）。如果需要长时间使用或是在后台使用位置信息，建议申请位置权限。

运作机制

整体方案由安全控件UI组件、安全控件管理服务、安全控件增强组成：

• UI组件：实现了固定文字图标的样式，便于用户识别，同时提供了相对丰富的定制化能力，便于开发者定制。
• 控件管理服务：提供控件注册管理能力、控件临时授权机制、管理授权生效周期，确保应用后台、锁屏下无法注册使用安全控件。
• 安全增强：实现了地址随机化、挑战值检查、回调UI框架复核控件信息、调用者地址检查、组件防覆盖、真实点击事件校验等机制，防止应用开发者通过混淆、隐藏、篡改、仿冒等方式滥用授权机制，泄露用户隐私。

开发者调用接口时，运作流程如图所示。

1. 应用开发者在ETS文件中集成安全控件，通过JS引擎解析后，在ArkUI框架中生成具体的控件。
2. 安全控件注册控件信息到安全控件管理服务，安全控件管理服务检查控件信息的合法性。
3. 用户点击事件分发到安全控件。
4. 安全控件将点击事件上报到安全控件管理服务。
5. 安全控件管理服务根据控件种类对应不同权限，调用权限管理服务进行临时授权。
6. 授权成功后，安全控件回调OnClick通知应用层授权成功。
7. 应用调用相应的特权操作，如获取地理位置、读取剪贴板信息、媒体库中创建文件等。 不同类型的安全控件，对于权限的使用方式不同、授权的有效期也不同，详情请查阅具体安全控件的开发指导。
8. 对应的服务会调用权限管理服务或安全控件管理服务，获取授权结果，返回鉴权结果。

约束与限制

安全控件因其自动授权的特性，为了保障用户的隐私不被恶意应用获取，针对安全控件作了很多的限制。应用开发者需保证安全控件在应用界面上清晰可见、用户能明确识别，防止因覆盖、混淆等因素导致授权失败。

当因控件样式不合法导致授权失败的情况发生时，请开发者检查设备错误日志，过滤关键字"SecurityComponentCheckFail"可以获取具体原因。

说明： 请开发者关注过滤条件下，所有级别的日志。

可能会导致授权失败的问题（包括但不限于）：

• 字体、图标尺寸过小。
• 安全控件整体尺寸过大。
• 字体、图标、背景按钮的颜色透明度过高。
• 字体或图标与背景按钮颜色过于相似。
• 安全控件超出屏幕、超出窗口等，导致显示不全。
• 安全控件被其他组件或窗口遮挡。
• 安全控件的父组件有类似变形模糊等可能导致安全控件显示不完整的属性。

05. 系统Picker组件

拉起系统应用

本章节介绍拉起系统应用的方式，以及支持跳转系统应用的能力清单。

拉起系统应用的方式

拉起系统应用除了采用使用前面章节介绍的方式（比如使用openlink拉起指定应用、使用startAbilitybyType指定类型的应用），还可以采用如下方式。

• 使用系统Picker组件相机、文件管理、联系人等系统应用提供了系统Picker组件，支持开发者无需申请权限、即可使用系统应用的一些常用功能，比如访问用户的资源文件。应用拉起系统Picker组件（文件选择器、照片选择器、联系人选择器等）后，由用户在Picker上选择对应的文件、照片、联系人等资源，应用即可获取到Picker的返回结果。例如，一个音频播放器应用可以通过AudioViewPicker让用户选择音频文件，然后获取所选的音频文件路径进行播放。> 说明： 由于系统Picker已经获取了对应权限的预授权，开发者使用系统Picker时，无需再次申请权限也可临时受限访问对应的资源。例如，当应用需要读取用户图片时，可通过使用照片Picker，在用户选择所需要的图片资源后，直接返回该图片资源，而不需要授予应用读取图片文件的权限。> > 系统Picker由系统独立进程实现。
• 使用特定接口设置、电话、日历等应用提供了一些接口，通过这些接口可以直接跳转系统应用。

支持跳转系统应用的能力清单

设置

当前支持直接拉起设置应用中如下功能界面，未列出的暂不支持。

• 权限设置： 当应用通过requestPermissionsFromUser()接口拉起权限申请弹框时，如果用户拒绝授权，将无法使用该接口再次拉起弹框，需要调用requestPermissionOnSetting接口拉起权限设置弹窗。二次向用户申请授权中以申请麦克风权限为例，介绍了如何拉起权限设置弹窗。该文档中的示例代码同样适用于应用权限组列表中的所有权限，只需将对应的权限名进行替换即可。以下为开发者经常用到的一些场景。- 拉起位置权限设置弹窗- 拉起相机权限设置弹窗- 拉起图片与视频权限设置弹窗- 拉起音乐和音频权限设置弹窗- 拉起通讯录权限设置弹窗- 拉起日历权限设置弹窗

电话

Telephony Kit提供makeCall()接口，支持跳转到拨号界面，并显示待拨出的号码。

日历

Calendar Kit提供addEvent接口，用于创建日程。

联系人

Contacts Kit提供联系人Picker（Contacts Picker），用于拉起联系人应用，读取联系人数据人。详见选择联系人。

相机

Camera Kit提供了相机Picker （Camera Picker），用于拍照、录像。详见通过系统相机拍照和录像。

文件管理

Core File Kit提供了文件Picker和音频Picker。

• 文件Picker（DocumentViewPicker）：用于访问、保存公共目录中文档类文件。详见选择文档类文件、保存文档类文件。
• 音频Picker（AudioViewPicker）：用于访问、保存公共目录的图片或视频文件。详见选择音频类文件、保存音频类文件。

图库（媒体库）

Media Library Kit提供了照片Picker（PhotoViewPicker），用于访问、保存公共目录的图片或视频文件。详见选择媒体库资源 、创建媒体资源。

06. 用户认证(了解)

6.1 用户认证开发概述

用户认证模块的定义

用户认证模块提供用户认证能力，对应用开发者而言，可使用该模块进行用户身份认证，用于设备解锁、支付、应用登录等身份认证场景。

当前用户认证提供人脸识别和指纹识别能力，设备具备哪种识别能力，取决于当前设备的硬件能力和技术实现。

基本概念

• 人脸识别：基于人的脸部特征信息进行身份识别的一种生物特征识别技术，用摄像机或摄像头采集含有人脸的图像或视频流，并自动在图像中检测和跟踪人脸，进而对检测到的人脸进行脸部识别，通常也叫做人像识别、面部识别、人脸认证。
• 指纹识别：基于人的指尖皮肤纹路进行身份识别的一种生物特征识别技术。当用户触摸指纹采集器件时，器件感知并获取到用户的指纹图像，然后传输到指纹识别模块进行一定的处理后与用户预先注册的指纹信息进行比对，从而识别出用户身份。

运作机制

人脸或指纹识别过程中，特征采集器件和TEE（Trusted Execution Environment）之间会建立安全通道，将采集的生物特征信息直接通过安全通道传递到TEE中，从而避免了恶意软件从REE（Rich Execution Environment）侧进行攻击。传输到TEE中的生物特征数据从活体检测、特征提取、特征存储、特征比对到特征销毁等处理都完全在TEE中完成，基于TrustZone进行安全隔离，提供API的服务框架只负责管理认证请求和处理认证结果等数据，不涉及生物特征数据本身。

用户注册的生物特征数据在TEE的安全存储区进行存储，采用高强度的密码算法进行加密和完整性保护，外部无法获取到加密生物特征数据的密钥，保证了用户生物特征数据的安全性。本能力采集和存储的生物特征数据不会在用户未授权的情况下被传出TEE。这意味着，用户未授权时，无论是系统应用还是三方应用都无法获得人脸和指纹等特征数据，也无法将这些特征数据传送或备份到任何外部存储介质。

约束与限制

• 当前版本提供的用户认证能力包含人脸识别和指纹识别，且只支持本地认证，不提供认证界面。
• 要求设备上具备相应的生物特征采集器，且对于人脸识别要求人脸图像分辨率大于100*100。
• 要求设备上具有TEE安全环境，人脸和指纹等生物特征信息高强度加密保存在TEE中。
• 对于面部特征相似的人、面部特征不断发育的儿童，人脸特征匹配率有所不同。如果对此担忧，可考虑其他认证方式。

6.2 用户认证开发指导

场景介绍

当前用户认证支持人脸识别和指纹识别，可应用于设备解锁、应用登录、支付等身份认证场景。

接口说明

userIAM_userAuth模块提供了用户认证的相关方法，包括查询认证能力、发起认证和取消认证等，用户可以使用人脸、指纹等生物特征信息进行认证操作。具体接口说明可以查阅API参考文档。

在执行认证前，需要指定认证类型和认证等级，查询设备是否支持该认证能力。

表1 用户认证开放能力列表
接口名称功能描述getAvailableStatus(authType : UserAuthType, authTrustLevel : AuthTrustLevel): void根据指定的认证类型、认证等级，检测当前设备是否支持相应的认证能力。getAuthInstance(challenge : Uint8Array, authType : UserAuthType, authTrustLevel : AuthTrustLevel): AuthInstance获取AuthInstance对象，用于执行用户身份认证。on(name : AuthEventKey, callback : AuthEvent) : void订阅指定类型的用户认证事件。off(name : AuthEventKey) : void取消订阅特定类型的认证事件。start: void执行用户认证。cancel: void取消本次认证操作。

07. 密钥管理(了解)

7.1 通用密钥库开发概述

简介

通用密钥库系统（HarmonyOS Universal KeyStore，以下简称HUKS）是HarmonyOS提供的系统级的密钥管理系统服务，提供密钥的全生命周期管理能力，包括密钥生成、密钥存储、密钥使用、密钥销毁等功能，以及对存储在HUKS中的密钥提供合法性证明。

HUKS基于系统安全能力，为业务提供密钥全生命周期的安全管理，业务无需自己实现，利用HUKS的系统能力，就能确保业务密钥的安全。

基本概念

在使用HUKS开发之前，建议了解以下基本概念：

• HUKS CoreHUKS核心组件，承载HUKS的核心功能，包括密钥的密码学运算、明文密钥的加解密、密钥访问控制等。一般运行在设备的安全环境中（如TEE、安全芯片等，不同的厂商有所不同），保证密钥明文不出HUKS Core。
• 密钥会话应用通过指定密钥别名，给当前操作的密钥建立一个会话，HUKS为每个会话生成一个全局唯一的句柄值来索引该会话。它的作用是缓存密钥使用期间的信息，包括操作数据、密钥信息、访问控制属性等。密钥操作一般需要经过建立会话、传入数据和参数、结束会话（中止会话） 三个阶段。

08. 加解密算法库框架(了解)

8.1 加解密算法库框架概述

加解密算法库框架是一个屏蔽了第三方密码学算法库实现差异的算法框架，提供加解密、签名验签、消息验证码、哈希、安全随机数等相关功能。开发者可以通过调用加解密算法库框架，忽略底层不同三方算法库的差异，实现迅捷开发。

框架实现原理

加解密算法库框架提供的组件分为三层：接口层，Framework层和插件层。接口层负责对外提供统一的JS接口，插件层实现针对具体三方算法库的功能，Framework层通过灵活加载插件层的插件适配并屏蔽三方算法库差异。

基本概念

对称密钥

对称密钥使用同一个密钥对数据进行加密解密操作。即对称加密算法中，数据发送方使用加密密钥对明文进行特殊加密算法处理后，使其变成复杂的加密密文发送出去。接收方收到密文后，若想解读原文，则需要使用同一个加密密钥以及相同算法的逆算法对密文进行解密，才能使其恢复成可读明文。

• AES加密AES的全称是Advanced Encryption Standard，是最常见的对称加密。AES为分组密码，分组密码也就是把明文分成一组一组的，每组长度相等，每次加密一组数据，直到加密完整个明文。在AES标准规范中，分组长度只能是128位，也就是说，每个分组为16个字节（每个字节8位）。密钥的长度可以使用128位、192位或256位。
• 3DES加密3DES，也称为 3DESede 或 TripleDES，是三重数据加密算法，相当于是对每个数据块应用三次DES的对称加密算法，它使用3个64位的密钥对数据块进行三次加密。相比DES，3DES因密钥长度变长，安全性有所提高，但其处理速度不高。因此又出现了AES加密算法，AES较于3DES速度更快、安全性更高。

非对称密钥

非对称密钥使用公钥和私钥两个密钥来进行算法操作，公钥对外公开，私钥对外保密。对于加解密操作，一般使用公钥对明文进行加密形成密文，持有私钥的人即可对密文解密形成明文。对于签名验签操作，使用私钥对明文进行签名，公钥持有者可以通过公钥对签名数据做验签，验证数据是否被篡改。

• RSA密钥RSA密钥以极大整数做因数分解的数学难题作为密钥安全性的基石。生成密钥时，首先需要随机出两个大素数p和q，计算n = p * q并将n做为模，再选择一个大于1且小于(p - 1) * (q - 1)的整数e，确保e与(p - 1)*(q - 1)互素，最后计算d，使得e * d - 1为(p - 1)和(q - 1)的倍数，则可得到公钥(n, e)和私钥(n, d)。算法库框架除提供了默认的双素数RSA密钥生成外，还提供了多素数密钥生成方式，可以在密钥生成时通过指定primes参数（PRIMES_2, PRIMES_3, PRIMES_4, PRIMES_5）指定素数个数。多素数密钥的优点是可以减少解密、签名的计算量（中国剩余定理），但相对的劣势是密钥强度会越低，算法库依据OpenSSL的素数使用规则制定了相应规格，具体将在约束与限制章节中说明。
• ECC密钥ECC是一种基于椭圆曲线数学的公开密钥加密算法，其数学基础是利用椭圆曲线上的有理点构成Abel加法群上椭圆离散对数的计算困难性，算法库框架提供了多种椭圆曲线的ECC密钥生成能力。

摘要

消息摘要MD算法是一种能将任意长度的输入消息，通过哈希算法生成长度固定的摘要的算法。消息摘要算法通过其不可逆的特性能被用于敏感信息的加密。消息摘要算法也被称为哈希算法或单向散列算法。

在摘要算法相同时，生成的摘要值主要有下列特点：

• 当输入消息相同时，生成摘要序列相同；
• 当输入消息的长度不一致时，生成摘要序列长度固定（摘要长度由算法决定）；
• 当输入消息不一致时，生成摘要序列几乎不会相同（依然存在相同概率，由摘要长度决定相同概率）；

消息摘要算法主要分为三类：MD，SHA与MAC（详见HMAC章节）

MD算法包括MD2，MD4和MD5。

SHA算法主要包括SHA1，SHA224，SHA256，SHA384，SHA512。

消息验证码

HMAC（Hash-based Message Authentication Code）是一种基于密钥的消息认证码算法。HMAC通过指定摘要算法，以通信双方共享密钥与消息作为输入，生成消息认证码用于检验传递报文的完整性，HMAC生成的消息认证码为固定长度。HMAC在消息摘要算法的基础上增加了密钥的输入，确保了信息的正确性。

随机数

随机数在加解密过程中主要用于临时会话密钥的生成与非对称加密算法中密钥的生成。随机数由硬件生成的硬件随机数生成器或由软件生成的伪随机数生成器进行生成。在加解密的场景中，安全随机数生成器需要具备随机性，不可预测性，与不可重现性。密码学安全伪随机数生成器CSPRNG（Cryptography Secure Random Number Generators）生成的随机数满足密码学安全伪随机性

• 内部状态代表随机数生成器内存中的数值，当内部状态相同时，随机数生成器会生成固定的随机数序列
• 种子（seed）是一个用来对伪随机数的内部状态进行初始化的数据，随机数生成器通过种子来生成一系列的随机序列。

09. 证书(了解)

提供X509证书相关的功能。开发者可以通过调用该系统能力，实现迅捷开发。

证书基本概念

数字证书提供了一种数字验证用户、设备、业务身份的方式。X509证书是国际定制的标准格式。加解密算法库框架部件提供X509证书、X509证书吊销列表、证书链校验器相关的功能。

• X509证书：提供X509证书的解析、序列化、X509证书签名验证、证书相关的信息查询等功能
• X509证书吊销列表：提供X509证书吊销列表的解析、序列化、信息查询等功能
• 证书链校验器：提供证书链校验（不包括证书有效期的校验）、证书链算法名称查询的功能

约束与限制

• 不支持多线程并发操作。

证书规格

• 证书链校验由于端侧系统时间不可信，证书链校验不包含对证书有效时间的校验。如果需要检查证书的时间有效性，可使用X509证书的checkValidityWithDate()方法进行检查。
• 证书格式目前支持DER与PEM格式的证书。

10. 附录