openUBMC社区安全签名特性设计说明书 ​

Copyright © 2026 openUBMC Community

您对"本文档"的复制，使用，修改及分发受木兰宽松许可证, 第2版协议(以下简称"MulanPSL2")的约束。 为了方便用户理解，您可以通过访问https://license.coscl.org.cn/MulanPSL2了解MulanPSL2的概要 (但不是替代)。 MulanPSL2的完整协议内容您可以访问如下网址获取：https://license.coscl.org.cn/MulanPSL2。

改版记录

目录

1.特性概述

1.1 目的

1.2范围

1.3特性需求列表

2.需求场景分析

2.1特性需求来源与价值概述

2.2特性场景分析

2.3特性影响分析

2.3.1硬件限制

2.3.2技术限制

2.3.3对License的影响分析

2.3.4对系统性能规格的影响分析

2.3.5对系统可靠性规格的影响分析

2.3.6对系统兼容性的影响分析

2.3.7与其他重大特性的交互性，冲突性的影响分析

2.4同类社区/商用软件实现方案分析

3.特性/功能实现原理

3.1目标

3.2总体方案

3.3签名体系架构

4.Use Case一实现：构建签名流程

4.1设计思路

4.2约束条件

4.3详细实现

4.3.1流水线签名能力构建

4.3.2 bingo工具签名支持

4.4子系统间接口

4.5子系统详细设计

4.6DFX属性设计

4.6.1性能设计

4.6.2升级与扩容设计

4.6.3异常处理设计

4.6.4资源管理相关设计

4.6.5小型化设计

4.6.6可测性设计

4.6.7安全设计

4.7系统外部接口

4.8自测用例设计

5.Use Case二实现：升级签名校验

5.1设计思路

5.2约束条件

5.3详细实现

5.3.1社区签名包升级校验能力

5.3.2加密配置文件处理机制

5.3.3兼容性升级场景

5.4子系统间接口

5.5子系统详细设计

List of abbreviations 缩略语清单 :

1.特性概述 ​

本特性旨在为openUBMC社区构建一套完整的安全签名体系，包括构建阶段的流水线签名能力、升级阶段的签名校验能力以及安全启动校验能力。通过该体系，社区可以确保固件包的真实性和完整性，保护用户免受恶意固件的攻击，同时为伙伴提供灵活的签名方案选择。

1.1目的 ​

本文档对社区安全签名特性的功能进行设计，明确签名构建流程、升级校验机制、安全启动验证等关键技术实现，为后续软件开发人员、测试人员及运维人员提供指导。

1.2范围 ​

• openUBMC社区版本构建流水线相关人员
• 需要使用社区签名工具的开发者
• 固件升级模块开发维护人员
• 安全合规审查人员
• 需要自行搭建签名服务器的伙伴开发者

1.3特性需求列表 ​

2.需求场景分析 ​

2.1特性需求来源与价值概述 ​

随着openUBMC社区的开放发展，社区版本的分发和升级安全问题日益突出。传统的华为签名体系已无法满足社区开放协作的需求，社区需要一个独立的签名体系来：

1. 保障固件真实性：防止恶意篡改的固件流入社区，保护用户设备安全
2. 实现社区版本安全升级：通过Rootfs证书识别和签名校验，确保社区内部升级的安全性
3. 支持平滑过渡：新老社区版本相互升级兼容，26年底LTS版本实现校验强制生效
4. 满足合规要求：符合安全启动、固件完整性等行业安全标准

2.2特性场景分析 ​

2.3特性影响分析 ​

2.3.1硬件限制 ​

不涉及硬件限制，签名和校验均为软件层面的操作。

2.3.2技术限制 ​

• 签名算法：支持RSA和SM2两种签名算法
• 签名工具：依赖sign_trust签名工具
• 签名服务器：需要独立的签名服务器部署环境
• 证书管理：需要购买和维护签名证书

2.3.3对License的影响分析 ​

不涉及License变更，签名体系为纯安全增强功能。

2.3.4对系统性能规格的影响分析 ​

• 构建阶段：签名操作增加构建时间（预估增加10-30秒）
• 升级阶段：签名校验增加升级时间（预估增加5-15秒）
• 存储空间：签名信息增加固件包大小（预估增加1KB-10KB）

