当前位置: 首页 > news >正文

ARM CCA机密计算安全模型之固件更新

安全之安全(security²)博客目录导读

目录

1、远程更新

2、本地更新

3、鲁棒性


1、远程更新

Arm欢迎关于CCA固件更新需求的反馈。一般而言,CCA固件更新过程可以描述如下:

  1. CCA固件更新客户端使用固件更新协议与远程更新服务通信。
  2. CCA固件更新客户端将下载的CCA固件复制到临时暂存位置。
  3. 系统重启,并在启动过程中使用更新。

[R0134] Arm建议固件更新协议元数据的签名和验证应独立于固件签名和固件验证。
固件更新协议的选择不在CCA的范围内。例如,固件更新协议可能包含安全功能,如更新目标控制和防回滚计数器控制。这些功能可能包括协议级固件更新控制消息,以及固件负载。
固件更新客户端应验证CCA固件更新或CCA固件更新控制消息来自授权的更新源。在这种情况下,源通常不同于镜像签名者。例如,镜像可能由CCA固件分发者签名,而更新过程可能由服务提供商或托管提供商单独控制。
只有在重启后,更新才会生效。重启的范围可能会根据更新的范围有所不同。
CCA固件更新的示例范围包括:

  • 根更新:影响Monitor安全域或CCA系统安全域中的一个受信子系统
  • Realm世界更新:仅影响Realm世界
  • RMM更新:仅影响Realm世界中的CCA组件

本文档使用“执行更新”一词描述固件更新客户端将更新提供给CCA固件后,验证、安装和执行更新的过程。更新影响CCA的可信性,CCA固件有责任确保只有授权的更新才能被执行。
固件更新只能由更受信的安全域或安全域中最受信的组件执行。

[R0142] 根更新只能由CCA HES主机执行。

[R0143] Realm世界更新可以由Monitor执行。

[R0144] RMM更新可以由RMM执行。

根更新需要系统完全重启,Realm世界更新仅需要Realm世界的重启。
RMM更新可能只需要重启RMM,而不需要重启所有Realms。这样的Realm世界动态更新不在当前CCA版本范围内,但可能在后续版本中解决。

[R0094] 至少更新的有效性应始终在执行更新时进行验证。
根据生态系统的需求,有效更新可能是任何正确签名并符合防回滚策略的更新。或者系统可能需要通过安全固件更新协议进行显式更新授权后才能执行更新。

暂存位置通常是通用的外部存储。根据生态系统的需求,可能需要额外的完整性控制以防止未经授权的替换。例如,可能的要求是使用本地哈希锁定方案,或在显式更新授权消息中实现防重放机制。

[R0098] 在将身份元数据复制到暂存区之前,必须知道并验证至少加载已签名的CCA固件身份元数据所需的内存。

[R0135] 必须在将镜像负载复制到片上内存或受保护的外部内存之前,知道并验证所需的内存。

[R0136] 必须在从外部存储复制数据之前,确保分配并可用所需内存。
例如,签名的固件身份元数据和固件负载可以组合成一个固定最大大小的镜像。然后实现可以确保在复制之前始终有一个至少该大小的固定缓冲区可用。

或者,签名的固件身份元数据可以是固定大小,并包含负载的大小。然后,身份元数据可以复制到固定缓冲区并在那里验证,然后基于已验证的负载大小分配第二个动态缓冲区。

[R0137] 数据不能复制超出暂存区的边界。这防止缓冲区溢出攻击。

[R0099] 重启后,启动过程的相关部分检测到可用的更新,并尝试以正常方式加载它。
系统在任何更新后必须保持可认证性。
根更新后系统始终是可认证的,因为它需要系统完全重启。它不会在运行时更改依赖方所认证的系统启动状态。
Realm世界更新后,Realm世界将重启,包括所有的Realms,确保更新后的Realms根据新的Realm世界状态进行认证。
在动态RMM更新的情况下,系统的启动状态在运行时发生了变化,与依赖方在更新之前认证的状态相比有所不同。RMM执行动态更新的能力必须反映在最初对依赖方的认证中。例如,作为服务级别协议的一部分,针对固件版本和测量值,或者针对已签名的固件身份元数据。
在动态RMM更新的情况下,无法可靠地更新任何已认证的Realms的状态。这也是为什么执行动态更新的能力必须是最初认证契约的一部分。

然而,任何动态RMM更新后的认证请求必须反映CCA平台的新状态。
同样,在动态RMM更新的情况下,更新后的状态可能会影响CCA派生的Realm密钥。
动态RMM更新和CCA派生的Realm密钥不在当前CCA版本范围内,可能会在后续版本中解决。

[R0101] 依赖方可以确定CCA平台的实现是否具备世界更新或Realm世界增量更新的能力。

2、本地更新

本地更新是指需要物理访问系统的更新。例如,通过USB更新、串行链路更新或启动过程中的救援加载程序功能。
总体过程及其安全属性应与远程更新的情况相同。例如,USB或串行链路更新可以视为固件更新协议的不同传输方式。或者救援加载程序可以视为CCA固件更新客户端的特殊情况。

3、鲁棒性

[R0100] 任何CCA固件更新机制必须能够应对更新失败。
防回滚和恢复应按照CCA固件启动的定义进行管理。


http://www.mrgr.cn/news/82636.html

相关文章:

  • Docker安装Prometheus和Grafana
  • 公共数据授权运营机制建设(六大机制、存在问题、发展路径)
  • 【Ubuntu】 Ubuntu22.04搭建NFS服务
  • Flink系列知识讲解之:深入了解 Flink 的网络协议栈
  • 2025年贵州省职业院校技能大赛信息安全管理与评估赛项规程
  • 融乐 1.1.6 | 拥有海量音乐资源的第三方音乐软件,支持无损音质下载
  • 代码实战:基于InvSR对视频进行超分辨率重建
  • Unity-Mirror网络框架-从入门到精通之Benchmark示例
  • 1.1.2.1 选择 + 冒泡排序
  • Oracle 11g rac + Dataguard 环境调整 redo log 大小
  • 与 Oracle Dataguard 相关的进程及作用分析
  • 1.1.7 master公式的使用
  • 1.2.1 归并排序
  • 智能工厂的设计软件 应用场景的一个例子:为AI聊天工具添加一个知识系统 之13 方案再探之4:特定于领域的模板 之 div模型(完整版)
  • 三子棋游戏
  • web漏洞之文件包含漏洞
  • 模型训练二三事:参数个数、小批量、学习率衰减、输入形状
  • SCAU期末笔记 - 数据库系统概念往年试卷解析
  • MyBatis执行一条sql语句的流程(源码解析)
  • 域上的多项式环,整除,相通,互质
  • 【精读电影】至暗时刻
  • unity-入门查漏补缺0.2.02.07
  • RocketMQ场景使用
  • window11 wsl mysql8 错误分析:1698 - Access denied for user ‘root‘@‘kong.mshome.net‘
  • RocketMQ使用场景问题
  • Eplan 项目结构(高层代号、安装地点、位置代号)