HarmonyOS：安全能力介绍

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
➤博客园地址：为敢技术（https://www.cnblogs.com/strengthen/ ）
➤GitHub地址：https://github.com/strengthen
➤原文地址：https://www.cnblogs.com/strengthen/p/18518158
➤如果链接不是为敢技术的博客园地址，则可能是爬取作者的文章。
➤原文已修改更新！强烈建议点击原文地址阅读！支持作者！支持原创！
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

一、安全架构设计

1、HarmonyOS系统安全设计理念，基于安全的三要素：机密性、完整性、可用性。HarmonyOS系统的安全设计以硬件的可信根和硬件的可信运行环境TEE作为信任的基础，基于信任链的传递机制，通过高安全的模块来保护和证明低安全模块的安全，实现安全的信任传递。对于完整性方面，基于PKI的基础设施的证书签名机制来保护系统和应用数据的完整性。

2、HarmonyOS系统安全设计基础：

（1）、基于最小的可信计算基础TCB；硬件主密钥，加解密引擎。

（2）、关键安全组件基于TEE可信运行环境；TEE。

（3）、基于强安全模块传递信任链到弱安全模块（TCB-> TEE -> OS Kernel -> User Process)。

（4）、基于PKI基础设施保护关键模块的完整性保护。

2、HarmonyOS是分布式的操作系统，HarmonyOS的核心安全理论，是分级的安全理论，通过结构化的保护机制，如你在访问客体的时候，需要遵循业界权威的安全模型：机密性遵循BL模型，完整性遵循Biba模型，HarmonyOS的安全是以CC的EAL5+等级作为安全目标进行设计。

2、HarmonyOS系统安全：为了保护应用能够在系统上安全可靠的运行，HarmonyOS通过软硬结合，对系统进行加固，来保护系统不被篡改或利用。系统安全包括四个部分：

（1）、完整性保护：从系统的启动，系统的升级，以及系统运行时的完整性保护，这里特别强调软硬结合的HKIP完整性保护能力。通过虚拟化的EL2等级来保护内核EL1的安全等级。同时对应用提供了转包的签名和应用的代码签名能力，来保护应用的完整性。

（2）、漏洞防利用：基于内核提供的堆栈保护能力，CFI能力以及地址随机化能力等等来进行保护，漏洞不会被利用。

（3）、系统访问控制：基于系统提供的强制访问控制能力，SElinux、Seccomp、Capability以及自主访问控制能力，对于上层的应用的运行，基于钱啊感知访问控制的能力，进行设计了应用的沙箱隔离能力，对于高安全运行环境，提供了TEE和SE的开发环境，来支持高安应用的运行。

3、Harmony的分级安全，首先对于数据进行分级保护，基于数据，目前各个国家，中国、美国、欧盟等均有个人数据等保护法，基于法理的基础，将数据进行划分为S0、S1、S2、S3、S4五个等级，在系统的框架层面，对于数据的风险等级标签能力，可以给数据进行打标签，在应用的文件进行存储的时候，可以基于文件的分级加密能力，对于数据提供EL1到EL4到分级加密能力，密钥的保护则基于系统底层的安全机制进行保护，同时对于关键的资产数据，如银行的卡号、token、本地的口令等短数据则提供Asset数据保护能力。通过对数据的加密存储在数据库当中，同时对于数据的访问，提供了对应的访问控制机制，只有正确的应用才能访问正确的数据，

4、HarmonyOS基于洋葱模型，按照APL维度，严格定义三层等级：OS核心APL3，系统增强服务APL2，应用程序APL1，实现严格的分层保护，外部的应用如果需要访问内部的权限，默认无法访问。通过严格的分层权限保护模型，可以有效抵御恶意攻击，确保系统安全可靠。

4.1、权限分级分配原则：

（1）、操作系统核心能力APL=3：

属于最小系统：系统正常运转核心，如AMS、BMS、软总线。

TCB最小化：作整个应用程序的TCB，拥有较高特权，禁止系统无关业务申请：禁止应用、业务类程序申请。

减少攻击面：禁止应用申请联网能力。

（2）、系统扩展的系统功能服务APL=2：

属于系统扩展基础服务：在OS核心能力基础上扩展的系统服务，如情景感知、查找设备。

不对外开放的增强服务：不对外开放的增强服务，如语音助手应用拉起，服务中心安装等。

（3）、普通应用程序APL=1：

一切应用程序都是APL=1。

禁止应用程序直接申请高等级特权。

如果需要特殊权限，以ACL的权限申请审核方式授予。

4.1、访问控制原则

（1）、以系统分配的Access Token作为应用的标识符，不以UID作为标识。

（2）、当访问的主体应用APL大于等于客体的APL时，只要在配置文件中声明即可允许访问。

