摘要

  • Caliptra 是面向数据中心片上系统的开源信任根项目，由 AMD、Google、Microsoft 和 NVIDIA 于 2022 年通过 Open Compute Project 发起。
  • 其核心结合了不可变 ROM、可变固件、生命周期控制、密码硬件、DICE Protection Environment，以及面向 CPU、GPU、DPU、加速器和存储控制器的证明服务。
  • Caliptra 2.x、Caliptra Subsystem、Adams Bridge 和 OCP L.O.C.K. 扩展了这一设计，但组件兼容性、补丁历史和集成仍是重大的运营风险。
  • 公开 RTL 有助于加强审查，但不会揭示所有物理实现、配置系统、背书证书或生产部署；现有资料也未提供完整的出货统计。

四家竞争者把信任根视为共享基础设施

AMD、Google、Microsoft 和 NVIDIA 于 2022 年 10 月在 Open Compute Project Global Summit 上宣布 Caliptra。创始成员既有芯片供应商，也有商业利益往往相互竞争的超大规模云运营商，但它们面对的安全问题存在重叠。

AMD 和 NVIDIA 制造复杂的处理器与加速器，需要内部信任机制。Google 和 Microsoft 运营的机群规模庞大，不一致的组件证据会转化为运营成本。专有信任根可以在单一产品内发挥作用，但每一种独立设计都需要新的审查、集成和验证逻辑。

这个共享项目提供了竞争前的共同基础。各公司可以在身份、度量启动、固件认证和证明方面合作，同时继续在处理器、加速器、云服务和制造领域保持差异化。

Open Compute Project 是自然的发布平台，因为它本已围绕服务器、存储和安全需求汇集大型运营商与硬件供应商。Caliptra 的主要规范仍处于这一环境之中。该设计并非面向爱好者的开放硬件实验，而是供制造数据中心芯片的组织采用。

仅有规范工作并不足够。文本可以定义接口和必要行为，却无法揭示 RTL、固件或验证中的缺陷。2022 年 12 月，Caliptra 加入 CHIPS Alliance，后者在 Linux Foundation 生态体系下提供公共代码库、贡献规则、许可证、会议和持续实施流程。

这种机构分工至今仍是该项目的主要特征之一。OCP 发布重要需求和用例规范；CHIPS Alliance 内的 Caliptra Workgroup 开发代码、固件、验证工具和发行版本。这种分工并非泾渭分明——许多相同公司同时参与两边——但它避免了项目被描述成某一家供应商附带公开文档的私有安全控制器。

创始成员之间的一致也有边界。共享代码并不意味着共享背书层级、工厂流程或部署计划。每个集成方都自行决定如何制造和配置该模块。共同信任根可以减少重复工程，但不会把产品控制权移交给项目。

开放许可把成本转移到集成和保障环节

Caliptra 采用 Apache License 2.0 发布。供应商可以重复使用并修改设计，无需向传统安全模块供应商支付按件计算的专有 IP 许可费。共享开发可以减少重复劳动，并让运营商对共同接口产生更大影响。

成本只是发生转移，并未消失。工程师必须集成模块、验证产品、实施物理防护、管理配置并支持现场更新。独立评估和芯片制造后的验证费用高昂。分叉代码的供应商还必须在漏洞和标准变化期间持续维护自己的分支。

大型创始公司能够承担这些成本并投入专业人员。规模较小的芯片企业可能受益于共同设计，却没有资源开展同等深度的评估。开放访问可以扩大参与范围，也可能造成保障水平不均。

项目能否持续，取决于贡献者是否继续资助有利于整个生态体系的工作。只有修复和功能回归公共主线，而非碎片化为私有分支，共同模块才能降低成本。产品进度和披露限制可能削弱这种动力。

对采购方而言，经济价值并不只是免费的 RTL，而是不同供应商可以提供可比较证据，并降低对私有信任根设计的依赖。只有当实现文档足以支持替代或审计时，这种价值才会兑现。

健康的生态体系可能围绕开放核心形成商业验证、集成和证书服务。这些业务可以在不占有项目的情况下资助专业能力，也可能带来需要与共享规范区分开的新依赖。

最适合把 Caliptra 理解为竞争前基础设施。许可证让合作在法律上成为可能；治理和持续工程则决定合作能否长期具备经济可信度。

服务器不再只有一条首条指令，也不再只有一道安全边界

传统的安全启动示意图始于一个处理器、一个不可变的初始阶段，以及通向操作系统的一连串签名软件。如今的数据中心服务器却是多个计算系统的集合。GPU 可以运行大量固件，DPU 可以控制网络、存储和主机管理，加速器可以独立加载代码，存储控制器则可能保存加密密钥并决定介质是否可读。

每个组件都有自己的第一条指令和首次信任判断。如果某个控制器在主机开始检查前已被攻破，主机的干净启动可能无法说明整台机器的状态。云运营商需要来自各个组件的证据，而这些组件的内部安全设计历来因供应商和产品线而异。

Caliptra 在芯片层面处理这种碎片化边界。它定义并实现片上系统内部用于度量的集成信任根。该模块建立设备身份、认证并度量固件、执行生命周期策略，并生成可由其他系统评估的签名证据。

