平台集成与管理/技术文章

平台数据与密钥安全

PSP包安全、L.O.C.K.密钥层次与设备生命周期

11 分钟阅读·PSP / L.O.C.K. / Caliptra / 密钥管理 / 密码学擦除

解析PSP接收密钥派生、nonce与轮换,以及Caliptra L.O.C.K.的多方授权、介质密钥隔离和纪元擦除。

正文

AI Factory的数据同时处在网络传输、设备处理和持久存储中。网络加密需要适应海量连接与高带宽;存储加密需要保证密钥在固件漏洞、设备失窃和退役过程中仍可控;管理接口则决定谁能更新固件、启用设备和改变密钥状态。这些路径需要分别设计,再由统一的设备身份与生命周期管理串联。

OCP PSP Architecture与L.O.C.K.分别从包处理和存储密钥路径提出开放设计。PSP在原文中称为PSP Security Protocol,是Google为传输中数据加密创建的协议,通过接收端逐包派生密钥降低连接状态成本;L.O.C.K.通过Caliptra中的Key Management Block隔离介质密钥,并将数据访问、多人授权和密码学擦除落实到密钥层次。S066 pp. 5–9 S065 pp. 11–16

PSP将接收密钥表转化为密钥派生#

PSP中的安全关联SA将一组报文绑定到相同的加密与认证处理,可细至单条TCP连接,也可覆盖VM间隧道。SA包含SPI、加密密钥、Crypt Offset、流量机密性配置和生命周期。发送侧保存该SA的加密密钥,接收侧则使用报文携带的SPI与NIC内部主密钥重新派生解密密钥。S066 pp. 8–10

这一变化针对大规模NIC的两个成本:连接状态占用与连接建立时的表项写入。规范给出一个容量演算:一千万连接、每连接双向各256 B SA数据,总量约5 GB;省去接收密钥一侧可减少约2.5 GB。若发送描述符可携带SA信息或指向主机内存,还可进一步降低NIC驻留状态。该数字描述架构容量推演,实际收益取决于SA粒度和实现。S066 p. 7

读下面的接收流水线时,重点看SPI进入密钥派生块,而非访问逐连接密钥数据库;再看ICV Check如何决定放行或丢弃。报文识别、密钥派生、认证解密和错误统计需要在同一条高速数据路径上完成。

PSP接收流水线中的SPI密钥派生 认证解密与ICV检查

原图:PSP Architecture Specification,Figure 10,物理第23页。S066 pp. 23–24

接收NIC持有两把256 bit AES主密钥,仅保存在NIC易失RAM中,并防止通过PCIe或调试接口读取。SPI最高位选择主密钥,其余31 bit用于SA索引。创建新SA时接收端选择SPI、派生密钥,再经安全握手交给发送端;相同主密钥下SPI不能复用。握手服务、认证和密钥交付因此成为控制面的关键组成。S066 pp. 8–10

两把主密钥允许轮换期间兼容旧连接:新SA切到新活动密钥,旧SA继续使用旧密钥,直到结束或达到生命周期再淘汰。规范以24小时为名义轮换周期,31 bit空间对应约24855个SPI/秒的平均消耗预算;若连接创建更快,需要调整轮换及SA聚合策略。单个派生密钥的撤销通过主密钥轮换实现,影响范围与SA分组必须一起考虑。S066 pp. 12–13

报文可观测性与密码学约束共同进入Fabric设计#

PSP以AES-GCM实现加密与认证,也支持只认证的AES-GMAC模式;认证范围从PSP头开始覆盖到payload结束。AES-GCM可通过Crypt Offset将前部部分payload保留明文但仍受认证保护,便于中间节点读取传输字段。当前封装在UDP内,目的端口1000,源端口携带内层流哈希相关熵供ECMP/WCMP选路;加密、负载分担和包采样因此可以协同设计。S066 pp. 5, 7, 14–20

nonce唯一性是另一项硬约束。PSP以32 bit SPI拼接64 bit计数值构成96 bit IV,计数值按皮秒单位编码,并要求相同密钥下不重复。800 MHz时钟每周期可以增加1250个编码单位;编码单位表达计数分辨率,不代表设备有皮秒级授时准确度。设备重置、计数回绕和主密钥更替都必须保持nonce不重用。S066 p. 12

完整性验证通过后仍需由上层运输协议实施回放保护。对TCP可以依赖其相应机制;其他运输应落实等价保护。NIC还须提供认证失败、格式错误、无效SPI或不支持版本等统计,并允许限速捕获错误包帮助诊断。将这些统计与NIC分层管理和Fabric可靠传输联动,才能区分密钥生命周期故障与真实网络故障。S066 pp. 13, 24

