diff --git a/README_zh.md b/README_ZH.md similarity index 93% rename from README_zh.md rename to README_ZH.md index 9374b928feedffb39cac6029193cd8399e8542b1..4a352649bf038f06b274df841e62ec01625a293d 100644 --- a/README_zh.md +++ b/README_ZH.md @@ -26,11 +26,11 @@ OpenHarmony系统安全架构如下图所示： - SL1为OpenHarmony设备中最低的安全等级。这类设备通常搭载轻量级系统和使用低端微处理器，业务形态较为单一，不涉及敏感数据的处理。本安全等级要求消除常见的错误，支持软件的完整性保护。若无法满足本等级的要求，则只能作为配件受OpenHarmony设备操控，无法反向操控OpenHarmony设备并进行更复杂的业务协同。 -- SL2安全等级的OpenHarmony设备，可对自身数据进行标记并定义访问控制规则，实现自主的访问控制，需要具备基础的抗渗透能力。此类设备可支持轻量化的可安全隔离环境，用于部署少量必需的安全业务。 +- SL2安全等级的OpenHarmony设备，可对自身数据进行标记并定义访问控制规则，实现自主的访问控制，需要具备基础的抗渗透能力。此级别设备可支持轻量化的可安全隔离环境，用于部署少量必需的安全业务。 -- SL3安全等级的OpenHarmony设备，具备较为完善的安全保护能力。其操作系统具有较为完善的安全语义，可支持强制访问控制。系统可结构化为关键保护元素和非关键保护元素，其关键保护元素被明确定义的安全策略模型保护。此类设备应具备一定的抗渗透能力，可对抗常见的漏洞利用方法。 +- SL3安全等级的OpenHarmony设备，具备较为完善的安全保护能力。其操作系统具有较为完善的安全语义，可支持强制访问控制。系统可结构化为关键保护元素和非关键保护元素，其关键保护元素被明确定义的安全策略模型保护。此级别设备应具备一定的抗渗透能力，可对抗常见的漏洞利用方法。 -- SL4安全等级的OpenHarmony设备，可信基应保持足够的精简，具备防篡改的能力。SL4的实现应足够精简和安全，可对关键保护元素的访问控制进行充分的鉴定和仲裁。此类设备具备相当的抗渗透能力，可抑制绝大多数软件攻击。 +- SL4安全等级的OpenHarmony设备，可信基应保持足够的精简，具备防篡改的能力。SL4的实现应足够精简和安全，可对关键保护元素的访问控制进行充分的鉴定和仲裁。此级别设备具备相当的抗渗透能力，可抑制绝大多数软件攻击。 - SL5安全等级的OpenHarmony设备，为OpenHarmony设备中具备最高等级安全防护能力的设备。系统核心软件模块应进行形式化验证。关键硬件模块如可信根、密码计算引擎等应具备防物理攻击能力，可应对实验室级别的攻击。此级别设备应具备高安全单元，如专用的安全芯片，用于强化设备的启动可信根、存储可信根、运行可信根。 @@ -78,7 +78,7 @@ OpenHarmony系统安全架构如下图所示： - 依赖添加 -1. 依赖编译依赖。 +1. 编译依赖添加 ```undefined external_deps += [ "devicesecuritylevel:dslm_sdk" ] @@ -120,7 +120,7 @@ OpenHarmony系统安全架构如下图所示： if (level >= 3) { // 目标设备的设备安全等级满足要求, 相关业务正常处理 } else { - // 目标设备的设备安全等级不满足要求, 对应流程处理，例如告警、弹窗提示用户等 + // 目标设备的设备安全等级不满足要求, 建议开发者结合实际业务场景进行相应处理，例如告警、弹窗提示用户等 } // 结束处理前，需要释放内存 @@ -147,7 +147,7 @@ OpenHarmony系统安全架构如下图所示： if (level >= 3) { // 目标设备的设备安全等级满足要求, 相关业务正常处理 } else { - // 目标设备的设备安全等级不满足要求, 对应流程处理，例如告警、弹窗提示用户等 + // 目标设备的设备安全等级不满足要求, 建议开发者结合实际业务场景进行相应处理，例如告警、弹窗提示用户等 } // 结束处理前，需要释放内存