该项目有意把范围限定在完整平台管理处理器以内。它不调度工作负载、不运营云证书颁发机构，也不定义服务器内每一个安全启动阶段。较窄的范围旨在让该模块可在多类芯片中重复使用。

这种可复用性具有战略意义。从多家供应商采购组件的云服务商希望用共同方式询问：这是什么设备、它启动了什么代码、哪个权威机构为证据背书？芯片供应商则希望避免重新构建每一种密码和证明原语，同时保留对产品集成的控制。

共享层无法让所有设备变得相同。制造商会选择熔丝映射、物理防护、封装、时钟、存储器和配置方式；平台所有者则决定哪些度量结果可以接受。Caliptra 的价值在于为仍然多样化的供应链创建一个共同检查点。

这一差别也解释了为什么不应把 Caliptra 介绍为芯片公司。Caliptra 没有产品目录、股东或销售组织。它是一个协作式硬件和固件项目，其成果只有在其他组织将其集成进芯片后才成为实际产品。

设备秘密需要共同的证据规范

信任根需要一个普通软件无法改写的起始事实。Caliptra 结合设备唯一性材料、生命周期状态和不可变初始代码来建立这一基础，随后为后续组件派生身份与证据，而不是把最深层秘密交给每个调用方。

启动序列从 ROM 开始。ROM 认证并度量 First Mutable Code（FMC），后者继而建立运行时固件和服务。安全版本号可防止攻击者把可变固件回滚到仍有有效签名、但存在漏洞的旧版本。这个序列形成一条链，使后续代码的状态与更早、权限更受限制的权威相连。

Caliptra 通过 DICE Protection Environment 与 Trusted Computing Group 的 DICE 概念保持一致。DPE 可以根据度量结果和上下文派生复合身份，使片上系统内部的组件无需直接访问根秘密即可获得签名或证明能力。

这种委派对大型芯片十分重要。管理控制器、安全服务或其他组件可以提供与自身度量上下文绑定的证据。验证方可以区分源自同一物理信任根、但代表不同功能或状态的身份。

这一机制通常被概括为身份、度量启动和证明。这些词可能掩盖一项关键的责任分工：Caliptra 可以签署证据，但不会决定证据是否可接受。云端验证方还需要背书链、预期度量数据库，以及对结果不符情况的处置策略。

正确签名的度量结果可能描述获准运行、但仍有漏洞的固件。设备可能真实无误，却配置不当。证明服务也可能因策略过时而拒绝健康硬件。信任并非仅由签名产生；签名只是让一项声明可以归属于特定身份。

项目的贡献在于让这项声明源自公开且可复用的设计。机群运营商的贡献则是治理身份及其对应后果。混淆两者，会把度量引擎包装成它无法兑现的承诺。

Caliptra 的 DPE 可以为芯片内部组件派生身份。这些身份通过协议呈现，并由理解其含义的系统评估后才有用。DICE 和 SPDM 等标准提供了更广泛语汇的一部分；TPM 则可能在平台中提供另一种信任服务。

这些组件可以相互补充。Caliptra 能建立内部度量身份；SPDM 响应方可以在与另一组件通信时使用设备和度量证据；TPM 可以保存或报告面向主机的状态。具体链路取决于系统架构。

互操作性所需的不只是选择相同的签名算法。参与方还必须就证书规范、度量格式、上下文标签和错误处理达成一致。验证方需要知道某个身份代表物理芯片、固件环境还是受委派组件。把所有证书视为等价，会抹去架构原本要保留的区别。

规范通过收窄可选行为，使独立产品能够共同测试。它们也带来治理问题：由谁定义某个云环境或行业领域接受的规范？供应商专用规范可以使用开放协议，却在策略层重新造成锁定。治理范围更广的规范能够改善替代性，但推进速度可能慢于产品开发。

Caliptra 的可复用模块为实现方提供共同的身份派生源，却不能消除上层达成一致的需要。最可信的产品证据，应当把内部 DPE 状态连接到外部协议和验证方策略，而不在链路中留下含义不明的跳跃。

这也是应把信任根描述为证据生成方，而非通用信任服务的另一个原因。密码学可以绑定各个步骤，规范和机构则决定这种绑定意味着什么。

每一项签名度量的底层都是熵和密钥存储

信任根只有在密码材料不可预测且受到保护时，才能认证固件并签署证明。Caliptra 包含熵和密钥库功能，使敏感值无需经过普通主机内存。

逻辑设计无法保证每个物理熵源的质量。工艺差异、启动行为和健康测试都会影响随机性。下游集成方可能错误连接该模块，或因周边逻辑而削弱隔离。

密钥库还会带来可用性和生命周期问题。锁定密钥能够保护机密性，但策略错误时可能阻止恢复。擦除槽位可能是正确的退役操作；如果仍需使用身份或介质密钥，也可能成为不可逆的错误。

因此，验证不应只覆盖密码测试向量，还应覆盖熵健康状态、访问控制转换、复位行为以及断电时的故障表现。再强的签名算法也无法补救可预测的秘密，或在密钥抵达加速器前便已泄露的问题。

不可变 ROM 必须保持精简，因为每一行代码都会成为全生命周期义务

最早执行的代码拥有非同寻常的权限，也最难更新。ROM 一旦制造进设备，缺陷可能需要后续固件绕过、调整熔丝策略，甚至让芯片退役。因此，Caliptra 把大量功能转移到经过认证的可变阶段。