（3）、当访问的主体应用APL低于客体APL时，如需使用高权限则使用必须通过HarmonyAppProvison的ACL字段进行授权（需审核）

5、生态安全生命周期管理。

对于来自生态的应用大多数为正常的的应用，也存在恶意利用进行牟利的黑产、诈骗、恶意营销推广等风险应用，为了生态应用安全纯净可控，HarmonyOS将以端到端的安全可控的生态模式进行构建。

6、HarmonyOS安全能力全景图

面向业务场景，以分级安全为架构思想的基础安全底座，构建HarmonyOS安全的应用生态。

二、安全开发关键技术

1、应用加固：应用混淆、代码签名、应用加密和反调试。提供了基础的应用加固安全能力，包括混淆、加密和代码签名能力，保护代码反编译和反调试。

2、安全能力介绍：

（1）、技术一：应用加密：对整个应用包进行加密，上架时加密，应用加载时进行解密。防止应用安装包的原始代码泄露。

（2）、技术二：代码混淆：混淆能力支持名称的混淆和日志的移除。如果开发者需要更高级的混淆能力，可以引入三方进行合作。

（3）、技术三：代码签名：通过代码签名，保证应用每一行执行的代码，都是系统签名认证过的。应用无法自行下载代码运行。

（4）、技术四：调试检测：通讨应用的调试标志，检测应用是否处于pTrace、GDB等的调试状态。

3、应用完整性保护：应用代码签名。

保障运行代码可信，仅指定应用市场签名的APP才能运行。在HarmonyOS 4.0实现了应用的代码段签名能力，所有的代码均会进行签名，在应用运行时状态进行加载的时候会进行校验该代码段是否已经经过签名验证，只有相等才能够被执行。这样能有效的防止代码的动态注入。

4、应用权限管理：权限申请和授权。应用的权限管理是基于“洋葱”模型，对于应用的配置是基于module.json5配置文件和Provision Profile配置文件进行配置。

（1）、应用开发阶段。

应用普通权限申请：应用申请的所有权限列表均需要在module.json5里定义，包含ACL配置的权限也需要在module.json5申清。

应用特殊权限申请：应用APL如果小于权限定义的APL，默认无法申请该权限。如果业务需要必须要使用的权限，需要通过HarmonyAppProvison证书的ACL实现申请。

（2）、应用运行阶段：动态权限申请、静态权限设置。

5、应用的快速修复：热布丁需要上架审核签名发布，不允许三方更新。三方应用随意热更新存在较大的安全隐患，可能存在绕开应用审查加载恶意代码的情况，HarmonyOS提供系统的快速修复机制帮助问题修复应用场景：头部应用提出在60分钟*全网热修复的需求，以应付紧急事件，作为安全运营的最后手段。即使通过当前的漏洞找到了可以加载三方框架的情况，但后续，系统也还是会把其进行修复和禁止这个三方的框架运行。因此不推荐开发者去使用这样的三方框架。当前在HarmonyOS上提供了对应的快速修复引擎以及对应的补丁的工具。

HarmonyOS提供给开发者官方的快速修复能力：

（1）、通过上架审核快速修复补丁并签名后支持公开发布。

（2）、支持开发者以远快于（小时级/分钟级）应用升级的方式进行缺陷修复。针对JS支持函数粒度的快速修复。

（3）、只允许修改代码，不能修改资源，只能用于问题修复，不能用于新增特性。

6、TEE TA应用开发：基于TEE的开发TA，高安全应用场景。

为了帮助金融等高安全应用场景需求，基于TEE可信运行环境，开发者可以开发应用的TA，TEE隔离运行，外部无法访问TEE运行的TA，即使Root也无法获取或劫持TA应用，可用于应用的支付认证等场景。

场景介绍：适用于对支付金融等高安全场景

能力介绍：

（1）、设备端TA框架：TEE TA运行环境框架统一，生态TA代码统一；TEE Client Framework及AP接口规范。

（2）、提供TA开发和调试工具：IDE集成TEE TA SDK支持，支持TA的开发和调试口 IDE支持TEE运行环境模拟，支持TA的模拟运行。

（3）、TA应用发布：TA的签名，目前需要经过审核并签名；TA分发，目前支持随App打包发布。

7、HarmonyOS提供对于TEE运行环境的开放，如果需要开发TEE TA应用，需要进行特殊的SDK申请，当前TEE的SDK是没有直接对外开放的。华为会对开发者客户所需要使用的场景进行评估，确认是否有必要去使用开发TA的情况，如果审核通过，才会提供对应的SDK进行开发。安全对于TEE的TA的开发发布，主要是通过跟App统一打包的方式进行发布，一旦被审核和签名之后，然后就可以和App一起打包进行发布。在运行时会将对应的TA加载到TEE的运行环境当中。