2.3.5对系统可靠性规格的影响分析 ​

• 签名校验失败默认行为：仅记录日志，不阻止升级运行（兼容性考虑）
• 签名服务器故障时，流水线应支持降级为无签名模式构建

2.3.6对系统兼容性的影响分析 ​

关键兼容性要求（社区升社区）：

1. 版本区分机制：通过Rootfs上大包的证书区分社区无签名版本和有签名版本
2. 校验开关固化：校验属性只能跟随构建生成，不支持CSR升级动态修改
3. 新老版本兼容：新老社区版本可以相互升级
4. 升级矩阵覆盖：
   • 新版本（校验不生效）可升级任意版本（有签名/无签名）
   • 新版本（校验生效）可升级有签名版本，不可升级无签名版本
   • 老版本可升级老版本无签名包，升级新版本有签名包需测试验证
5. 长期策略：26年底LTS版本切换到校验生效版本
6. 待讨论事项：校验生效的版本无法回退到校验不生效的版本
7. 内外层签名一致性：Rootfs HPM内外层签名保持一致

2.3.7与其他重大特性的交互性，冲突性的影响分析 ​

• 与固件升级特性强耦合，需同步升级校验逻辑
• 与安全启动特性协同，提供内层安全启动校验能力
• 与构建系统(bingo)强集成，需修改构建流程

2.4同类社区/商用软件实现方案分析 ​

3.特性/功能实现原理 ​

3.1目标 ​

• 完整性：确保固件包从构建到升级全流程的签名覆盖
• 灵活性：支持RSA/SM2双算法，支持配置化签名策略
• 兼容性：支持多签名模式间的平滑升级转换
• 开放性：为伙伴提供签名工具和能力，但不提供公开签名服务
• 安全性：符合安全启动标准，实现内外层签名一致性

3.2总体方案 ​

社区安全签名体系分为三个核心模块：

1. 构建签名模块：在流水线和bingo工具中集成签名能力，实现构建阶段的固件签名
2. 升级校验模块：在升级流程中预埋签名校验能力，实现升级阶段的签名验证
3. 安全启动模块：实现内层安全启动校验，确保固件启动过程的安全性

3.3签名体系架构 ​

3.3.1 签名流程原则 ​

核心原则：

1. 校验开关固化：校验属性只能跟随构建生成，不能通过CSR升级动态修改（确保安全性）
2. 签名服务不公开：社区只提供签名工具，不提供公开的签名服务，社区普通开发者不能签名社区包
3. 内外层签名一致：Rootfs HPM内外层签名保持一致
4. 社区升社区优先：当前阶段仅考虑社区升社区的升级场景，暂不考虑华为、伙伴签名模式
5. 长期策略过渡：26年底LTS版本切换到校验生效版本，实现平滑过渡

3.3.2 社区版本升级场景矩阵 ​

表：社区版本升级场景矩阵

版本区分机制：

• 通过Rootfs上大包的证书来区分社区无签名版本和有签名版本
• 有签名版本：Rootfs上大包携带签名证书
• 无签名版本：Rootfs上大包不携带签名证书（老版本或免签名构建版本）

校验开关机制：

• 属性名称：signature_verification_enabled
• 属性值：true（校验生效）/ false（校验不生效）
• 属性固化：只能跟随构建生成，不从CSR读取，不支持升级动态修改

长期策略时间线：

• 当前阶段：新版本默认校验不生效（false）
• 中间阶段：支持构建配置开启校验
• 26年底LTS版本：强制校验生效（true）

4.Use Case一实现：构建签名流程 ​

4.1设计思路 ​

构建签名流程的核心设计思路：

1. 能力优先，暂不落地：先支持构建签名能力，26年LTS版本发布后再使能签名校验能力
2. 配置化判断：通过manifest配置和环境检测来判断是否执行签名
3. 工具集成：bingo工具识别sign_trust并集成签名流程
4. 伙伴赋能：提供签名服务器配置指导，支持伙伴自行搭建签名服务

4.2约束条件 ​

• 时间约束：当前阶段先支持能力，暂不直接落地签名，26年LTS版本发布后再使能签名
• 权限约束：签名服务不公开，社区普通开发者不能签名社区包
• 工具依赖：依赖sign_trust签名工具的部署和证书配置
• 外围固件约束：BIOS的PFR签名需特殊处理（待细化方案）