First Mutable Code 提供早期可更新层。运行时固件提供邮箱命令、签名和证明等运营服务。ROM 的任务是确认这些阶段获得许可，并维持其运行所需的安全条件。

该架构为 RTL、ROM、FMC 和运行时固件设置独立版本线。这比假装项目只有一个版本号更符合现实，但运营起来也更困难。集成方必须知道哪些组合兼容、接受哪些安全版本号，以及哪个组件可以安全绕过另一组件中的缺陷。

Caliptra 2.0 系列的兼容性指导曾因 ROM 交互而要求特定 RTL 补丁级别。这类警告并非脚注，而是表明不可变组件如何限制其上方的每一次更新。

防回滚策略还会带来另一项取舍。拒绝旧版本可以保护设备免受降级攻击，但过于激进地烧录安全版本可能使合法恢复无法进行。损坏的更新、遗失的签名密钥或紧急镜像可能因为硬件正确拒绝后退而无法使用。

制造商控制版本熔丝、镜像权威和恢复路径的配置方式。开放项目可以定义字段和逻辑，却无法确保每种产品都选择安全的运营策略。

2025 年和 2026 年的补丁版本证明这是一个仍在演进的项目，并不证明架构存在无法使用的根本缺陷。安全硬件十分复杂，出现缺陷不可避免。关键问题是缺陷位于何处，以及受影响层能否更新。公开补丁历史提高了可见性，也提醒采购方，芯片维护是一项持续多年的义务。

生命周期恢复不能成为第二个启动权威

芯片会经历制造、测试、生产、现场运行、返厂和退役。在一个阶段适用的访问权限，到了另一阶段可能十分危险。工厂工程师需要测试和调试能力，但生产设备不应向远程攻击者或未经授权的技术人员开放同样的路径。

Caliptra 使用生命周期输入、熔丝状态和调试解锁机制来区分这些阶段。具体集成仍由制造商决定。信任根可以评估状态并执行策略，但物理引脚、调试结构和配置工作站均位于通用模块之外。

永久关闭调试可以缩小攻击面，却会增加后续诊断难度。保留解锁路径有助于维修，同时也会产生高价值凭据或质询机制。设计不当的退料流程可能重新引入生产策略原本要移除的访问权限。

生命周期错误也可能无法逆转。被烧录到错误状态的设备可能无法使用；保留时间过长的制造密钥可能削弱现场所有权；无法在退役时安全转换状态的产品，可能在转售和回收过程中泄露数据或凭据。

这些决定常被视为工厂细节，其实属于安全架构的一部分。没有制造商设计的策略和凭据系统，信任根便无法区分合法技术人员与攻击者。

公开生命周期逻辑可以改善审查。集成方能够检查允许的转换并分析故障，但它不会揭示某家工厂是否保护了密钥、熔丝是否正确编程，或电路板是否存在绕过该模块的另一条调试路径。

因此，Caliptra 把生命周期执行的重要部分纳入共享代码，同时把责任留在物理现实所在之处。项目可以让不安全状态更难定义，却无法监督每一条生产线。

只会拒绝不良固件的信任根，可能把原本可恢复的事故变成设备报废。Caliptra 2.0 增加了与 OCP 恢复工作一致的支持，使平台能够在软件损坏或更新失败后进行恢复。恢复必不可少，因为可变固件预计会在芯片整个生命周期中持续变化。

恢复路径同时也是能够替换代码的权威，需要自己的认证、版本规则和触发条件。如果攻击者能用恶意镜像调用它，安全启动就会被维修机制绕过；如果策略过严，运营商可能在密钥或清单遗失后无法恢复设备。

因此，恢复设计需要第二条不会悄然超越第一条链的信任链。信任根需要知道哪个权威可以提供恢复材料、是否允许回滚，以及生命周期状态如何影响操作。平台所有者则需要在可能比原工程团队存续更久的产品生命周期内，保存并轮换恢复凭据。

恢复还会影响可用性。反复进入恢复状态的设备可能无法加入机群，即使其秘密仍受到保护。运营商需要通过遥测区分签名失败、存储损坏、组件版本不兼容和主动隔离。缺少这些证据时，安全控制器看起来可能只是已经损坏。

项目可以规定机制并测试常见路径。下游系统则控制镜像分发、网络访问、现场服务和硬件退役决定。只有在紧急情况发生前演练这些运营环节，恢复功能才能成为有韧性的基础设施。

标准路径的存在仍有价值。它降低了把未记录工厂接口保留为唯一维修选择的诱因。Caliptra 可以让恢复成为经过审查的架构组成部分，而不是产品出货后才设计的特权例外。

每次后续度量背后都有一套私密的配置仪式

在 Caliptra 能够证明任何内容前，制造商必须创建或派生设备唯一性材料、设置生命周期状态，并建立验证方愿意信任的背书。这些工作发生在项目不负责运营的工厂和安全配置系统中。

遭到攻破的配置工作站可能植入可预测的秘密、签发欺诈证书或记录私密材料。后续启动度量可能在密码学上完全正确，却根植于攻击者控制的身份。若无独立恢复设计，再多现场验证也无法修复被破坏的起点。

