HarmonyOS 2.0安全框架分析

HarmonyOS 2.0终于在几天前正式开源了面向物联网的部分（基于原有的LiteOS），并且引发了大家的关注和激烈讨论。物联网安全是我所在的课题组的一个重要的大方向，所以在这里我会简单分析一下当前HarmonyOS 2.0已开源的安全部分相关的东西，以及提出一些可以改进、扩展的地方。

安全的含义非常广，概括性地说就是保证数据的机密性、完整性和可用性，在此基础上又可以分为多个大方向。以我所在的专业方向为例，可以分为四个部分：

密码学：主要涉及的是密码算法、协议的设计与实现，可以说是信息安全的一大基石；系统安全：主要涉及软件安全、操作系统安全等，大家常听说的软件漏洞、系统漏洞就是在这个范畴内；网络安全：网络安全主要涉及信道安全、web系统安全等，也是大家常听到的一个方向；内容安全：内容安全的重要性主要是近几年才被重视，主要涉及大数据安全、隐私保护、人工智能安全等。

当然这个是培养方案划分的大方向，实际上每一个方向都或多或少涉及其他方向的东西。例如我的方向其实是密码学，但是系统安全、网络安全也是我学习的重点。

而如果以CTF比赛的类型来分类的话，大致有如下的几类：

MISC(Miscellaneous)类型：安全杂项，涉及数据隐写、流量分析、电子取证、人肉搜索、数据分析等等；CRYPTO(Cryptography)类型：即密码学，涉及各种加解密技术，包括信安数学基础、古典加密技术、现代加密技术等；PWN类型：PWN在黑客俚语中代表着攻破、取得权限，例如对Windows、Linux或者浏览器的漏洞利用；REVERSE类型：即逆向工程，涉及软件逆向、程序脱壳、破解等；WEB类型：即常见的Web漏洞，诸如SQL注入、XSS、任意代码执行等漏洞。

在官网的文档里，对于安全的定义如下图：

下面我会根据我的兴趣分析其中的几个部分。

1. 浅谈HarmonyOS安全框架

先说一下看完之后的总体感受：中规中矩。

不是说HarmonyOS不安全，相反，基本上每一个地方都有相应的安全措施，只是采取的方案都比较中规中矩，刚好够用，没有用到什么黑科技或者前沿的密码学。当然这也不能责怪华为，密码学走得太超前了，量子计算机还没看到影，后量子密码已经被研究了十多年了。

1.1 硬件安全

硬件安全方面，主要有三个部分：硬件密钥引擎、启动可信根、硬件隔离可信环境。

硬件密钥引擎指的是安全芯片SE（Secure Element），可进行密码运算、密钥的安全储存、物理真随机数发生等等，计算能力和功耗比较低，并且可以抵抗功耗、电磁辐射等侧信道攻击方式。安全芯片里一般也会有一个操作系统COS（Chip Operating System），也可以进行一些简单的安全运算。例如华为的高端手机和一些中端手机，里面就会内置一颗安全芯片，以达到金融支付级别。做这块比较厉害的是恩智浦、英飞凌，不过国内也有华大信安、复旦微电子等有相关技术积累，而且因为安全的需求，安全芯片涉及的工艺不会很高（40nm顶天了），所以这一块应该不会受到制裁影响。

启动可信根这个很常见了，例如大家现在用的PC里的一般都会有TPM（Trusted Platform Module），用于Secure Boot。它的作用主要是保证操作系统启动时的安全（例如保证操作系统启动时没有被病毒修改数据），一般通过内置一个安全模块（例如上面的安全芯片）或者直接写在ROM里，里面保存证书、签名、哈希校验值，验证启动时的完整性。

硬件隔离可信环境，也就是TEE（Trusted Execution Environment），有很多例子，例如ARM的TrustZone，Intel的SGX等等，一般是在芯片上划出一块单独的区域，与其他地方隔离，只留下安全通信的接口。安全性没有安全芯片高，但是也可提供安全性较高的隔离环境。HarmonyOS据说其实一开始就是用在TEE中的，所以做形式化验证啥的也无可厚非。