4.3详细实现 ​

4.3.1 流水线签名能力构建 ​

图：流水线签名流程

实现要点：

1. 流水线默认签名构建：

   • CICD版本构建流水线集成sign_trust
   • 流水线默认使用签名的包进行构建
   • 支持配置化签名与免签名模式切换

2. 签名算法支持：

   • 支持RSA签名算法
   • 支持SM2国密签名算法
   • 算法选择通过manifest配置指定

3. 签名内容范围：

   • BMC固件主包
   • 外围固件（CPLD/BIOS/VRs/BBU/CSR）
   • 配置文件包（config.tar.gz）

4.3.2 bingo工具签名支持 ​

bingo工具签名能力设计：

1. manifest签名配置解析：

   • bingo解析manifest中的产品签名配置策略
   • 根据配置判断是否需要执行签名流程
   • 配置项包括：签名算法、签名范围、签名开关

2. 环境检测机制：

   • bingo识别环境上是否存在sign_trust工具
   • 存在sign_trust时，判断是否需要执行签名流程
   • 不存在sign_trust时，自动降级为无签名模式构建

3. 签名指导说明：

   • bingo提供指导说明文档
   • 告知社区普通开发者如何配置签名服务器
   • 提供签名操作教程和示例

bingo签名判断流程：

步骤1: 解析manifest签名配置
步骤2: 检测环境中sign_trust工具是否存在
步骤3: 判断签名需求
  - 如果配置要求签名且sign_trust存在 → 执行签名流程
  - 如果配置要求签名但sign_trust不存在 → 报告警告，降级无签名构建
  - 如果配置不要求签名 → 直接无签名构建
步骤4: 执行签名或构建

4.4子系统间接口 ​

bingo与sign_trust接口：

• bingo调用sign_trust进行固件签名
• sign_trust返回签名结果和签名证书信息
• bingo将签名信息嵌入固件包

流水线与bingo接口：

• 流水线触发bingo构建命令
• bingo返回构建结果和签名状态
• 流水线根据签名状态决定后续流程

4.5子系统详细设计 ​

4.5.1 sign_trust签名工具 ​

sign_trust部署要求：

1. 基础设施依赖：

   • 正式环境的服务器
   • 购买的签名证书
   • 网络安全隔离措施

2. 签名机制：

   • client计算固件包hash
   • client发送hash给server
   • server只签名hash，不接收完整包
   • server返回签名结果

3. 安全措施：

   • 签名服务器网络隔离
   • 签名密钥安全存储
   • 签名操作审计日志

4.5.2 manifest签名配置结构 ​

manifest签名配置项：

signature:
  enabled: true/false        # 是否启用签名
  algorithm: RSA/SM2         # 签名算法选择
  scope:                     # 签名范围
    - BMC_main_package
    - CPLD
    - BIOS
    - VRs
    - BBU
    - CSR
  server:                    # 签名服务器配置
    address: xxx.xxx.xxx.xxx
    port: xxxx

4.6DFX属性设计 ​

4.6.1性能设计 ​

• 签名操作增加构建时间：预估10-30秒
• 签名信息增加固件包大小：预估1KB-10KB
• 签名服务器响应时间要求：<5秒

4.6.2升级与扩容设计 ​

• 签名证书更新流程
• 签名算法扩展机制
• 签名服务器扩容方案

4.6.3异常处理设计 ​

4.6.4资源管理相关设计 ​

• 签名服务器资源需求：独立服务器、安全存储
• 签名证书管理：证书购买、存储、更新
• 签名日志存储：签名操作审计日志

4.6.5小型化设计 ​

不涉及小型化设计，签名信息大小固定且可控。

4.6.6可测性设计 ​

• 签名流程可观测：bingo提供签名状态输出
• 签名结果可验证：提供签名验证工具
• 签名日志可追溯：完整签名操作日志记录

4.6.7安全设计 ​

• 签名密钥安全存储
• 签名服务器网络隔离
• 签名操作审计日志
• 签名证书安全管理

4.7系统外部接口 ​

• sign_trust签名服务器接口
• 签名证书管理接口

4.8自测用例设计 ​