工厂还需要良率测试和调试。流程必须开放足够权限以诊断新芯片，同时确保测试凭据和生命周期权限不会进入生产。合同制造商、封装厂和物流服务商还可能在芯片设计方之外增加更多组织边界。

开放规范可以定义预期熔丝字段、身份派生和状态转换，并通过明确逻辑仪式来支持审计。它们无法公开每一把密钥、流程控制或设施布局。一些保密措施是保护运营系统所必需的，但保密也会增加外部保障难度。

因此，采购方应要求与风险相称的配置证据：职责分离、密钥生成控制、证书审计、生命周期测试记录，以及工厂或证书颁发机构变更时的连续性。如果两种芯片都依赖同一个未记录的背书服务，第二供应来源并不构成真正替代。

Caliptra 的供应链价值在于标准化配置完成后的接口，并说明制造商在此前必须完成什么。项目不会取消这套仪式，而是让客户更容易识别仍然存在的私有信任。

邮箱既是服务边界，也是攻击面

主机固件和其他组件需要一种向 Caliptra 请求服务的方式。邮箱为运行时固件提供受控命令路径，用于度量、签名、密码运算、更新和恢复等功能。

相比暴露内部内存或密钥，狭窄接口更为可取。命令可以验证参数并限制访问，使信任根能够在保持秘密隔离的同时支持芯片其余部分。

同一接口也构成攻击面。调用方可能已被攻破、发送畸形输入，或只是产生过多请求。解析器必须处理不可信输入。耗时的密码操作可能占用信任根有限的处理能力，请求洪泛可能延迟启动或证明，权限错误则可能向本不应使用某些命令的组件开放访问。

由于信任根处于中心位置，拒绝服务造成的后果比普通外设故障更广。安全组件一旦不可用，平台可能无法证明自身状态或完成恢复。

设计需要命令授权、速率或顺序控制、谨慎的内存边界和可观测性。集成方需要决定哪些主机代理可以调用哪些功能，以及故障应如何呈现在机群遥测中。

这揭示了安全硬件更广泛的事实：隔离并不足够。受保护服务必须在恶意或错误需求下保持可用。信任边界的性能和可用性本身就是安全属性。

Caliptra 的公开实现使贡献者能够共同审查和测试这些路径。下游产品仍可改变封装逻辑、总线和仲裁方式，因此产品保障必须识别完整调用路径，而不只是公共命令处理程序。

独立评估使项目超越自我陈述

开放硬件常以“任何人都能检查”为依据进行辩护。实际问题在于，合格审查人员是否有时间、工具和产品背景开展检查。NCC Group 于 2023 年对 Caliptra 进行的公开评估，对明确范围内的架构和实现状态提供了重要外部审查。

评估可以发现设计歧义、不安全假设和实现缺陷，也可以确认重要边界已得到考虑。公开结果让社区能够看到问题如何处理，而不必只依赖创始公司的保证。

评估范围十分重要。审查只适用于特定版本、配置和攻击模型。后续版本会增加代码；供应商可能修改 RTL、采用不同工具进行综合、选择不同存储器实现，并将其置于具有新侧信道的物理环境。项目层评估无法认证所有这些结果。

验证仪表板、回归测试和发行检查清单处理保障的另一部分。它们可以表明既定属性和测试用例持续通过。覆盖率是有用证据，但不能证明不存在尚未发现的缺陷。

硬件验证也不同于软件测试，因为部分缺陷会成为永久问题。仿真、形式化方法、FPGA 原型和流片前测试必须在流片前发现错误。芯片制造后的评估则可能揭示模型遗漏的物理和集成行为。

项目愿意公开问题和补丁版本，应被视为成熟表现。当历史中包含缺陷、决策和修复时，安全声明才更可信。看不到任何问题的代码库可能意味着完美、审查不足或私下处理；公众无法判断究竟是哪一种。

下一步保障工作是提供产品专属证据。采购方需要知道采用了哪个公共版本、做过哪些修改、如何评估物理防护，以及哪个配置流程建立了身份。Caliptra 为这类审查提供更强起点，但不会替代审查本身。

组件版本把一次发行变成集成契约

软件产品即使包含许多库，也常只展示一个发行版本号。Caliptra 无法安全地这样简化生命周期。RTL、ROM、First Mutable Code 和运行时固件有不同的更新约束，Subsystem 和密码加速器也有自己的版本。产品是这些组件的组合。

独立版本控制让可变代码能够改进，而无需重新制造芯片；它也形成了一个兼容矩阵，使某项安全修复可能只适用于特定 ROM 或 RTL 级别。集成方需要足够精确的物料清单记录，以识别每个产品修订版内部的实际组合。

安全版本号又增加一个维度。运行时镜像可能在功能上兼容，却因防回滚值低于熔丝设定的最低值而遭拒。修补后的镜像可能需要旧芯片不具备的早期阶段；Subsystem 版本也可能依赖在小版本间发生变化的 Core 接口。

这属于把不可逆硬件纳入其中的常规配置管理，但依赖错误的后果更严重，修复也更慢。数据中心运营商可能拥有数千台产品名称相同、内部修订版却各异的设备。

因此，有用的产品证明应报告足够详细的组件身份，使验证方能够应用正确策略。“Caliptra 2”并不够具体，报告可能需要包括 Core RTL、ROM、可变固件安全版本、Subsystem 修订版和供应商集成规范。

