Android与鸿蒙系统安全（三）_鸿蒙系统st(security target)文档

八、鸿蒙安全系统

OpenHarmony操作系统是一个开放的系统，开发者可以通过OpenHarmony开发灵活的服务和应用，为开发者和使用者带来便利和价值。为了达到这一目的，OpenHarmony提供了一个可以有效保护应用和用户数据的执行环境。

在这个执行环境中，芯片的安全能力、系统的安全能力、以及上层的安全服务一起协作，从硬件安全、系统安全、数据安全、设备互联安全、应用安全、安全更新多个维度提供安全保障。鸿蒙采用的微内核+外核的设计，微内核没有被Root的概念，同时外核和内核是分开的，互相隔离，提升了操作系统的安全

 

1.硬件安全 安全机制 启动可信根

OpenHarmony设备采用PKI（Public Key Infrastructure）体系保护软件完整性，确保设备运行来源合法、软件未被篡改。

在设备启动流程中，逐级进行软件签名校验形成安全启动链，任何一个环节的签名校验不通过即终止设备启动；安全启动链中最初执行签名校验的软硬件实体，需确保自身的合法、未被篡改。该实体即为设备的启动可信根。启动可信根可为固化在ROM中的一段代码，这段代码在芯片制造环节固化到芯片中，芯片制造完成后软件不可更改，在设备上电初始化的过程中，最先执行这段ROM中的代码，并由这段ROM代码执行后续的软件签名校验。

ROM中的代码在执行签名校验时，需确保用于校验的PKI公钥的合法性，OpenHarmony设备可采用eFuse/OTP等存储介质来存储公钥（如公钥哈希值），来保护公钥自身的合法性。公钥一般在设备制造环节，烧录到设备的eFuse/OTP中。

硬件隔离的可信环境，遵循了可信计算系统的设计理念。可信环境内外形成了两个世界：可信世界与不可信世界，两者之间存在清晰而明确的隔离边界；OpenHarmony设备在可信环境中实现了核心敏感数据的保护机制，可确保即使不可信世界的操作系统存在漏洞且被利用，也依然能确保可信环境中敏感数据的安全。

OpenHarmony设备的可信环境，基于硬件的安全隔离机制构建，在不同的OpenHarmony设备上芯片隔离机制略有差异，较为通用的方法是采用ARM的TrustZone技术。在部分Risc-V芯片平台上，也可能采用独立安全核的形式来构建可信环境。

硬件密钥引擎

密码学是信息安全的基础。数据加解密对计算机设备的核心诉求是：高效、安全。硬件加解密技术利用计算机硬件辅助软件，甚至直接取代软件，来处理数据的加解密。相比由软件实现的加解密计算，硬件实现的加解密计算更高效、更安全。

由硬件来实现加解密处理，当加解密引擎工作的时候CPU可以并发地继续执行其他计算任务，因此硬件加解密引擎可以带来极大的性能提升，同时降低CPU负载。此外，硬件密钥引擎可以带来更高的安全性，设计良好的硬件密钥引擎，哪怕软件被攻破也依然可保护密钥不泄露，甚至可对抗电磁、辐射等物理侧信道攻击。

OpenHarmony设备支持硬件密钥引擎，支撑OpenHarmony系统进行数据加解密、证书验签、哈希计算等计算任务，可支持AES/RSA等主流的密码学算法。

安全启动是整个系统安全的基础，通过采用数字签名和完整性校验机制，从芯片内部固化的可信启动根开始，逐级校验每一层软件的完整性和合法性，确保最终启动的操作系统软件是厂家提供的正确合法的软件，防止攻击者对系统软件做恶意的篡改和植入，为整个系统提供初始安全的基础运行环境。
推荐做法

• 自主访问控制和Capability机制是控制资源被谁可以访问的机制，建议所有权限设置都采用最小权限原则。
• 安全启动必须要开启，信任根必须是基于芯片的不可更改的形式存在，并且在有安全升级的情况下，必须考虑安全升级后对于安全启动的影响，也就是安全升级后必须要更新对应镜像文件的签名信息或者hash值。

