未验证 提交 93962530 编写于 作者: O openharmony_ci 提交者: Gitee

!6718 TEE相关描述删除

Merge pull request !6718 from yang-boyu/OpenHarmony-3.1-Release
......@@ -21,14 +21,6 @@ This environment combines chip security and system security features with upper-
When you use the code for signature verification, ensure the validity of the PKI public keys. OpenHarmony devices use a storage medium such as eFUSE and one-time password \(OTP\) to store the public keys \(for example, their hash values\) and guarantee their validity. A public key is usually programed into the eFuse or OTP of a device during device manufacturing.
- Hardware-isolated trusted environment
The hardware-isolated trusted environment complies with the design concept of the trusted computing system. There is a clear boundary between the trusted environment and untrusted one. OpenHarmony devices protect core sensitive data in the trusted environment. Even if OS vulnerabilities in the untrusted environment are exploited, sensitive data in the trusted environment is secure.
The trusted environment of OpenHarmony devices is built based on a hardware security isolation mechanism. The chip isolation mechanism varies slightly on different OpenHarmony devices, and the most common mechanism is Arm TrustZone. On some RISC-V chip platforms, independent security cores may also be used to build a trusted environment.
A specific, simplified OS iTrustee lite runs in the trusted environment to manage resources and schedule tasks in the environment and provide security services for OpenHarmony devices. Key management and data security are the most common security services in the trusted environment. A device has a unique hardware root key in the eFuse/OTP. Based on this root key and service context, the trusted environment generates multiple keys that provide key management and data encryption/decryption services for applications. During their whole lifecycle, core keys of devices stay in the trusted environment. The trusted environment also provides security services such as identity authentication, system status monitoring, and secure data storage to enhance device security.
- Hardware key engine
Cryptography is the basis of information security. Data encryption/decryption requires high efficiency and security of computing devices. Hardware encryption/decryption technologies use computer hardware to assist or even replace software to encrypt or decrypt data. Hardware-based encryption/decryption is more efficient and secure than software-based encryption/decryption.
......@@ -41,9 +33,6 @@ This environment combines chip security and system security features with upper-
### Recommended Practices<a name="section948519243104"></a>
- The boot root of trust consists of a built-in code segment in the chip and the root key of the device. The root of trust is written into the chip during manufacturing and cannot be modified in the device lifecycle. It is used to verify software certificates in the device boot process. The root key is the public key matching the private key of the device certificate signature. The private key is maintained on the PKI signature server and the public key is written to the device. To prevent attackers from tampering with the public key to bypass signature authentication, you can write the public key to media such as fuses on OpenHarmony devices. Considering that the fuse space is limited, you can store only the hash value of the public key in the fuse and verify the validity of the public key using the boot code.
- Generally, a trusted execution environment \(TEE\) is built based on the Arm TrustZone technology, and can also adopt other isolation mechanisms, such as TrustZone-M and independent security cores, depending on the device form. A TEE OS must be deployed in the TEE to manage resources and schedule tasks. OpenHarmony provides iTrustee as the TEE OS. You can develop and deploy security services based on iTrustee.
Not all OpenHarmony devices need to support the TEE, for example, some devices with thin resources that run less sensitive services may not need the TEE. You can choose whether to support the TEE and how to implement the TEE based on service requirements.
- The hardware key engine must provide key algorithms related to true random numbers, public keys, symmetric keys, and hash values. By deploying required drivers in OpenHarmony, you can provide unified key management and key algorithms for applications.
......
......@@ -40,14 +40,6 @@ OpenHarmony操作系统是一个开放的系统,开发者可以通过OpenHarmo
ROM中的代码在执行签名校验时,需确保用于校验的PKI公钥的合法性,OpenHarmony设备可采用eFuse/OTP等存储介质来存储公钥(如公钥哈希值),来保护公钥自身的合法性。公钥一般在设备制造环节,烧录到设备的eFuse/OTP中。
- 硬件隔离可信环境
硬件隔离的可信环境,遵循了可信计算系统的设计理念。可信环境内外形成了两个世界:可信世界与不可信世界,两者之间存在清晰而明确的隔离边界;OpenHarmony设备在可信环境中实现了核心敏感数据的保护机制,可确保即使不可信世界的操作系统存在漏洞且被利用,也依然能确保可信环境中敏感数据的安全。
OpenHarmony设备的可信环境,基于硬件的安全隔离机制构建,在不同的OpenHarmony设备上芯片隔离机制略有差异,较为通用的方法是采用ARM的TrustZone技术。在部分Risc-V芯片平台上,也可能采用独立安全核的形式来构建可信环境。
可信环境中,运行特定的、精简的操作系统iTrustee lite,用于管理可信环境的资源和任务调度,给OpenHarmony设备提供安全服务。密钥管理及数据安全,是可信环境中最为常见的安全服务,设备在eFuse/OTP中存有硬件唯一根密钥,可信环境可基于该密钥结合业务上下文衍生出多种密钥,给应用提供密钥管理和数据加解密相关的服务;设备核心密钥生命周期不离开可信环境。可信环境同样可提供身份认证、系统状态监控、数据安全存储等安全服务,提高设备安全性。
- 硬件密钥引擎
密码学是信息安全的基础。数据加解密对计算机设备的核心诉求是:高效、安全。硬件加解密技术利用计算机硬件辅助软件,甚至直接取代软件,来处理数据的加解密。相比由软件实现的加解密计算,硬件实现的加解密计算更高效、更安全。
......@@ -60,9 +52,6 @@ OpenHarmony操作系统是一个开放的系统,开发者可以通过OpenHarmo
### 推荐做法<a name="section948519243104"></a>
- 启动可信根可由一段固化在芯片中的代码和设备根密钥组成,前者一般在芯片制造阶段写入,设备生命周期内不可更改,负责在启动阶段校验设备软件证书;后者则是用于设备证书签名的私钥相对应的公钥,证书签名私钥不出PKI签名服务器,而公钥则需写入设备。为防止攻击者篡改公钥从而达到绕过签名认证的目的,写入OpenHarmony设备的公钥须确保不可篡改,可将公钥信息写入如熔丝等介质;考虑到熔丝空间有限,可仅存储公钥的哈希值,并由启动代码校验公钥的合法性。
- 可信执行环境较为通用的做法是基于ARM TrustZone技术构建,也可根据设备的实际形态选择其他隔离机制,如TrustZone-M、独立安全核等;可信执行环境中须部署TEE OS,用于管理可信执行环境的资源及任务调度。OpenHarmony系统提供iTrustee作为TEE OS的解决方案,开发者及设备商可基于iTrustee开发并部署安全业务。
并非所有OpenHarmony设备都强制要求支持可信执行环境,部分运行低敏感业务的瘦资源设备可不做强制要求;可根据实际业务场景选择是否支持可信执行环境,以及实现怎样的可信执行环境。
- 硬件密钥引擎须提供真随机数、公钥、对称密钥、哈希等密钥算法能力,通过在OpenHarmony系统中部署相应的驱动程序,给应用提供统一的密钥管理及密钥算法服务。
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册