这些细节可能让机群策略变得复杂，但仍好过把所有设备视为等价，然后在事故中才发现区别。版本透明度把隐藏的异构性转化为可管理的清单。

项目的兼容性表格和补丁说明属于安全模型的一部分，说明公共团队有理由认为哪些组合能够共同运行。下游供应商仍有责任记录偏差并测试具体产品。

Caliptra Subsystem 以扩大可信基础为代价简化集成

最初的 Caliptra Core 有意保持严格边界。随着实现方考虑完整产品，它们需要围绕信任根配置管理功能、外设接口和恢复服务。Caliptra Subsystem 增加了制造商控制单元和更广泛的集成环境。

这种扩展可以减少重复工程。片上系统供应商能够获得更多必要框架，用于把信任根连接到总线、存储、恢复和主机组件。共同实现可以改善互操作性，并把审查集中到共享代码上。

代价是可信计算基础扩大。更多固件、外设和命令意味着需要验证更多状态。负责恢复或密码服务的控制器可能成为进入秘密和生命周期策略的路径。周边 Subsystem 中的缺陷可能削弱原本稳健的 Core。

产品声明应明确区分 Core 和 Subsystem。一个设计可能把 Core 与专有管理逻辑集成，另一个则可能采用公开 Subsystem，两者的保障证据不能互换。

范围扩大是采用压力的正常表现。用户发现最精简的原语难以一致集成，便要求项目标准化更多内容。治理上的关键问题是应在何处停止。每项共同功能都可能改善可移植性，同时增加项目的维护义务。

Caliptra 的 Subsystem 工作也改变了竞争环境。最小化信任根模块可以补充现有安全控制器；功能更完整的 Subsystem 则开始与专有平台安全处理器重叠。供应商可能欢迎共同 API，同时保护差异化管理功能。

项目需要保持模块化，让集成方能够选择适当边界，而无需分叉整个设计。当可信基础不大于用例所需时，安全性更高；当共同功能不必在每个产品中重新拙劣实现时，生态体系获益。Subsystem 正处于这两个目标之间。

Adams Bridge 把后量子验证带入长寿命硬件

数据中心芯片可能服役多年，固件镜像也可能需要在制造完成很久后继续受信任。因此，密码迁移必须在旧算法真正遭到破解前开始。Caliptra 2.x 增加了 Adams Bridge，这是一款面向 ML-DSA 和 ML-KEM 等后量子机制的开放硬件加速器。

其直接用途并非宣称整台服务器已经具备量子安全性。硬件支持可以加速固件签名验证和密钥建立操作，否则这些操作在信任根内部的小型处理器上成本很高。它为长寿命设备提供了采用 NIST 流程所选算法的路径。

后量子方案具有更大的密钥和签名，也有更高的实现复杂度，会带来新的内存、性能和侧信道问题。这些算法和代码的部署时间短于成熟的椭圆曲线系统，因此围绕加速器的补丁历史是重要证据，不是需要掩盖的尴尬。

混合迁移可以同时使用传统机制和后量子机制，在防范任一算法族的不确定性时，也会增加消息大小、验证工作量和兼容要求。不可变 ROM 必须掌握足够信息来接受所选格式，或安全地把任务委派给可变代码。

迁移范围还会超出芯片。背书证书、证明服务、更新签名系统和验证软件都必须理解新算法。能够验证 ML-DSA 固件的信任根，仍可能通过较旧的外部链呈现身份。

2.1 版增加了更多后量子能力，包括 ML-KEM 和 ML-DSA 的 External-Mu 模式。这些是具体项目功能，并不能证明每个下游产品都会启用。集成方将根据性能、威胁模型和生态体系准备程度选择规范。

Caliptra 的价值在于，多家供应商可以共同审查和实现同一加速器，而不是各自私下重复迁移。风险则是共同缺陷可能广泛传播。正因为代码旨在复用，独立审查、测试向量和明确版本报告才至关重要。

OCP L.O.C.K. 把信任从启动扩展到存储复用

存储设备提出了不同的安全问题。静态数据加密可以通过销毁或更换介质加密密钥，使硬盘内容无法访问。保障水平取决于密钥在哪里生成、存储和擦除。声称已清除介质的主机命令，其可信度不会高于负责执行它的控制器。

OCP L.O.C.K. 的 1.1 版于 2026 年 6 月发布，它扩展 Caliptra，以支持存储介质密钥保护和密码擦除流程。这项工作把信任根模块与存储控制器功能连接起来，同时并未把信任根本身描述为加密引擎。

这一用例对循环利用十分重要。数据中心硬盘可能被重新部署、维修或退役。安全销毁密钥可以提高复用安全性，并减少销毁仍可工作的硬件。可验证控制器能够提供证据，表明密钥路径按照必要状态进行了转换。

边界仍取决于具体产品。存储供应商提供介质加密、控制器固件和物理设计，设备所有者提供清除策略和资产清单。Caliptra 可以隔离并授权密钥操作，却无法保证供应商的加密设计覆盖每份数据副本或重新映射的数据块。

L.O.C.K. 也说明项目如何通过规范进行扩展。并非每种 Caliptra 集成都会成为存储设备。该扩展定义了一组特定交互和具名行业参与方。相关声明应说明下游产品是否实现了对应版本，以及是否在预期擦除和恢复场景下通过测试。