2.数据安全 安全机制

HUKS（Huawei Universal Keystore Service），提供了密钥管理、证书管理服务，当前在OpenHarmony上主要提供密钥管理服务，用于支撑HiChain(设备身份认证平台)的基础设备认证。如下是HUKS的功能结构图：

HUKS在使用中有如下约束：

• 密钥安全存储：密钥要求存储于安全存储区域，数据不可以修改，恢复出厂设置时出厂预置的密钥不能被删除。
• 密钥访问安全：OpenHarmony通过将不同应用数据保存在不同的位置，来实现应用间数据的隔离。通过参数结构体中包含UID和进程ID，来实现不同应用间的数据隔离。

不支持并发访问：HUKS本身不考虑多个应用同时调用的情况，因为HUKS只是一个lib库，也不考虑资源的互斥。如果有多个应用都会用到HUKS服务，那么应该由每个应用各自链接一份HUKS库，并由业务传入持久化数据存储的路径，以实现应用间的数据存储分开。数据存储在各应用各自存储目录下。

3.设备互联安全

为了实现用户数据在设备互联场景下在各个设备之间的安全流转，需要保证设备之间相互正确可信，即设备和设备之间建立信任关系，并能够在验证信任关系后，搭建安全的连接通道，实现用户数据的安全传输。设备之间的信任关系在本文档中涉及IoT主控设备和IoT设备之间建立的可信关系。设备间可信关系建立的流程如下图所示：

IoT设备互联安全

设备互联支持基于OpenHarmony的IoT设备（如AI音箱、智能家居、智能穿戴等设备）与IoT主控设备间建立点对点的信任关系，并在具备信任关系的设备间，搭建安全的连接通道，实现用户数据端到端加密传输。

IoT主控设备的IoT业务身份标识

IoT主控设备为不同的IoT设备管理业务生成不同的身份标识，形成不同IoT管理业务间的隔离，该标识用于IoT主控设备与IoT设备之间的认证以及通信。IoT业务身份标识为椭圆曲线公私钥对（Ed25519公私钥对）。

4.应用安全 安全机制 应用签名管控

OpenHarmony应用的安装需要首先对包的完整性进行校验，具体策略是在开发阶段完成开发和调试后对安装包进行签名，这个签名需要使用指定的私钥，这个私钥就是跟验签用的公钥是一对的，一般的做法是OEM厂商生成一对公私钥，然后将公钥信息预置到设备中，而私钥就放在一个不联网的本地服务器上，这样可以确保私钥被泄露的风险尽量小，而应用在完成开发后就可以通过外置设备（例如USB）上传安装包到存放私钥的服务器上计算签名并下载签名结果到外置设备上。而安装应用时首先计算包的Hash值，一般采用SHA256算法，然后使用hash值和签名信息以及预置公钥进行验签，只有验签通过的应用才能安装。

除了要证明应用来自云端认证过的，还需要证明来源，即这个应用来自合法开发者开发的，具体做法是，开发者向云端申请开发证书，开发完成后，用开发证书进行自签名，设备端存放这个证书的上一级证书，所以安装过程中，对自签名信息做校验，确保开发者的合法性。

应用权限控制

由于OpenHarmony系统允许安装三方应用，所以需要对三方应用的敏感权限调用进行管控，具体实现是应用在开发阶段就需要在profile.json中指明此应用在运行过程中可能会调用哪些敏感权限，这些权限包括静态权限和动态权限，静态权限表示只需要在安装阶段注册就可以，而动态权限一般表示获取用户的敏感信息，所以需要在运行时让用户确认才可以调用，授权方式包括系统设置应用手动授权等。除了运行时对应用调用敏感权限进行管控外，还需要利用应用签名管控手段确保应用安装包已经被设备厂商进行了确认。

5.分布式数据服务

分布式数据管理子系统支持单设备的各种结构化数据的持久化，以及跨设备之间数据的同步、共享功能。开发者通过分布式数据管理子系统，能够方便地完成应用程序数据在不同终端设备间的无缝衔接，满足用户跨设备使用数据的一致性体验。

