鸿蒙安全模块分析——CS之间是如何通讯的？(正篇)

进入正题——CS之间是如何通讯的呢？

1. 密钥的类型

安全中最重要的就是密钥，那么鸿蒙的security_huks中有多少种类型不同的密钥呢？
这里简单的列出一些在阅读代码中遇到的密钥类型：

1. rootKey
2. genKey
3. AgreeKey
4. DeriveKey
5. WrapKey
6. UnWrapKey
7. RawKey
8. MainKey
9. MasterKey
10. ImportKey
11. ExportKey
12. PublicKey
13. PrivateKeY

具体这些密钥的作用和联系，我们暂时还没有完全弄清楚，所以这里就不献丑，等到后面深入阅读后再做分享

下面开始CS的分析

2. framwork/huks_lite

首先从名字看这是一个轻量版本的实现
从层次框架中

我们可以看到其主要分为两部分：common和soft_service
1. 可以看到它并没有单独的os_dependency文件来定义或者适配ipc之间的通讯(我猜想是场景不需要，所以轻装上阵)

2. 在common中函数写的很紧凑，具体的一些通用函数都写在huks_common.c中，并没有专门独立出文件来进行参数的检查或者算法的实现等(与huks_standard对比)，但是对于类型转换和日志输出做了单独的封装

3. 在软服务中重点实现了密钥文件的存储和读写，在huks_service中实现了服务端的功能

4. 在轻量版中CS的通讯方式是通过access的授权建立连接，从而获得一系列可支持的服务

3. framework/huks_standard

标准版的实现
1. 在common中分别封装了参数检查、paramSet的创建和维护

2. 在core中实现了服务的local化，通过全局变量进行服务的实现

3. 两大框架OpenSSL和Mbedtls的鸿蒙安全模块功能实现

4. 最最重要的模块os_dependency，实现了非常重要的客户端Poxy代理的申请以及服务端SA的获取以及数据切分和序列化存储的功能，结合另一个文件夹service的代码，我们认为标准版的CS通讯流程应该是这样

当需要通讯的时候，客户端向服务端请求代理，通过该代理进行客户端和服务端的通讯；通常服务端会在系统能力管理者(SAMgr)中注册系统能力(SA),通过该SA，SAMgr会提供相应的API供代理使用，当客户端发送request到代理的时候，服务端从中提取code cmd context key等信息后回复response将数据附在reply中(注：当传输的数据过大时需要使用数据切分功能函数将数据分块传输处理)

4. Service

最后一块是huks_engine和huks_service的实现

1. 服务端的参数检查、用于两大框架OpenSSL和Mbedtls的X509标准格式转换、操作handler、密钥和文件管理都以单独的.c文件实现于文件夹huks_service/core中

2. 在os_dependency中完成信息的验证并调用core中封装好的函数完成服务的提供并封装为response进行应答

3. huks_engine中实现了对keyBlob的构造以及用户认证相关

4. 值得一提的是sa中的hks_sa.cpp，作为Server实现的.cpp文件，实现了init, OnremoteRequest等基础函数

Init：
	Publish(GetInstance)：注册SA并且获取autoLock

	HksServiceInitialize：
							HksUpgradeData：对文件进行更新
							HksAccessInitialize：rkc的初始化，包括众多g_hksRkcCfg属性的初始化
							HksLoadFileToBuffer：已存在的相关文件读入缓冲区

OnStart: 两个函数涉及running_state的改变
OnStop:

OnRemoteRequest:远端服务请求的处理，调用CanRequest进行信息确认和通道验证并将request中的对应请求操作code通过handler实现

5. 服务端可提供的服务

• Hash单向散列函数的计算
• BnExp大数计算
• Mac消息验证算法
• AES加密算法
• RSA加密算法
• MD5 SHA消息摘要算法
• 数字签名算法 ED25519 X25519 ECC ECDSA
• 密钥交换 ECDH Curve25519
• 签名验证