其中还存在治理影响。一旦共同信任根控制的密钥销毁决定着资产能否合法、正常复用，其生命周期就会成为资产管理的一部分。固件缺陷可能延迟整个机群的退役；过于宽松的恢复路径可能削弱擦除保障；错误的不可逆转换则可能销毁仍然需要的数据。

存储扩展使 Caliptra 从启动安全组件走向更广泛的基础设施安全服务。这种增长提高了它的经济相关性，也增加了缺陷的代价。

开放逻辑仍把物理保障留在私有且昂贵的环节

Caliptra 的 RTL 和固件可以接受检查、仿真和综合。审查人员可以研究密钥库访问、生命周期转换、密码命令路径和 DPE 上下文管理。公开记录让不同公司能够讨论同一实现，而不是比较私有模块的营销描述。

最终芯片包含通用 RTL 中不存在的选择。晶圆厂工艺、存储器宏、时钟树、布局规划、封装和供电都会影响抵抗物理攻击的能力。故障注入可以针对电压或时钟行为，侧信道可能通过时间、功耗或电磁辐射泄露信息，侵入式攻击者则可能绕过逻辑控制。

供应商还会添加封装逻辑和熔丝逻辑。安全的公共模块可能与暴露的总线或薄弱调试路径集成；密码加速器可能本身正确，却接收到低质量熵或被攻破的密钥；综合与工具配置也可能改变原有假设。

因此，不应把开放设计宣传为自动保障。它改善了审查机会，并减少共同逻辑周围的保密。产品安全仍需要物理评估、供应链控制和集成测试。

项目可以定义安全属性、测试挂钩和集成指导，发布已知限制并鼓励独立评估。它无法强迫制造商披露每项布局或工厂程序，而公开披露本身也可能给特定产品带来风险。

实际标准应是证据与声明相称。声称芯片采用 Caliptra 的供应商可以说明公共版本和所做修改；声称能够抵抗物理攻击的供应商应为实际实现提供评估；声称机群完整性经过证明的云运营商，则应在适当层面说明背书和验证方模型。

开放硬件把基线从“信任供应商的私有实现”转变为“检查共享设计，并要求为私有剩余部分提供证据”。这是有意义的变化，但并不意味着信任问题已经结束。

证明报告的是执行起点，而不是此后发生的一切

信任根生成度量结果，以便其他系统采取行动。在机群中，验证方可能把证据与获准固件清单、证书链和生命周期状态进行比较，然后准许设备加入、将其隔离，或不向其提供密钥和工作负载。

CPU、GPU 和 DPU 采用共同证据可以降低集成成本。平台运营商能够建立统一策略框架，而不必解读互不相关的供应商格式。组件身份还能提高资产清单和事故响应的精确度。

验证方因此获得很大权力。它决定哪些固件可以接受、信任哪些背书权威。策略错误可能大规模拒绝健康设备；遭到攻破的验证方则可能放行恶意状态，或在原始安全目的之外关联身份。

Caliptra 不运营这项服务。创始云公司有强烈动力建设自己的机群验证和证书基础设施，芯片供应商则建立设备背书。客户可能只能看到结果，而无法了解完整策略。

这种分工保护商业自主权并限制项目控制，但也意味着两个基于 Caliptra 的产品可能生成技术上兼容、却由不同权威在运营上接受的证据。格式共同并不意味着治理共同。

机群运营商需要制定验证服务连续性计划。策略变更应有版本并经过测试，背书根需要轮换和恢复，例外情况应可审计。证据保留应根据隐私和事故要求决定，而不是默认无限期收集。

开放信任根可以提高度量路径的可检查性，但下一个权力集中点会转移到解释证据的服务。安全负责人应以审视芯片时同样的怀疑态度检查这项服务。

Caliptra 可以度量经过认证的固件，并从启动链派生证据。这些证据之所以有价值，是因为早期代码建立身份、内存保护和更新策略，但它存在时间边界。

启动后，获准固件仍可能遇到漏洞、接收恶意输入或作出错误决定。DPU 可以从获准镜像启动，随后执行错误的网络策略；加速器可以证明其固件，却因运行时缺陷或故障而输出错误结果。信任根不会观察每一条指令或每项应用结果。

机群系统需要把启动证据与运行时遥测、漏洞清单和行为控制相结合。度量结果应说明它覆盖的状态和采集时间。发生重要变化后，长期凭据可能需要续期或重新证明。

明确这一边界有助于防止夸大声明。“经过证明”不应成为安全的同义词。它表示特定证据由某个身份签署，并按照验证方策略得到处理。声明质量取决于度量了什么，以及系统随后如何响应。

这种区别也有助于事故响应。有效证明可以把调查范围从启动篡改缩小到运行时或应用原因；无效结果可以触发隔离，却不能证明存在恶意意图。证据在减少不确定性时最有价值，而不是假装能够消除不确定性。

治理和部署仍分散在不同机构

Caliptra 没有传统管理团队。技术权力分散在 OCP 规范流程、Caliptra Workgroup、CHIPS Alliance 治理、维护人员、代码库审查人员和贡献公司之间，下游集成方则控制最终产品。

