Hubris项目中的安全启动与可信度量机制解析

背景与问题核心

在嵌入式安全领域，可信启动链的实现至关重要。Hubris项目作为嵌入式操作系统，面临着如何确保系统组件（特别是安全处理器SP和信任根RoT）的可信度量问题。当前架构中，RoT通过SWD任务记录SP闪存bank的度量值，但存在一个关键安全问题：非授权SP镜像可能篡改自身的度量记录。

现有机制分析

当前实现存在三个主要特征：

1. 度量触发机制：当SP_RESET引脚被置位时，RoT的swd任务会记录活动SP闪存bank的度量值
2. 度量时机限制：若RoT未完成初始化，则不会记录度量值
3. 控制平面交互：控制平面可通过请求SP重置来获取初始或更新的度量

安全威胁模型

最严重的威胁场景是：

• 非授权SP镜像启动后查询度量日志
• 如果发现已有记录则重置RoT
• 在首个日志槽位记录伪造的"可信"度量值
• 继续运行非授权代码，形成"伪装攻击"

解决方案对比

经过深入讨论，团队提出了三种改进方案：

方案1：度量来源标记

为每个度量记录添加来源标识。优点是可扩展性强，但需要预先定义所有可能的度量来源类型。

方案2：槽位分配机制

将日志改为固定大小的数组，预先分配特定槽位给特定组件。优点是访问控制明确，但缺乏灵活性且管理复杂。

方案3：首记录特权

仅允许swd任务创建首个度量记录，其他来源必须在已有记录后才能添加。这种方案改动最小，与现有API兼容性好。

实施建议与安全考量

最终团队采纳方案3，基于以下安全原则：

1. 最小特权原则：只有最底层的swd任务有权创建初始信任锚点
2. 防御纵深：通过DICE证书链确保RoT镜像的可信性
3. 可验证性：评估方可通过证书链验证RoT版本是否符合安全要求

系统级安全保障

完整的安全机制包含多个层面：

1. 固件签名验证：确保只有经过签名的RoT镜像能够执行
2. 新鲜度证明：支持获取带有时间证明的可信度量报告
3. 硬件控制能力：RoT可通过看门狗定时器等机制影响SP启动流程

未来演进方向

虽然当前方案解决了迫切的威胁，但长期来看需要考虑：

1. 自动化度量机制：实现RoT启动时自动度量SP
2. 分层度量架构：允许上层组件报告度量集合的哈希值
3. 安全启动序列：优化RoT与SP的启动时序协调

这种安全设计模式不仅适用于Hubris项目，对于其他嵌入式安全系统的可信计算基(TCB)设计也具有参考价值。通过硬件与软件的协同设计，构建起从底层硬件到上层应用的完整信任链。