硬件安全采用的方案都很成熟，而且这个是其他的安全的基石。手机可以有安全芯片、TEE，PC可以有SGX和TPM，而对于资源受限的物联网设备，则有一些问题：

物联网芯片一般没有TEE；增加一块安全芯片，会增加成本和功耗；将证书、公钥、哈希值等烧录在不可写区域，后续又无法更新，存在风险；并且不能存储私钥信息，密钥管理复杂。

不过官网文档也提到了：

并非所有OpenHarmony设备都强制要求支持可信执行环境，部分运行低敏感业务的瘦资源设备可不做强制要求；可根据实际业务场景选择是否支持可信执行环境，以及实现怎样的可信执行环境。

1.2 系统安全

这部分感觉没有什么好说的。

进程隔离、DAC都比较常规，DAC类似Linux/UNIX，是一种RBAC(Role Based Access Control)。比较有意思的文档中提到的Capability机制，是对Root权限的进一步的细粒度划分，这个感觉挺关键的。

我觉得可能有一些问题的地方：

进程隔离依赖于MMU，而其实挺多嵌入式芯片是没有MMU的，例如ARM Cortex-M的一些芯片。这个或许可以参考uClinux的实现，或者干脆直接放弃这类芯片的支持？Capability机制是一个较大的攻击面，需要注意实现的正确性。

1.3 数据安全

提供了HUKS这个软算法库用于密钥管理和存储服务，提供了证书管理、密钥管理、安全存储和密钥认证服务。

安全存储依赖于安全介质，例如安全芯片，对于物联网芯片有上面硬件安全部分提到的问题。

支持的算法有：

认证加密：AES-128/192/256-GCM

签名验签：ED25519

密钥协商：X25519

消息认证：HMAC-SHA256/512

数据摘要：SHA256/512

可以看出，没有对于国密算法（SM1/SM2/SM3/SM4/SM9/ZUC等）的支持，AES、SHA256等都是国际算法，而根据刚颁布的《密码法》，可能需要增加国密的支持。

X25519和ED25519都是基于Curve25519（或者等价的Twisted Edwards Curves），是已知最快的ECC曲线，可以利用浮点运算进行加速，并且密钥大小比传统ECC小很多（因为其数学结构的特点，只用到了X轴），非常适合物联网环境。可以看出，华为在算法选型时，确实做了挺多调研的（毕竟华为里面还是有一堆密码学大佬的）。

题外话：Curve25519论文提出后的几年内，都没有被受到重视，直到斯诺登事件之后，从爆料中得知NSA在其推荐的椭圆曲线中可能加入了后门，人们寻找替代曲线时，curve25519因其安全性、高效性被人们所知。

1.4 设备互联安全

这个是我非常关注的一个地方。

这是官网文档的架构图：

绑定的流程是：

设备分别生成Ed25519密钥对；利用PIN码和PAKE(Password authenticated key exchange)进行密钥协商，生成会话密钥；通过会话密钥加密彼此的公钥（其实也可以不用加密，算个MAC就行，只要能验证公钥确实来自对方即可）；这里的身份标识公钥指的应该是(设备标识, 公钥)的二元组。

通信的流程是：

通过公钥协商会话密钥；文档没细说会话密钥应该会怎么用，不过一般来说，会将初步协商的密钥进行密钥分散，分为加密密钥、MAC密钥等；使用会话密钥加密通信数据。

从文档描述的密码协议来看，没有明显的问题。通过手动输入PIN、扫描二维码、NFC触碰使得两个设备有了共同的密钥因子，这其实是一种offline的方式。

存在的一个问题是，PIN和二维码必须要是可变的，不能打印贴在设备上，不然就没有意义了，因为每次用的密钥因子是相同的。

个人的一个改进或者扩展建议：增加IBC（Identity Based Cryptography）的支持。这样可以省去交换公钥、会话密钥协商等过程，减少交互流程和通信量。不过这个带来的问题可能是运算成本的增加、密钥size的增大，需要视情况取舍。

1.5 应用安全

这部分没有什么好说的，主要分为两部分：

应用签名管控：PKI体系下的证书体系，经典一套。不过不知道华为有没有CA？应用权限控制：分为动态权限和静态权限，目前分布式应用支持的权限似乎不多，感觉划分的粒度也不够细（例如ohos.permission.DISTRIBUTED_VIRTUALDEVICE这个权限，为“允许应用使用分布式虚拟能力”，这个太粗粒度了）。