分布式数据服务支持数据跨设备相互同步，为用户提供在多种终端设备上一致的数据访问体验。通过结合帐号、应用和数据库三元组，分布式数据服务对数据进行隔离。在通过可信认证的设备间，分布式数据服务支持数据相互同步，提供跨设备的数据访问。

在搭载HarmonyOS的分布式终端上，可以保证“正确的人，通过正确的设备，正确地使用数据”。

通过“分布式多端协同身份认证”来保证“正确的人”。

通过“在分布式终端上构筑可信运行环境”来保证“正确的设备”。

通过“分布式数据在跨终端流动的过程中，对数据进行分类分级管理”来保证“正确地使用数据”

九、鸿蒙系统EAL5+认证

1.认证的鸿蒙是什么

华为的ST文档。本次认证产品名称Hongmeng V1.2, TOE（评估对象）范围明确限定在TEE的一部分，硬件平台和部分安全固件（firmware和bootloader）并不在评估范围内。

但是，华为是有自己的TEE的，名称Huawei iTrustee v2.0,并且在2018年2月获得了EAL2+的认证。鸿蒙和iTrustee有什么区别，iTrustee是符合GP标准的TEE，因为其遵循的规范是有GP组织发布的；而鸿蒙，应该是一个广义上的TEE，即一个专注于安全的独立操作系统，但是和GP标准的相关性不大，毕竟TEE的全称是可信执行环境，只要专注安全可信的操作系统，都可以叫做TEE。华为的ST文档。本次认证产品名称Hongmeng V1.2, TOE（评估对象）范围明确限定在TEE的一部分，硬件平台和部分安全固件（firmware和bootloader）并不在评估范围内。

鸿蒙评估对象（TOE）

CC全称Common Criteria for Information Technology Security Evaluation，信息技术安全评估准则，这是一个被国际各国普遍认可的信息安全评估标准，CC将信息安全等级从低到高分为7个等级EAL1-EAL7。

任何信息安全产品都可以使用CC作为评估标准，但是现实的安全产品从软件的操作系统，到硬件的芯片，从打印机到路由器，包罗万象，靠一个标准去限定所有产品，没有可操作性。所以CC作为信息安全评估的根，更应该被理解为一种方法论，提供了一种评估产品信息安全的方法。具体对于每一类产品的评估，需要定义更具体的评估标准，这就是PP protection profile，保护轮廓。

PP是对一类产品的评估标准，其完全沿用的cc的评估方法，只是会更加具体的定义了这类产品的资产、安全问题和安全功能。PP规范都是行业内所有曾参者共同决定的，在中国PP一般就是国标，例如安全芯片的PP就是GB-22186, 智能卡软件的PP就是GB-20276。PP的检测机构都是按着PP对产品进行量化检测案例的。

ST是安全目标，是产品厂商出具的问题，描述本产品是如何符合PP的描述性文档。

现在回到开始的问题上，为什么业内普遍认为TEE只能过EAL2+的认证？因为TEE类产品的PP就只有EAL2+的，这份PP是由GP组织在2016年定义的，是GP组织内所有成员国专家群策群力的结果，至于为什么各位专家只搞出了一个EAL2+的标准，没有定义更高安全评估等级的PP，从两方面去考虑这个问题，必要性和可行性。

必要性就需要从TEE的定位来说了，TEE本身定位就是比开放的操作系统（REE）安全，但又要比现在的安全实体好用。开放的操作系统(例如Android)没有安全性考虑，设计的目的就是功能强大，性能优异，用户体验好；安全实体则只专注于安全，普遍安全评估等级是EAL4+起步，但是非常难用，完全没有用户体验可言，连接口都是固定的那几个。所以这时候就需要TEE来兼顾安全与功能。所以从定位而言，TEE的等级不需要太高，至少没必要到达安全实体所需要的EAL4+级别。

可行性而言，去实现TEE的EAL4+等级，也是可以的，但是牺牲性能换安全，这不是TEE应该做的事情，那么不牺牲性能去实现高安全等级呢？很难！

