OpenHarmony中HUKS组件基本介绍

OpenHarmony的HUKS组件提供密钥管理及密码学操作,分为SDK、Service和Engine三层,确保密钥安全。HUKS在L2设备上运行于安全环境。安全子系统包括应用完整性保护、权限管理、设备认证和密钥管理等,其中设备认证模块负责可信设备间的关系管理。security_huks关注HUKS的框架、接口和实现,而security_deviceauth涉及设备认证的全生命周期管理。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

OpenHarmony中HUKS组件基本介绍

HUKS简介

HUKS(Harmony Universal KeyStore,鸿蒙通用密钥库系统)向应用提供密钥库能力,包括密钥管理及密钥的密码学操作等功能。HUKS所管理的密钥可以由应用导入或者由应用调用HUKS接口生成。
HUKS是通用密钥管理服务,向应用提供KeyStore及Crypto接口API,包括密钥管理及加解密等功能。

HUKS分层

  • HUKS SDK层
    HUKS SDK层能提供HUKS API供应用调用。
  • HUKS Service层
    HUKS Service层能实现HUKS密钥管理、存储等功能。
  • HUKS Engine层
    HUKS Engine层是HUKS核心模块,负责密钥生成以及加解密等工作。对于L2设备,该部分模块在商用场景下必须在安全环境下运行,包括TEE或者具备安全能力的芯片等。由于安全环境需要特定硬件支持,因此在开源代码中为模拟实现。

HUKS框架

base/security
├── huks
│   ├── frameworks
│   │   └── huks_lite  HUKS代码实现
│   └── interfaces
│       └── innerkits
│           └── huks_lite  HUKS提供接口

相关仓

  • 1.安全子系统

    • 简介
      安全子系统包括系统安全、数据安全、应用安全等功能,为OpenHarmony提供有效保护应用和用户数据的能力。
      安全子系统当前开源的功能,包括应用完整性保护、应用权限管理、设备认证、密钥管理服务、数据分级保护。

    • 子系统框架

      /base/security
      ├── appverify                       # 应用完整性校验
      ├── dataclassification              # 数据分级保护
      ├── device_auth                     # 设备认证
      ├── huks                            # HUKS密钥管理
      └── permission                      # 权限管理
      
    • 子系统架构
      安全子系统架构图 对外API:安全子系统的对外API,部分API只针对系统应用开放;
      应用权限管理:为程序框架子系统提供权限管理功能,并且为上层应用提供权限申请和授权状态查询接口;
      应用完整性校验:提供对应用完整性校验的能力,为应用签名、应用安装校验提供能力支撑;
      设备认证:为分布式设备互联提供密钥协商和可信设备管理能力;
      HUKS密钥管理:为系统提供密钥管理服务,用于支撑基础的设备认证。
      数据分级保护:提供数据分级相关的接口定义。

  • 2.security_huks

    • 基本框架:

      base/security/huks/
      ├── build                             # 编译配置文件
      ├── frameworks                        # 框架代码, 作为基础功能目录, 被interfaces和services使用.
      │   └── huks_standard                 # huks标准模块, 即表示L2的HUKS模块
      │   └── huks_lite                     # huks L0和L1代码实现
      │   └── crypto_lite                   # 加解密实现
      ├── interfaces                        # 接口API代码
      │   └── innerkits
      │       └── huks_standard
      │       └── huks_lite				  # huks提供接口
      └── services
          └── huks_standard
      
  • 3.security_deviceauth

    • 简介
      在OpenHarmony中,设备认证模块作为安全子系统的子模块,负责设备间可信关系的建立、维护、使用、撤销等全生命周期的管理,实现可信设备间的互信认证和安全会话密钥协商,是搭载OpenHarmony的设备进行可信互联的基础平台能力。
    • 基本框架:
      /base/security/deviceauth
      ├── frameworks                   # 设备认证框架层代码
      ├── hals                         # 平台相关工具库抽象层
      │   ├── inc                      # 工具库头文件
      │   └── src                      # 工具库源文件
      ├── interfaces                   # 对外接口目录
      └── services                     # 设备认证服务层代码
          ├── common                   # 公共代码库
          ├── group_auth               # 设备群组认证模块
          ├── group_manager            # 设备群组管理模块
          ├── module                   # 认证器模块(包括帐号无关点对点设备认证器)
          └── session                  # 调度及会话管理模块
      
    • 系统架构图
      在这里插入图片描述