1. bingo签名配置解析测试
2. bingo环境检测测试（sign_trust存在/不存在）
3. 流水线签名流程测试
4. RSA签名算法测试
5. SM2签名算法测试

5.Use Case二实现：升级签名校验 ​

5.1设计思路 ​

升级签名校验的核心设计思路：

1. 版本区分机制：通过Rootfs上大包的证书来区分社区无签名版本和有签名版本
2. 校验开关机制：校验做成开关，默认不校验，支持开启校验
3. 属性固化原则：校验属性只能跟随构建生成，不能通过CSR升级生效
4. 社区内部升级：仅考虑社区升社区的升级场景
5. 长期过渡策略：26年底LTS版本切换到校验生效版本
6. 加密自动解析：对config.tar.gz文件支持自动加密状态检测

5.2约束条件 ​

• 升级范围约束：仅考虑社区升社区的升级场景，暂不考虑华为、伙伴签名模式
• 属性固化约束：校验开关属性只能跟随构建生成，不支持CSR动态修改
• 外围固件约束：配套固件CPLD需要同步测试签名校验
• 加密约束：config.tar.gz加密场景需特殊处理
• 回退约束：校验生效的版本无法回退到校验不生效的版本（待讨论确认）

5.3详细实现 ​

5.3.1 版本区分机制 ​

通过Rootfs证书区分签名版本：

1. 社区有签名版本识别：

   • Rootfs上大包携带签名证书
   • 证书信息包含在固件包元数据中
   • 可通过固件包解析获取证书信息

2. 社区无签名版本识别：

   • Rootfs上大包不携带签名证书
   • 固件包元数据中无证书信息
   • 为老版本或免签名构建版本

3. 版本标识存储位置：

   • 固件包元数据区
   • Rootfs文件系统特定路径
   • 升级包描述文件

5.3.2 校验开关机制 ​

校验开关设计：

1. 开关属性定义：

   • 属性名称：signature_verification_enabled
   • 属性值：true（校验生效）/ false（校验不生效）
   • 属性来源：构建时固化，不从CSR读取

2. 开关固化机制：

   • 属性在构建阶段写入固件包
   • 属性值固化在Rootfs配置中
   • CSR升级无法修改该属性
   • 确保校验策略的一致性和安全性

3. 默认开关状态：

   • 新版本默认：校验不生效（false）
   • 长期策略：26年底LTS版本默认校验生效（true）
   • 支持构建配置切换开关状态

表：校验开关状态定义

5.3.3 社区升社区升级矩阵 ​

表：社区版本升级矩阵

升级矩阵详细说明：

1. 当前环境：新版本（校验不生效）

   升级包类型	升级包签名状态	校验行为	升级结果
   新版本有签名包	有签名证书	不校验	可升级
   老版本无签名包	无签名证书	不校验	可升级

   说明：

   • 校验开关为false，不执行签名校验
   • 无论升级包是否有签名，都可以升级
   • 适用于当前阶段的默认行为

2. 当前环境：新版本（校验生效）

   升级包类型	升级包签名状态	校验行为	升级结果
   新版本有签名包	有签名证书	校验签名	可升级
   老版本无签名包	无签名证书	检测无签名	不可升级

   说明：

   • 校验开关为true，执行签名校验
   • 升级有签名包：执行签名验证，验证通过可升级
   • 升级无签名包：代码适配检测无签名，记录明确日志，阻止升级
   • 日志内容："升级失败：当前环境启用签名校验，但升级包为老版本无签名包，请使用有签名的新版本升级包"

3. 当前环境：老版本

   升级包类型	升级包签名状态	校验行为	升级结果
   新版本有签名包	有签名证书	待测试	待确认
   老版本无签名包	无签名证书	不校验	可升级

   说明：

   • 老版本无校验开关属性，默认不校验
   • 升级老版本无签名包：直接升级
   • 升级新版本有签名包：需实际测试验证兼容性

5.3.4 校验流程详细设计 ​

签名校验流程：

步骤1: 接收升级包
步骤2: 解析当前环境版本属性
  - 检查是否存在signature_verification_enabled属性
  - 读取属性值：true/false
步骤3: 解析升级包签名状态
  - 检查Rootfs上大包的证书信息
  - 判断升级包是否有签名证书