TEE的性能优势是因为和REE共用硬件设备，虽然做了底层硬件的隔离（主要是逻辑的）和访问控制，但是毕竟底子还在，比起安全实体全部独立的物理硬件而言，性能强了几个数量级。但是正因为如此，在没有对安全进行特殊设计的物理硬件环境下，实现TEE的安全，是空中楼阁，所以普遍的认为是TEE不具备防物理攻击的能力。TEE虽然也可以假设物理环境的安全，但是这个安全是没办法保证的，所以GP的专家并没有去假设这个无法被验证的物理安全。综上所述，TEE很难达到EAL4+的水平，EAL4+是一个分水岭，这是安全实体SE的起始安全等级，只有达到EAL4+才可以应用在SIM、银行卡等高安全领域。

2.华为的鸿蒙为什么可以过EAL5+认证？

我们先看看鸿蒙过的是什么的标准的EAL5+，从ST和证书中都能清楚发现，鸿蒙并不遵循任何PP，是按着CC进行检测认证的。

鸿蒙ST里提到“this security target does not claim conformance to any PP”，PP是对一类产品定义的评估标准，而鸿蒙声明并不遵循任何已有的PP，那么就意味华为认为鸿蒙是一个全新的产品，和市面上已经被录入规范的产品都不一样。因为是全新产品，所以遵循CC的方法论，自行定义资产，威胁，安全功能，这样的认证含金量显然要比使用PP的认证的低很多，毕竟PP是很多专家合作讨论数个月或者数年的结晶。

鸿蒙的ST文档上很讨巧的几个点

1 鸿蒙的评估对象范围

鸿蒙的评估对象是完全的软件，不包括硬件和bootloader，这里就已经和GP_TEE的PP有了很大的区别，GP_TEE的PP规定的评估对象是包括部分的硬件资源的，因为GP的专家们知道，没有硬件安全基础的安全，是空中楼阁。

2 鸿蒙定义的威胁

鸿蒙只定义了两个威胁：T.UNAUTHORIZED ACCESS和T.QUEUE SKIPPING，简单的说，一个是访问控制的威胁，一个是进程插队的威胁。偌大的一个操作系统只面临两类威胁，实在是不能理解中间的内涵。威胁也是CC体系中核心的存在，所有的安全功能，保障措施全部都是围绕着如何抵御威胁展开的，威胁越少，安全功能越好设计。

GP_TEE的定义的威胁就很多，T.ABUSE_FUNCT、T.CLONE、T.FLASH_DUMP、T.IMPERSONATION、T.RAM 、T.ROGUE_CODE_EXECUTION、T.PERTURBATION、T.RNG、T.SPY、T.TEE_FIRMWARE_DOWNGRADE、T.ROLLBACK、T.STORAGE_CORRUPTION、T.TA_PERSISTENT_TIME_ROLLBACK、 T.ABUSE_DEBUG。威胁多，安全功能就更难设计，相应的所能达到的评估等级也就不容易太高。

为什么鸿蒙能达到EAL5+的关键，华为使用了极其完备的安全设计，能抵御这两个威胁。但是问题来了，作为一个承载安全的操作系统，它真的不会受到来自物理攻击的威胁吗？内存有没有可能泄露机密信息？FLASH会不会被越权访问？随机数发生器会不会被篡改？其他的威胁到底是不是威胁？如何保障安全资产不受到其他威胁的破坏？这些问题，估计只有定义资产和威胁的人才清楚。

3 鸿蒙定义的假设

假设是产品安全的一个前置条件或者说是一个免责声明，举个例子，防盗门是安全的，这需要假设在和平环境下，破坏者只是平民；如果在战场上，破坏者是军队，那么这个防盗门是不可能安全的。

鸿蒙的假设是两个：A.TRUSTWORTHY PERSONNEL、A.ENVIRONMENT和A.TRUSTED PROCESS，其中想说说第二个假设A.ENVIRONMENT，描述如下：

l The bootloader shall initialize the hardware so the TOE starts in a safe and secure state.

2 The memory managed by the TOE, and the Kirin 970/980 SoC required by the TOE shall be protected in confidentiality and integrity from the outside of the TOE.