2. 代码实现

从代码上可以看出HarmonyOS是比较模块化的，接口定义和实现是分开的。

主要涉及的仓库有：

2.1 security_interfaces_innerkits_app_verify

提供对HAP包签名的验签能力，只有接口定义。

2.2 security_services_app_verify

这个仓库提供对HAP包签名的验签能力。

密码运算基于mbedtls，并且在代码中写死了根证书（有两个根证书，一个用于测试，另一个应该是正式环境的）。这种方式可能不太好，不支持证书的更新、安装、删除等操作，不过考虑到物联网环境的受限，加一个证书管理服务确实有点奢侈。

2.3 security_interfaces_innerkits_huks_lite

Internal interfaces of the key management service，密钥管理服务功能内部接口，只有接口定义。

2.4 security_services_huks_lite

上面提到的HUKS的实现。

接口设计了几种不同类型的密码原语以及对应的数据格式：

enum hks_cmd_type { HKS_GENERATE_KEY = 0, HKS_GENERATE_KEY_EX, HKS_SIGN, HKS_VERIFY, HKS_ENCRYPT, HKS_DECRYPT, HKS_IMPORT_KEY, HKS_EXPORT_KEY, HKS_GENERATE_RANDOM, HKS_KEY_AGREEMENT, HKS_KEY_DERIVATION, HKS_HMAC, HKS_HASH, HKS_BN_EXP_MOD, HKS_NMI_GENERATE_SYMMETRIC_KEY, HKS_SYMMETRIC_ENCRYPT_DECRYPT, ​ HKS_CMD_MAX, /* new cmd type must be added before HKS_CMD_MAX */ };

比较意外的是，居然有大整数模幂运算的类型（HKS_BN_EXP_MOD）。

以上几种类型基本涵盖了密码学里的基本原语（primitives），不过，因为现代密码学已经发展到非常复杂了，如何进行扩展是需要仔细考虑的。

2.5 security_interfaces_innerkits_secure_os

libteec库函数接口定义，提供标准TEE Client接口，实现与TEE的交互。

2.6 security_frameworks_secure_os

libteec库函数实现libteec库函数实现，提供标准TEE Client接口，实现与TEE的交互。

2.7 security_services_secure_os

TEE的代理服务，感觉没啥好说的。

2.8 security_interfaces_kits_iam_lite

应用权限管理的接口定义。

2.9 security_interfaces_innerkits_iam_lite

IPC通信鉴权的内部接口。

2.10 security_services_iam_lite

Application permission management and IPC authentication，提供应用权限管理及IPC通信鉴权能力。

提供JS的binding，整体感觉应该借鉴了Android的权限管理。

enum GrantTime { INUSE, ALWAYS }; ​ enum GrantType { USER_GRANT = 0, SYSTEM_GRANT = 1, }; ​ enum IsUpdate { FIRST_INSTALL = 0, UPDATE = 1, }; ​ enum IsRestricted { RESTRICTED = 0, NOT_RESTRICTED = 1, };

2.11 security_interfaces_innerkits_hichainsdk_lite

提供设备互连安全认证能力内部接口定义，也就是所谓的HiChain。

2.12 security_services_hichainsdk_lite

提供设备互连安全认证能力的实现。

比较复杂，不过流程基本就是文档中图所描述的。

2.13 security_interfaces_innerkits_crypto_lite)

数据加解密的内部接口，不知道为啥是空的。

2.14 security_frameworks_crypto_lite

数据加解密的能力模块，目前只看到有AES和RSA的实现；也有JS的binding。

3. 扩展

将IBC（国密SM9）结合进HarmonyOS的安全框架中，简化一些流程；分布式场景可以结合群签名、门限签名签名、代理签名等密码协议，保证数据的安全性，并且可以扩展到非信任、匿名环境；

4. 总结

目前HarmonyOS采用的安全框架、密码协议等，有针对物联网环境进行了调研、优化；HarmonyOS的安全框架没有明显的协议漏洞；有一些可以针对性扩展的地方。