未验证 提交 0de41f24 编写于 作者: W wkyrong 提交者: Gitee

update zh-cn/device-dev/subsystems/subsys-security-huks-guide.md.

Signed-off-by: Nwkyrong <wangkairong@huawei.com>
上级 fff2a5ac
......@@ -4,50 +4,65 @@
### 功能简介
OpenHarmony通用密钥库系统(英文全称:Open**H**armony **U**niversal **K**ey**S**tore,以下简称HUKS)是OpenHarmony提供的系统级的密钥管理系统服务,提供密钥的全生命周期管理能力,包括密钥生成、密钥存储、密钥使用、密钥销毁等功能,以及对存储在HUKS中的密钥提供合法性证明。在HUKS软件架构中,承载着核心密钥管理功能HUKS Core一般运行在设备的安全环境中(比如TEE、安全芯片等)。由于不同厂商设备安全环境不同,为了保证上层架构归一,使得HUKS Core为了保证HUKS Service密钥的安全存储和安全使用环境是密钥安全最重要的约束,如对明文密钥的存储和使用不能出现在非安全环境中,需要保证在安全环境中使用(比如TEE,安全芯片等);本文档介绍了开发者在OpenHarmony HUKS架构的基础上适配安全存储和安全使用环境的步骤,以及如何去验证适配是否正确,以保证API接口的兼容。
OpenHarmony通用密钥库系统(英文全称:Open**H**armony **U**niversal **K**ey**S**tore,以下简称HUKS)是OpenHarmony提供的系统级的密钥管理系统服务,提供密钥的全生命周期管理能力,包括密钥生成、密钥存储、密钥使用、密钥销毁等功能,以及对存储在HUKS中的密钥提供合法性证明。在HUKS的分层架构中,处于最底层的HUKS Core承载着密钥管理核心功能,一般运行在设备硬件安全环境中(比如TEE、安全芯片等)。由于不同厂商硬件安全环境不同,HUKS Core的实现方式也不尽相同,为了保证上层架构归一,HUKS Core定义了一套HDI接口(硬件设备统一接口),以保证HUKS Service调用HUKS Core API接口的兼容。
HUKS支持密钥全生命周期管理,包括以下特性:
HUKS Core支持以下特性:
1. 密钥生成/导入
1. 生成密钥
2. 密钥存储
2. 外部导入密钥
3. 密钥使用(加解密、签名验签、密钥派生、密钥协商、哈希、密钥访问控制等)
3. 密钥操作(加密解密、签名验签、密钥派生、密钥协商、消息认证码等)
4. 密钥销毁
4. 密钥访问控制
### 基本概念
5. 密钥证明
6. 芯片平台公钥导出
- 服务层(HUKS Service)
### 基本概念
HUKS Service为系统常驻服务,为应用提供应用身份校验、密钥文件(密文)管理、系统状态监听等,核心的密钥生成、密钥使用和访问控制等功能依赖HUKS Core提供。
- **HUKS Core**
HUKS核心组件,承载HUKS的核心功能,包括密钥的密码学运算、明文密钥的加解密、密钥访问控制等。一般运行在设备的安全环境中(如TEE、安全芯片等,不同的厂商有所不同),保证密钥明文不出HUKS Core。
- 核心层(HUKS CORE)
- **密钥会话**
提供密钥管理服务的核心功能模块,需要保证该模块处于安全环境中且密钥全生命周期明文不出HUKS Core模块
应用通过指定密钥别名,给当前操作的密钥建立一个会话,HUKS为每个会话生成一个全局唯一的句柄值来索引该会话。它的作用是缓存密钥使用期间的信息,包括操作数据、密钥信息、访问控制属性等。密钥操作一般需要经过**建立会话、传入数据和参数、结束会话(中止会话)** 三个阶段
- 可信执行环境(Trusted Execution Environment)
- **可信执行环境(Trusted Execution Environment)**
通过划分软件和硬件资源的方法构建一个安全区域,使得安全区域内部的程序和数据得到保护。这种划分会分隔出两个执行环境——可信执行环境和普通执行环境。每个执行环境有独立的内部数据通路和计算所需存储空间,保证可信执行环境里的信息不会向外泄露。普通执行环境的应用不能访问可信执行环境的资源,可信执行环境中的应用在没有授权的情况下也无法相互访问。
- 三段式(Init-Update-Finish)
Init:初始化密钥操作数据。
## 实现原理
密钥会话是HUKS中承载密钥使用的基础,它的主要作用是初始化密钥信息、缓存业务数据等。对数据的密码学运算和对密钥密文的加解密都是在HUKS Core中进行,以此保证密钥明文和运算过程的安全。
Update:分段操作数据并返回结果,或追加数据。
**图1** HUKS运行机制
Finish:结束分段操作或追加数据,返回结果。
![huks_architect](../../application-dev/security/figures/huks_architect.png)
### 实现原理
## 约束与限制
以密钥的生成为例介绍HUKS Service与HUKS Core的通信过程,其他密钥操作类似:
上层应用通过密钥管理SDK调用到HUKS Service,HUKS Service再调用HUKS Core,HUKS Core会调用密钥管理模块生成密钥。之后HUKS Core使用基于RootKey派生的加密密钥对生成的密钥加密再传给Service侧,Service侧再以文件形式存储加密后的密钥。
- **密钥不出安全环境**
![HUKS密钥生成流程图](figures/HUKS-GenerateKey1.png)
HUKS的核心特点是密钥全生命周期明文不出HUKS Core,在有硬件条件的设备上,如有TEE(Trusted Execution Environment)或安全芯片的设备,HUKS Core运行在硬件安全环境中。能确保即使REE(Rich Execution Environment)环境被攻破,密钥明文也不会泄露。因此,HUKS Core API所有函数接口密钥材料数据只能是密文格式。
- **系统级安全加密存储**
### 约束与限制
必须基于设备根密钥加密业务密钥,在有条件的设备上,叠加用户口令加密保护密钥。
- **严格的访问控制**
只有合法的业务才有权访问密钥,同时支持用户身份认证访问控制以支持业务的高安敏感场景下安全访问密钥的诉求。
- **密钥的合法性证明**
业务提供硬件厂商级别的密钥的合法性证明,证明密钥没有被篡改,并确实存在于有硬件保护的HUKS Core中,以及拥有正确的密钥属性。
- **密钥材料格式**
导入/导出密钥时(包括密钥对、公钥、私钥),密钥材料的数据格式必须满足HUKS要求的格式,具体各个密码算法密钥材料见[密钥材料格式](huks-appendix.md#密钥材料格式)
* HUKS的实现需要在可信执行环境中实现,保证密钥管理和操作的可信可靠。
* HuksHdiAttestKey返回的证书链应该按照业务证书、设备证书、CA证书和根证书的顺序组装,在每项证书之前还需要加上证书的长度。证书链组装完成后添加整个证书链的长度组装成Blob格式。证书的具体格式如要自己实现应与服务器侧解析的格式相对应。
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册