步骤4: 根据校验开关决定校验行为
  - 开关为false → 不校验签名，直接升级
  - 开关为true → 执行签名校验流程
步骤5: 执行签名校验（开关为true时）
  - 升级包有签名证书 → 验证签名有效性
  - 升级包无签名证书 → 记录明确日志，阻止升级
步骤6: 处理校验结果
  - 校验成功 → 继续升级流程
  - 校验失败 → 记录日志，根据策略处理

关键代码适配点：

1. 无签名包检测：

   • 当校验开关生效时，检测升级包是否携带签名证书
   • 如果无签名证书，记录明确日志说明原因
   • 日志示例："检测到升级包为老版本无签名包（无Rootfs证书），当前环境启用签名校验，升级被阻止"

2. 老版本兼容：

   • 检测当前环境是否为老版本（无校验开关属性）
   • 老版本默认不校验签名
   • 支持老版本升级到新版本

5.3.5 升级目标与长期策略 ​

升级目标：

1. 兼容性目标：

   • 新老社区版本可以相互升级
   • 确保平滑过渡，不中断现有升级路径
   • 支持灵活的版本切换策略

2. 长期策略：

   • 时间节点：26年底LTS版本
   • 策略内容：所有版本切换到校验生效版本
   • 实施方式：新版本默认校验开关为true
   • 影响范围：所有社区版本升级均需签名校验

3. 待讨论事项：

   • 回退问题：校验生效的版本无法回退到校验不生效的版本？
   • 讨论要点：
     • 是否允许校验生效版本回退到校验不生效版本？
     • 回退是否需要特殊处理机制？
     • 回退对安全性的影响评估？
     • 回退场景的实际需求分析？

长期策略实施计划：

表：长期策略实施时间线

5.4子系统间接口 ​

升级模块与签名校验接口：

• 升级模块读取当前环境的校验开关属性
• 升级模块解析升级包的签名状态
• 升级模块根据开关状态决定是否调用签名校验
• 签名校验模块返回校验结果和建议操作

签名校验与加密解析接口：

• 签名校验模块调用加密解析模块
• 加密解析模块返回config.tar.gz内容
• 签名校验模块继续验证流程

5.5子系统详细设计 ​

5.5.1 签名校验模块 ​

签名校验流程：

步骤1: 读取校验开关属性
  - 检查固件包中signature_verification_enabled属性
  - 属性不存在 → 老版本，不校验
  - 属性存在 → 根据属性值决定行为
  
步骤2: 解析升级包签名状态
  - 检查Rootfs上大包证书信息
  - 有证书 → 有签名版本
  - 无证书 → 无签名版本
  
步骤3: 校验决策逻辑
  if (开关为false) {
    // 不校验，直接升级
    return 允许升级
  }
  else if (开关为true) {
    if (升级包有签名证书) {
      // 执行签名校验
      return 签名校验流程
    }
    else {
      // 升级包无签名证书
      log("升级失败：当前环境启用签名校验，但升级包为老版本无签名包")
      return 拒绝升级
    }
  }
  
步骤4: 执行签名验证（有签名包时）
  - 验证证书有效性
  - 验证签名hash
  - 验证固件完整性
  
步骤5: 返回校验结果
  - 校验成功 → 允许升级
  - 校验失败 → 记录日志，根据策略处理

5.5.2 加密解析模块 ​

加密解析逻辑：

步骤1: 接收config.tar.gz文件
步骤2: 尝试直接tar解压
步骤3: 检查解压结果格式
  - 如果为tar.gz格式 → 未加密，返回内容
  - 如果非tar.gz格式 → 进入加密检测流程
步骤4: 检查本地是否存在AES解密密钥
  - 存在密钥 → 尝试AES解密
  - 不存在密钥 → 记录日志，返回失败
步骤5: 解密后再次检查格式
  - 解密成功且为tar.gz格式 → 返回内容
  - 解密失败或格式错误 → 记录日志，返回失败

5.5.3 外围固件同步测试 ​

外围固件签名校验范围：

1. CPLD固件：

   • 需同步测试签名校验能力
   • 配套CPLD升级需验证签名
   • 确保CPLD升级与社区包升级协同

2. 其他外围固件：

   • BIOS、VRs、BBU、CSR等
   • 需同步测试签名校验流程
   • 确保外围固件升级安全性