3 The bootloader and ARM Trusted Firmware shall be protected in integrity from the outside of the TOE.

简单理解就是鸿蒙安全，需要假设的条件是启动时bootloader要验证硬件以保证鸿蒙在安全状态，内存要被外部保证机密性和完整性，bootloader和防火墙也要被外部保障是完整的。

综上所述，华为对鸿蒙的评估对象范围上，排除了硬件和固件，威胁定义上只选择了两个威胁，排除了物理攻击，假设上又假设了固件是安全的，所以从安全评估的角度看，EAL5+的唯一难点，就剩下半形式化了。

4鸿蒙的EAL5+，是否可以说明其安全性比肩安全实体了？

安全实体SE，普遍的安全评估等级都是EAL4+，比鸿蒙还低。安全实体可以做成银行卡，SIM卡存放个人密钥，那么评估等级更高的鸿蒙更加安全？答案当然是否定的！

安全实体获得EAL4+的认证，在国内要涉及两份PP规范，分别是嵌入式软件安全的GB-20276和芯片安全的GB-22186，两份规范靠GB-20276的假设相关联，20276假设了嵌入式软件是要运行在安全芯片上的，所以作为智能卡产品，需要经过同时获得两个EAL4+认证才能说明产品的安全性。

那我们看看智能卡需要抵御的威胁和鸿蒙需要防范的威胁是否相同呢？显然是不同的，那么鸿蒙经过完整论述的安全目的，安全功能，安全功能需求，安全保障需求，以及评估对象实现的复杂的安全设计是否能抵御的了智能卡所面临的威胁呢？答案显然也是否定的，鸿蒙只能抵御鸿蒙自己面临的威胁。

其实，不同类型的产品比较安全评估等级本来就是个伪命题，两个功能，定位完全不同的产品，如何说谁比谁更安全呢？就好像保险箱和打印机比安全一样。

综上所述，把银行的PBOC应用或者电信的USIM应用，安装到安全等级为EAL5+的鸿蒙里，来实现银行卡或者电信卡的幻想，是不可行的。就功能而言，智能卡可以实现的功能，鸿蒙一定可以实现，但是智能卡的安全，是鸿蒙不可实现的，即使它看上去比智能卡还高一些。

5 总结

鸿蒙获得了EAL5+的认证是真实可信的，检测实验室是鼎鼎大名的荷兰Brightsigh，其权威性还是毋庸置疑的。回到鸿蒙本身来说，作为一个全新的安全微内核，其在自己定义的范围内是很安全的，但是也仅限于其定义的范围内，超出了这个TOE范围，安全就无从谈起了。鸿蒙毕竟不是一类产品，作为华为自己的私有产品，产品定位，使用范围，产品功能都还不明确，但是现在可以明确的是，鸿蒙的EAL5+不代表其TEE、SE是EAL5+，鸿蒙的安全，不能说其作为生物识别平台的安全，也不能说其作为金融应用平台的安全，鸿蒙暂时不能代替TEE和S

十、Android和鸿蒙系统对比

• 领域	Android	鸿蒙	对比
  应用，框架层	沙箱，进程隔离，KeyStore身份认证	进程隔离，HUS	相同
  内核底层	DAC，MAC，Selinux	DAC，MAC，Root	鸿蒙无root
  硬件	Trustzone 技术	Trustzone 技术	相同
  安全启动	AVB	安全认证	相同
  设备互联	无	PKI	鸿蒙新业务
  分布式数据	无	分布式	鸿蒙新业务

    系统在安全领域所用的工具都是通用的，除了鸿蒙的无Root微内核外，其他的基本类似，多设备互联会增加安全风险，另外分布式数据存储在移动设备上的安全风险有待验证。

参考链接：

zh-cn/device-dev/security/security-guidelines-overall.md · OpenHarmony/docs - Gitee.com

zh-cn/readme/安全子系统.md · OpenHarmony/docs - Gitee.com

浅谈华为鸿蒙获得国际安全评估EAL5+证书_finery77的博客-CSDN博客