这种安排让每个机构承担明确用途。OCP 把需求与数据中心运营商和硬件供应商连接起来；CHIPS Alliance 提供中立的法律和项目归属；工作组举行公开会议并开发发行版本；维护人员决定变更是否符合技术标准；公司则提供大部分专业劳动力和部署知识。

中立托管降低了一家供应商关闭项目或私下重定义接口的风险，却不会让资源变得平等。超大规模云公司或芯片企业能够分配工程师、开展昂贵验证，并带来独立贡献者无法掌握的产品约束。非正式影响力会随能力分布。

公共代码库和会议提高了决策可见性，但重现某项选择所需的部分证据仍可能属于私有信息，例如物理测试结果、客户要求或尚未公布的产品计划。社区可以审查实现，却看不到推动它的全部部署事实。

项目于 2025 年在 CHIPS Alliance 获得毕业项目地位，表明流程趋于成熟。补充资金机制和公司贡献支持共同工作，但没有公开统一项目预算。没有公开账目不等于成本低。高保障 RTL、Rust 固件、密码技术、验证和安全响应均需要持续投入专家。

当创始成员的优先事项开始分化时，长期治理将受到考验。供应商可能为某款产品冻结旧分支，云运营商可能要求其他成员不需要的功能，安全问题也可能要求多个保密集成方协调披露。中立项目必须维持共同主线，同时承认各参与方不会按相同时间表出货。

机构设计本身就是 Caliptra 价值的一部分。竞争者共享信任根，需要一个技术合法性不依赖单家公司市场地位的论坛。

Caliptra 已有发行版本、公共代码库、评估、补丁系列和具名集成工作。这些事实表明它是严肃项目，却无法说明有多少生产芯片采用该模块，也无法说明哪些机群依赖其证据。

AMD 曾介绍集成工作，创始公司展示过演示和用例，存储领域参与方也为 L.O.C.K. 作出贡献。项目面向 CPU、GPU、DPU 和相关控制器。截至 2026 年 8 月 5 日，公开资料中仍没有完整产品清单、出货数量或一致性登记册。

这一缺口可能造成两种相反错误。怀疑者可能因产品细节保密而断言没有采用；支持者也可能把创始成员身份和路线图转化为全面部署声明。公开证据都无法支持这两种结论。

产品周期可以解释部分延迟。信任根模块必须在流片前进入芯片设计，经过验证和制造，再集成到电路板、固件和机群系统。从项目公布到出现具名出货产品，可能相隔多年。

公开一致性信息可以改善证据。登记册可以列出产品、Caliptra 修订版、规范、评估范围和相关扩展，而不暴露工厂秘密。测试套件可以确认功能行为，供应商则另行发布物理和配置保障。

项目必须决定要对自身名称拥有多少控制。宽松标签有助于采用，却可能造成歧义；严格认证计划成本高，也可能阻碍修改后的实现。中间方案可以要求披露版本和修改，而不承诺普遍安全。

下一个重要里程碑并不是又一次宽泛承诺，而是一款能够检查其集成、证据路径和运营结果的产品。在此之前，应把 Caliptra 描述为技术成熟、但公开部署可见性仍不完整的开放基础设施。

OpenTitan、TPM 和专有处理器以不同方式划定信任边界

Caliptra 经常与 OpenTitan 一同被提及，因为两者都公开信任根硬件和固件，但它们是不同项目。OpenTitan 开发了范围更广的独立设计，并已在 Chromebooks 中实现有记录的生产出货。Caliptra 则专注于数据中心级片上系统的集成度量信任根，以及多供应商组件证据模型。

两者共享或复用了部分概念与开放硬件工作，但部署其中一个并不能证明另一个也已部署。它们的治理、顶层架构和产品路径均不相同。

独立的 Trusted Platform Module 在单独组件边界提供标准化命令和身份功能。它可以补充采用 Caliptra 的芯片，而非与其直接竞争。TPM 可以证明主机状态，Caliptra 则在主机能够访问处理器或加速器前建立其内部信任。

Microsoft Cerberus 和其他 OCP 安全规范从不同角度处理平台与固件保护。专有安全处理器可以与供应商产品紧密集成，也可能具备成熟的物理加固，但其实现和接口较少开放给共同审查。

选择并非发生在一个通用赢家与过时替代方案之间。一台服务器可以包含多个信任根和证据链。工程挑战是理解哪个组件为哪种状态担保，以及验证方如何组合这些证据。

Caliptra 的结构优势是拥有由采购方和供应方共同支持的公开模块；其劣势则是通用复用无法针对每款产品优化，公开实现也不包含完整保障体系。

因此，比较应聚焦于边界和证据：哪些代码不可变？秘密存储在哪里？谁负责配置背书？哪些度量跨越接口？哪个组织能够更新策略？相较项目名称，这些答案更重要。

加速器和 DPU 无需询问主机 CPU 就能改变数据

聚焦数据中心并非随意的市场选择。加速器和基础设施处理器如今承担了过去必须经过主机的工作。GPU 在有价值的模型和训练数据上运行内核与固件；DPU 可以执行网络策略、终止存储路径并管理隔离。即使主机操作系统已完全修补，遭到攻破的组件仍可能影响机密性或完整性。

