鸿蒙源码分析（七十四）---安全子系统

比赛中提到的安全子系统模块huks是一种通用密钥管理服务，它为应用程序提供KeyStore和Crypto API，以执行密钥管理，加密和解密操作。包括密钥管理及密钥的密码学操作等功能。HUKS所管理的密钥可以由应用导入或者由应用调用HUKS接口生成。
主要就是三大部分：

HUKS SDK层：提供HUKS API供应用调用。
HUKS Service层：实现HUKS密钥管理、存储等功能。
HUKS Engine层： HUKS核心模块，负责密钥生成以及加解密等工作。对于L2设备，该部分模块在商用场景下必须在安全环境下运行，包括TEE或者具备安全能力的芯片等。由于安全环境需要特定硬件支持，因此在开源代码中为模拟实现。

security_huks
├── build                             # 编译配置文件
├── frameworks                        # 框架代码, 作为基础功能目录, 被interfaces和services使用.
│   └── huks_standard                 # huks标准模块, 即表示L2的HUKS模块
│   └── huks_lite                     # huks L0和L1代码实现
│   └── crypto_lite                   # 加解密实现
├── interfaces                        # 接口API代码
│   └── innerkits
│       └── huks_standard             #标准内核下实现
│       └── huks_lite				  #轻量级系统
└── services
    └── huks_standard				  #标准系统下的服务实现

上面是huks的实现，但是这一模块也是挂在安全模块下面。下面我们来看看安全模块主要涉及哪些内容。

安全模块

简介

本章节主要是为了提供样例给开发者展示如何去使用已有的安全机制来提升系统的安全能力，包括安全启动、应用权限管理、IPC通信鉴权、HUKS、HiChain、应用签名验签。

文件目录如下

security
├── framework
│     ├── appverify    应用签名验签
│     ├── crypto_lite    加解密
│     ├── hichainsdk_lite    设备认证能力
│     ├── huks_lite    秘钥管理和证书管理
│     ├── secure_os    安全OS
├── interface    接口目录
│     ├── innerkits    内部kit目录
│     │     ├── appverify    应用签名验签
│     │     ├── crypto_lite    加解密
│     │     ├── hichainsdk_lite    设备认证
│     │     ├── huks_lite    秘钥管理和证书管理
│     │     ├── iam_lite    应用权限管理
│     │     ├── secure_os    安全OS
│     ├── kits    外部kit目录
│     │     ├── iam_lite    应用权限管理
├── services    具体实现
│     ├── iam_lite    应用权限管理
│     ├── secure_os    安全OS

但是这种安全模块代码并不是在所有设备上都会包括，而是基于不同内核代码功能部分也会不同。比如上述安全能力主要是在Cortex-A或同等处理能力设备上使用，在Cortex-M或同等处理能力设备上只有HUKS(Huawei Universal KeyStore Service，华为通用密钥存储管理服务)和hichain（身份认证平台技术）。比赛中我们主要分析的就是huks部分

应用权限

应用权限是软件用来访问系统资源和使用系统能力的一种通行方式，存在涉及个人隐私相关功能和数据的场景，例如：访问个人设备的硬件特性，如摄像头、麦克风，以及获取个人数据，如通讯录，日历等存储的信息等。操作系统通过应用权限管理来保护这些数据以及能力。
权限字段
在这里插入图片描述

IPC鉴权

在Samgr中注册的系统服务如果通过进程间通信的方式暴露接口给其他进程访问，需要配置相应的访问控制策略。若不进行相关配置，访问会被拒绝。
配置方式：在头文件base/security/services/iam_lite/include/policy_preset.h中配置访问策略。1. 定义各个Feature的策略 2. 将Feature的策略加到全局策略中

Eg. 比如当前需要为BMS服务配置访问策略，BMS在Samgr中注册的service为bundlems，注册的Feature为BmsFeature。
一、首先定义Feature的策略，可配置多个Feature，每个Feature可以配置多个访问策略，策略的声明方式参考图2
图 1 Feature策略示例
在这里插入图片描述
访问策略有三种类型：
图2 访问策略结构体

1 type为RANGE类型：允许某个特定范围UID的进程访问，需要指定uidMin和uidMax
2 type为FIXED类型：允许指定的几个UID的进程访问，需要指定fixedUid，最多配置8个
3 type为BUNDLENAME类型：只允许特定的应用访问，需要指定bundleName（包名）

二、将定义的Feature的策略加配到全局策略中，需要配置feature数量，注册参考图4
图 3 feature策略注册
在这里插入图片描述
UID分配规则

Init/foundation进程：0
appspawn进程：1
Shell进程：2
kitfw进程：3
其他内置服务向后递增…最多到99
系统应用（如settings）：100 ~ 999
预置厂商应用（如钱包、淘宝）：1000 ~ 9999
普通三方应用：10000 ~ INT_MAX

huks再介绍

在分布式场景下，不同终端设备的硬件能力和运行系统环境都不尽相同，这些设备在分布式场景下，均需要建立信任关系，最典型的应用即是HiChain可信互联。那么就需要这样一个统一的密钥管理服务，来做到接口一致，密钥数据格式一致，同时提供业界标准的加解密算法实现。HUKS基于此来提供统一的密钥管理、加解密等能力。
HUKS模块整体分为北向接口，南向适配层，以及核心的功能模块：

HUKS 北向接口：提供统一的对外API，用C语言实现，保持所有设备一致；主要包括密钥生成API、加解密API等
HUKS Core Module：依赖HAL层，提供核心功能：加解密、签名验签、密钥存储等；
HUKS HAL层：屏蔽底层硬件和OS的差异，定义HUKS需要的统一底层API。主要包括平台算法库、IO和LOG等；