L.O.C.K.把介质密钥从驱动固件中隔离#

L.O.C.K.的全名是Layered Open-source Cryptographic Key management,目标是自加密存储设备的静态数据保护。它是Caliptra的扩展,可用于多种SED,并兼容TCG Opal、Enterprise和Key Per I/O模型。驱动固件仍处理主机存储命令和密钥生命周期请求,Caliptra KMB承担原始介质密钥MEK的保护及向加密引擎编程。S065 pp. 11–14

其威胁模型包括被盗设备运行任意固件、供应链拦截、调试日志泄露以及侵入式分析。隔离的意义是把“固件能请求一次密钥操作”与“固件能读取密钥明文”分开。KMB通过邮箱提供服务,介质密钥经受保护的硬件接口进入加密引擎;驱动固件只能持有受保护的封装或派生所需输入。S065 pp. 11–15, 47

下面的密钥层次图应分三段阅读:顶部外部access key经HPKE进入设备;中部DPK、MPK和epoch材料共同决定访问条件;底部才产生或解封装MEK并送入加密引擎。图中不同颜色区分持久、易失和短暂存在的值,生命周期是理解擦除与重置行为的关键。

L.O.C.K.外部授权 密钥层次与介质密钥生成加载关系

原图:OCP L.O.C.K. 1.1 RC4,Figure 2,物理第16页。S065 pp. 14–20

DPK由数据所有者管理,一个MEK绑定一个DPK;零个或多个MPK代表额外授权方,每个MPK依赖独立的外部access key。access key通过HPKE保护,可以由远程KMS交付而不向主机暴露。先将Locked MPK启用,再参与MEK secret派生,使多方同意落实为真实密钥依赖。S065 pp. 14–16, 22, 28–33

实现上还要区分驱动固件与受Caliptra保护的KMB固件。某些密码材料在KMB内存中短暂存在,原始随机MEK初次生成也有特定内部路径;它们仍不向驱动固件开放。对已封装MEK增加MDK内层保护,可防止被攻破的KMB运行固件利用AES-GCM接口返回明文;硬件强制特定解密结果进入Key Vault。S065 pp. 19–20, 39–42

纪元擦除把退役状态变成可验证对象#

HEK与SEK共同构成epoch保护,全部MEK依赖该epoch。SEK由驱动固件管理并存于可重写存储,HEK从熔丝中的seed及设备秘密派生。清除其中一项即可切断相应密钥材料的可恢复性;清除SEK时还须清掉加密引擎的key cache,防止旧密钥继续驻留。S065 pp. 15, 34–37

HEK seed使用4至16个256 bit熔丝槽,按blank、randomized、zeroized推进。设计要求先清SEK再清HEK seed;冷启动时ROM读取当前seed并报告HEK状态。槽位消耗完后可选择永久HEK模式延长设备使用寿命,这意味着硬epoch轮换能力本身是需要规划的有限生命周期资源。S065 pp. 35–37

多人授权密钥的轮换也有顺序。更新access key时,调用者需证明同时掌握旧值与新值,KMB解开旧封装并以新值重新保护MPK;之后驱动固件清除旧封装并保存新封装。重置时HPKE密钥对需要重新生成,冷重置还会使启用态MPK所依赖的VEK失效。KMS可用性、重启恢复和数据访问恢复应在同一组故障场景中验证。S065 pp. 30–33, 46

验证密钥状态转换及失败后的恢复路径#

评估这两类设计时,可以沿密钥状态逐次重建操作。PSP先建立SA并验证双向流量,再轮换活动主密钥,观察旧连接与新连接是否按预期并存;随后淘汰旧密钥,确认旧SPI不再被接受、相关失败统计可见。发送失败必须在上线前丢弃,避免把明文带到网络,这项行为应与认证失败和不支持版本的接收处理一起核查。S066 pp. 8–13, 24

存储侧则从锁定MPK、启用MPK、加载MEK到卸载MEK逐步验证。改变某一授权输入后,先观察错误能否送达主机,再确认加密引擎没有误装入另一把密钥。对于派生MEK,L.O.C.K.提供可选checksum机制,用于识别输入损坏导致的密钥改变;规范举例说明SEK在内存中翻位后,旧checksum可阻止加载错误密钥,避免新写入数据在后续重启时无法恢复。S065 pp. 42–44, 73