<think>嗯,用户这次给了一个新的日志条目,需要我分析。之前他们问的是关于OpenHarmony密钥生成失败的错误链,现在这个日志看起来和密钥删除操作有关。首先我要仔细看看日志的内容。 日志显示的时间是01-01 04:31:47.305,进程ID是590和574,组件HUKS,信息级别是I(Info)。消息内容是删除密钥或证书链,存储路径是/storage/data/service/el1/public/huks_service/maindata/+0+0+0+0/key,密钥别名是43217A8EF1BF9377580038A28413666A8ADDBBDD76DE6F837A193276****A263。用户可能想知道这个日志的含义,或者是否有潜在的问题需要注意。 首先,我需要确认HUKSOpenHarmony中的作用。HUKS是硬件密钥管理系统,负责密钥的安全存储和管理。记录中的删除操作可能是正常的密钥生命周期管理,比如应用卸载时删除相关密钥,或者系统定期清理过期密钥。但用户可能担心这是否是异常操作,比如未经授权的删除,或者是否存在安全风险。 接下来,分解日志的各个部分。存储路径中的目录结构看起来是标准的HUKS服务存储位置,用于保存主数据。密钥别名通常是唯一的标识符,用于引用特定的密钥。这里的别名被部分打码,可能是出于安全考虑,隐藏了部分关键信息。 然后,我需要考虑可能的异常情况。比如,是否有频繁的删除操作?是否有错误码伴随出现?之前的日志中有错误,但这条是信息级别的,可能只是记录了一个成功操作。不过需要结合上下文来看,比如用户之前遇到的密钥生成失败的问题,是否和此处的删除有关联? 另外,路径中的“+0+0+0+0”可能代表某种目录结构或分片方式,需要了解HUKS的存储机制。可能是多级目录用于分散存储密钥,提高安全性。密钥别名中的长字符串可能是经过哈希处理的结果,确保唯一性和不可逆性。 用户可能需要知道这个操作是否正常,或者如何验证删除是否成功。可能需要检查相关目录是否存在该密钥文件,或者通过HUKS的API查询密钥是否存在。此外,权限问题也可能导致删除失败,但这条日志显示的是信息级别,可能操作已经成功完成。 还需要考虑安全方面,比如密钥删除是否符合预期,是否有敏感数据泄露的风险。在OpenHarmony中,密钥管理非常重要,任何异常操作都可能导致安全问题。建议用户检查是否有相关的安全策略或日志审计机制,确保密钥操作的可追溯性。 总结来说,这条日志记录了一个正常的密钥删除操作,但需要结合系统其他日志和上下文来判断是否有异常。如果用户没有主动触发删除操作,可能需要进一步调查是否有恶意软件或错误配置导致密钥被删除。</think>该日志条目记录了 OpenHarmony 硬件密钥管理系统 (HUKS) 执行密钥删除操作的关键信息。以下是结构化解析: --- ### **日志关键要素解析** ```log 01-01 04:31:47.305 590 574 I 02F00/HUKS: RecordKeyOperation[941]: delete key or certchain, storage path: /storage/data/.../huks_service/maindata/+0+0+0+0/key, key alias: 43217A8EF1BF9377580038A28413666A8ADDBBDD76DE6F837A193276****A263 ``` | 字段 | 说明 | |---------------------|------------------------------------------------------------------------------------------------------------------------------------------------| | **操作类型** | `delete key or certchain` 表示正在删除密钥或证书链 | | **存储路径** | `/storage/data/.../+0+0+0+0/key` 为密钥存储的物理路径,`+0+0+0+0` 是 OpenHarmony 的分级目录结构设计,用于分散存储提升安全性 | | **密钥别名** | `43217A8EF1...****A263` 是密钥的唯一标识符,`****` 表示敏感信息脱敏处理 | | **安全层级** | `el1/public` 表明该密钥属于非安全环境(EL1)的公共存储区,若为 `el2/private` 则属于安全执行环境(TEE) | --- ### **技术背景与安全机制** 1. **HUKS 密钥存储策略** - **分级存储**:通过 `+0+0+0+0` 目录结构将密钥文件分散存储,防止通过单一路径遍历获取完整密钥 - **访问控制**:需满足以下条件才能访问该路径: ```bash # 目录权限示例 drwx------ system system /storage/data/service/el1/public/huks_service/ ``` 2. **密钥别名设计** - 采用 **SHA-256哈希** 生成唯一标识,例如: $$ \text{Alias} = \text{SHA256}(\text{AppID} \parallel \text{KeyPurpose}) $$ - 脱敏部分(`****`)通常保留哈希值的首尾各16字节,确保可追溯性同时防止泄露 --- ### **操作场景分析** #### 可能触发此操作的场景 | 场景 | 典型特征 | |-------------------------------|--------------------------------------------------------------------------| | 应用卸载 | 关联应用的密钥生命周期结束 | | 证书链更新 | 旧证书被吊销后触发删除 | | 安全策略强制执行 | 检测到密钥泄露风险时主动擦除 | | 用户手动清除 | 通过设置 > 安全 > 凭据存储执行清除操作 | #### 异常行为排查 若该日志在无上述场景的情况下频繁出现,需检查: ```bash # 1. 查看密钥文件是否存在 ls -l /storage/data/.../+0+0+0+0/key/43217A8EF1...A263* # 2. 验证操作发起者 cat /proc/590/cmdline # 查看进程590对应的服务 # 3. 审计日志关联性 grep "43217A8EF1" /var/log/huks/audit.log # 检查密钥操作记录 ``` --- ### **安全建议** 1. **存储加密验证** ```bash # 确认文件系统加密状态 dmesg | grep "FBE initialized" # 应显示文件级加密已启用 ``` 2. **密钥残留检测** ```c // 通过HUKS API验证密钥是否存在 HksBlob alias = { .size = 32, .data = "43217A8EF1..." }; int ret = HksKeyExist(&alias, NULL); // 返回HKS_SUCCESS表示密钥仍存在 ``` 3. **安全事件响应** - 若为异常删除,立即执行: ```bash auditctl -w /storage/data/service/el1/public/huks_service/ -p wa -k critical_keys ``` - 启用内核级监控捕获后续操作 --- 该日志表明系统正在按设计执行密钥管理策略,开发者和安全团队应结合 **密钥生命周期管理策略** 与 **审计日志** 进行综合研判。如需更深入分析,需检查同时间段内的 TEE 日志 (`/proc/tzdriver/log`)。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值