共同内部信任根让这些设备能够在运营商交付工作负载前呈现身份和启动证据。机群系统可以区分运行获准固件系列的真实加速器与未知或被修改的设备。这些证据可以支持隔离、密钥发放和维护决定。

证明无法证实加速器正确计算了模型。它报告的是经过度量的代码和设备状态。运行时故障、恶意工作负载以及获准固件中的缺陷仍然可能发生。这一区别在 AI 系统中至关重要，因为干净启动可能被误认为可信输出的证明。

DPU 又形成另一道边界。它通常用于把基础设施服务与租户控制的主机隔离。当接口一侧具有敌意时，信任根必须仍然可信。邮箱权限、更新权威和复位行为都需要维持这种隔离。

由于这些处理器位于高带宽路径上，可用性十分重要。信任根故障可能阻止原本功能正常的加速器加入集群，或阻止 DPU 提供网络服务。运营商需要制定能够处理组件身份变化的冗余和替换流程。

Caliptra 的架构机遇是让不同供应商的证据保持一致；其战略风险则是单一验证方策略成为异构机群的准入门槛。组件信任根减少设备内部的不确定性，同时提高外部控制平面的重要性。

产品未公开时，协调漏洞披露会更加困难

普通开源软件的漏洞可以映射到软件包版本和公共发行版。Caliptra 缺陷却可能已经综合进芯片，而芯片是否存在、采用哪个修订版以及客户是谁都可能保密。公共项目可以发布补丁，却没有完整的受影响产品清单。

这使协调披露成为供应链工作。维护人员需要判断问题位于可变固件、ROM、RTL 还是特定集成。创始公司和下游公司需要时间识别产品与缓解措施。云运营商可能拥有无法公开共享的机群遥测。研究人员也需要一条报告发现的路径，而不必逐一联系所有潜在供应商。

响应方式差异很大。如果产品提供可信路径，运行时固件可以更新；ROM 或 RTL 缺陷可能需要由可变层绕过、采取限制性策略或替换硬件；物理弱点则可能只影响采用特定布局或封装的产品。

因此，公开公告应说明受影响组件和版本假设，而不暗示所有产品均受影响。供应商应在披露条件允许时发布产品映射。客户则需要足够信息来判断公共修复是否已经抵达其设备。

2026 年 3 月的补丁系列说明了这套机制的重要性。持续安全加固证明项目正在接受检查和维护。风险不在于存在修复，而在于下游缺乏可见性。公共代码库更新后很久，芯片仍可能继续出货旧快照。

成熟的 Caliptra 生态体系会把安全来源追踪视为产品功能。物料清单应把物理部件与公共提交记录和安全公告连接起来。缺少这种关联时，开放开发虽能改善共同代码，客户却仍无法确定面前芯片的状态。

只有在更换供应商后证据仍然有效，共同信任根才能改善供应商选择

共享基础设施的一项承诺是降低对专有安全模块的依赖。采购方可以要求多家芯片供应商提供能够输出熟悉度量和身份的信任根，验证系统不必为每种设备从头重建。

仅有功能兼容性不足以支持替代。供应商可能配置不同的背书层级、支持不同的生命周期状态，或提供不同的恢复保证。一种实现可能采用 Caliptra Core，另一种采用 Caliptra Subsystem；物理加固和后量子选项也可能不同。

因此，采购方需要一份规范，说明哪些行为为必选、哪些仍由供应商决定。一致性测试可以验证命令和证据格式，采购条款可以要求披露版本、更新支持和证书连续性，独立评估则可以处理产品特有的物理与集成声明。

这一过程可能表明两个“基于 Caliptra”的部件并不能互换。这是有用的结果。真正的韧性来自在供应商失效前了解替代成本和边界，而不是假设共同标识就能提供保证。

项目可以通过保持接口稳定、记录可选功能并抵制含糊使用其名称来支持这一市场。它无需成为中央认证机构，也能让证据更可比较。

如果 Caliptra 在这一层面成功，其最大经济贡献可能并不显眼。云服务和硬件采购方可以围绕共同信任接口进行谈判，而供应商继续在处理器、性能和保障方面竞争。开放模块不会消除供应商权力，却能让其中最不透明的基础之一更容易测试。

Caliptra 让组件的第一项声明可供检查，而不是自动可信

现代数据中心的安全问题不在于缺少密码原语，而在于需要跨供应商信任太多组件的首段代码和身份。Caliptra 提供共同内部信任根，使这些组件能够从中度量自身并呈现证据。

其架构十分具体：ROM、可变固件、生命周期状态、密钥存储、密码加速器、DPE 和邮箱。其机构同样具体：OCP 规范、CHIPS Alliance 代码库和公开工作组。补丁版本与外部评估表明，该设计一直得到维护，而非停留在发布公告中。

边界也同样明确。制造商负责物理实现和配置，平台运营商负责验证方策略，产品供应商决定出货哪些版本和扩展。客户可能无法完整了解这三个方面。

这种分工不是否定项目的理由，而是开放信任根必须揭示的现实。Caliptra 可以让共享逻辑基础接受检查，并减少私有设计数量，却无法把复杂供应链化为一次信任判断。

当产品证据、一致性和现场结果赶上代码成熟度时，项目才适合获得更广泛的评价。在此之前，它取得的成就范围较窄，却仍意义重大：竞争者同意公开构建设备首次安全声明所依赖的组件。