密码学擦除还要核对运行中的缓存与持久材料。仅删除一份封装不足以回答其他副本是否存在;epoch方案将全盘MEK依赖收敛到HEK/SEK,并要求相应key cache清除。产品集成验证需覆盖ROM状态报告、引擎接口、驱动生命周期调用及主机授权。规范预期通过OCP S.A.F.E.评审检查L.O.C.K.集成和调用方式。S065 pp. 11–15, 35–37, 76–77

这些测试同时揭示可用性成本。外部KMS、access key或恢复流程缺失时,安全隔离可能正确地拒绝数据访问。因此项目需把密钥备份、授权方服务等级、设备重启顺序和紧急恢复纳入运营设计,并保留每次状态转换的证据;密码机制与业务恢复的责任可以由此明确对接。

用共同生命周期连接网络、存储与管理安全#

网络侧需要验证密钥创建、轮换与失败统计;存储侧需要验证授权、加载、清cache及擦除状态;管理侧需要验证固件更新、重置和通道隔离。OBMF-ICP提供多通道聚合,敏感内容可由SPDM等既有机制保护;TPM通道使用对应安全会话,同时防止一条通道的异常影响其他通道。S069 pp. 79–81

由这些机制推导出的平台路线是:把身份、固件版本、密钥epoch、授权方和操作结果纳入同一变更记录;故障演练覆盖失联、重启、部分升级及外部KMS不可达;退役验收检查已擦除状态及证明链。这样安全投入可以同时支持租户隔离、自动化维护和设备再使用,后者又进入全生命周期可持续性评价。

本文引用 3 份原始资料S065OCP L.O.C.K. ↗S066OCP PSP Architecture Specification ↗S069obmf-icp-1-0-0 ↗

延伸阅读

存储层级与分布式数据服务↗AI 传输中的包序、事务序与完成边界↗可靠性服务与故障闭环↗能源水碳与材料联合评价↗

输入关键词,查找全部技术文章。

全文搜索 · 在浏览器本地运行↑ ↓ 选择 ↵ 打开
阅读导航
技术路径总览 ↗

01总体架构

  1. AI Factory 的系统架构与跨域约束
  2. AI Factory 的系统分层与运行闭环
  3. 从 Pod 组到开放集群的端口扩展
  4. 拓扑放置与端到端性能建模
  5. 面向 3–5 年的技术布局与验证资产

02计算与状态

  1. 低精度计算的表示、缩放与数据路径
  2. 并行策略塑造通信关键路径
  3. 推理解耦与 KV 数据路径
  4. Agent 状态与因果恢复
  5. 存储层级与分布式数据服务
  6. 芯粒系统语义与封装内传输分层
  7. 高带宽闪存的主机与媒体协同
  8. 量子处理器的经典闭环与设施集成

03网络与光互联

  1. 训练 Fabric 的流量控制与运行闭环
  2. AI 传输中的包序、事务序与完成边界
  3. 拥塞反馈与多路径的端点控制环
  4. Scale-up Ethernet 的事务、打包与链路契约
  5. 光电链路的距离、功耗与维修边界
  6. 光电路交换的拓扑与时间匹配
  7. 硅光平台的封装、制造与开放集成
  8. 从链路恢复到作业进展的 Fabric 运维

04液冷与热管理

  1. 从结温到热汇:AI 冷却的热边界与设计包络
  2. 液体回路的热量、压头与动态平衡
  3. 冷却液与接液材料的共同设计
  4. 液体连接器的尺度、自由度与服务接口
  5. 冷却资格验证:从材料试片到动态系统验收
  6. 液冷系统的清洁、充排液与长期维护

05供电与能源

  1. 从中压到芯片:AI 工厂电源架构的分层重构
  2. 高压直流变换:SST、LLC DCX 与板级供电的协同
  3. 机架电源系统:从 72 kW AC 到 100 kW HVDC 的接口链
  4. AI 负载的电力动态:阶跃、储能与母线阻抗
  5. 备用与储能:从脉冲缓冲到清洁能源的连续供电
  6. 高功率直流的安全闭环:故障能量、选择性与运行状态

06平台集成与管理

  1. 机架集成与开放接口
  2. 硬件管理与接口收敛
  3. 平台数据与密钥安全
  4. 可靠性服务与故障闭环
  5. 时间同步与跨域测量
  6. 光互连的远端消息与故障闭环
  7. 园区漫游组播的成员迁移与同步呈现

07设施与运行优化

  1. 数字孪生:系统模型、联合仿真与运行闭环
  2. 设施接口与系统交付
  3. 能源水碳与材料联合评价