SoC有AXI总线了，安全密钥分发为何还要专门协议？

现代 SoC 里的加密功能越来越多：PCIe 需要保护链路数据，DRAM 控制器可能负责内存加密，网络接口要运行 MACsec，AI 加速器也可能处理不同租户的敏感数据。

这些硬件模块都需要密钥，但密钥从哪里来？如果每个模块都自己生成、保存和更新密钥，整颗芯片就会出现多套独立的安全管理机制。更麻烦的是，密钥还必须经过片上互连，才能从安全模块送到实际使用它的地方。

在 2026 年 OCP 全球峰会上，Marvell 介绍了一套面向 SoC 硬件模块的安全密钥分发协议（Key Distribution Protocol，KDP）。它试图解决的问题很具体：如何让一颗芯片里的多个硬件模块共享统一的密钥管理能力，同时避免密钥在传输过程中暴露。

Caliptra 硬件信任根通过 KMTx，向 SoC Fabric 上的 PCIe IDE、DRAM 控制器、MACSec、加密加速器四类端点（各内嵌 KMRx）分发密钥。来源：OCP EMEA Summit 2026《Caliptra as Server Security Hub – Key Distribution Protocol》（Marvell）

01｜为什么不能直接通过 AXI 写入密钥？

假设 PCIe 控制器需要一把新的数据加密密钥，最简单的办法是让安全处理器把密钥写入 PCIe 控制器的配置寄存器。

从功能上看，这和普通 MMIO 写操作没有太大区别。但密钥一旦以明文形式经过片上互连，就必须考虑哪些模块能够观察这次传输、哪些主设备能够访问目标寄存器，以及调试接口是否可能暴露敏感数据。

即使 AXI 互连配置了访问权限，也不意味着传输内容天然受到加密保护。

KMTx/KMRx 端点内部结构：两侧各持一把 BEK，AES-256 在发送端把明文 DEK 加密，密文经 SoC Fabric 传输，接收端还原后交给硬件模块。

KDP 采用另一种方式：在密钥发送端设置 KMTx，在接收端设置 KMRx。真正的数据加密密钥（DEK）发送前，先使用总线加密密钥（BEK）进行加密。

这样一来，即使密钥分发消息需要经过片上共享互连，传输的也不是明文 DEK。

片上互连负责把消息送到目的地，KMTx/KMRx 负责保护消息里的密钥，两者承担不同职责。

02｜密钥从哪里来？

这套架构以 Caliptra 硬件信任根（HRoT）作为中心安全模块，由它统一管理向其他硬件模块提供的数据加密密钥。

Caliptra 本身是面向芯片的开放硬件信任根项目，能够为设备身份、启动验证和密钥管理提供安全基础。

在 KDP 方案中，发送端和接收端之间还需要建立 BEK。它相当于一把专门用于保护密钥分发过程的密钥，与最终提供给 PCIe、DRAM 或加密加速器使用的 DEK 不是同一回事。

BEK 派生方案三：MSS = MSS1‖MSS2，KDF 输入含 AXI_ID 与 MMIO 地址，BEK = AES(MSS, AXI_ID‖ADDR)，每个 KMRx 实例一把。

OCP 公布的方案使用两个秘密值参与 BEK 派生：一个是在启动时生成的随机秘密 MSS1，另一个是通过 RTL 实现引入的秘密 MSS2。

BEK 还与目标模块的 AXI ID 和 MMIO 地址绑定，使不同接收端获得的密钥保护关系有所区别。

这相当于为每个硬件端点建立独立的密钥分发上下文。即使某个端点发生安全问题，也不应让其他端点直接共享同一把传输保护密钥。

需要注意，AXI ID 和 MMIO 地址主要用于绑定接收端身份与位置，不能仅凭这两个字段就证明接收端可信。实际安全性仍依赖秘密值保护、密钥派生和端点访问控制。

03｜为什么还要设计专门的协议？

只把 DEK 加密还不够。接收端需要知道密钥什么时候有效，发送端也需要确认密钥是否已经正确安装。

因此，KDP 除了密钥传输，还定义了消息顺序、流量控制、响应确认以及密钥清除等操作。

例如，当安全模块向 PCIe 控制器下发一把新密钥时，发送端不能仅凭消息已经写入总线，就假定 PCIe 控制器已经完成配置。接收端需要返回对应的确认消息，系统才能继续后续操作。

KMRx 寄存器映射：最多 256 个密钥槽（每把 DEK 16B）、用 Check Value 校验密钥是否有效、通过 Key Control 执行 Zeroize 清除。

协议还支持带标签的响应，以及用于控制发送节奏的 Credit/Debit 机制，避免多个端点同时请求密钥时出现无法管理的事务积压。

另一个重要操作是 Zeroize，即清除密钥。当某个硬件模块复位、租户切换或安全状态发生变化时，系统需要能够让接收端清除不再有效的密钥，而不是只依赖软件重新写入配置。

这些功能说明，密钥分发不仅是一次数据搬运，还涉及硬件端点之间的状态同步。

04｜Chiplet 会让这个问题更复杂

当 SoC 进一步拆成多个 Chiplet，密钥分发路径可能跨越 Die-to-Die 互连。

KDP 在设计时既考虑了片内连接，也考虑了通过 UCIe 跨 Die 传输。它可以使用点对点串行通道，也可以在适当情况下通过共享总线传输加密后的密钥消息。不同 Chiplet 可能处于不同的时钟域，甚至存在独立的复位和电源管理。协议因此允许设置中继式安全 Hub，处理跨时钟域等连接问题。

但中继节点不应因此获得任意读取其他端点 DEK 的能力。如何限制中继节点权限，是整个硬件信任边界设计的重要部分。

KDP 还引入了 SoC、封装和外部连接等边界标签，供系统执行密钥分发范围相关的安全策略。Chiplet 把计算资源拆到了不同 Die 上，密钥管理却仍然需要维持统一、可验证的安全关系。

05｜架构工程师能学到什么？

这套方案展示了一个很典型的 SoC 架构取舍：安全功能应该分散到每个硬件模块，还是集中到统一的硬件信任根？

完全分散的方案让每个模块独立管理密钥，但会增加重复设计、验证和安全维护成本。集中式方案能够统一密钥来源，却必须解决中心模块与大量硬件端点之间的安全通信问题。KDP 选择把密钥管理集中到硬件信任根，同时通过轻量级 KMTx/KMRx 端点，让各个硬件模块保留独立的密钥接收和保护能力。

系统级视图：Caliptra 与四类需要密钥的硬件模块经“不可视为安全”的 SoC Fabric 互连，这是 KDP 要保护的传输路径。

这里的关键设计并不是增加一种新的加密算法，而是把密钥生命周期管理、片上消息传输和端点安全边界拆成不同的硬件职责。

对于越来越复杂的 AI SoC 和 Chiplet 系统，这种分工能够减少各模块重复实现安全管理功能的需求，同时让密钥在跨模块、跨 Die 传输时获得明确的保护机制。

当然，目前公开资料主要展示的是协议架构和设计机制，尚不足以证明它已经在大规模量产 SoC 中部署，也没有足够数据评价其面积、功耗和传输延迟开销。

但它提出的问题已经十分现实：当一颗芯片里的加密引擎越来越多，如何把密钥安全送到正确的硬件模块，本身就需要成为一项独立的 SoC 架构设计。这类硬件信任根与安全总线设计的演变，也是云栈社区持续关注的芯片架构方向。