凌晨三点，谁给你的机器人打补丁

Brain 的规格表里有一行，全文只有几个字：固件签名密钥，由客户持有。Brain Kit 页面说得长一些——签名，单机密钥，签名密钥由客户持有——旁边一行写着机身无法访问厂商云。这些行每一行都是研发中产品的设计目标，不是在机器上量出来的数值，两个页面都如此说明。我们在有客户提问之前就把它们发布了。然后我们去找那份要求这么做的采购文件，没有找到。

一个没有边界的否定不值钱，所以先把边界画出来。六份文书通读全文，第七份只隔着一层读到，再加三份已发布的采购文件和欧盟的招标语料库，2026 年 9 月 11 日用下文列出的检索词与计数搜过一遍：我们够得着的东西里，没有一份要求供应商把固件签名密钥交给客户。第七份是 MDS2，它在付费墙后面：我们改读了一家制造商填好的表格，下图把它放在我们没读到的文件那一栏，而不是六份之中。我们搜不了的语料库：新加坡的 GeBIZ、美国联邦采购授予系统，以及 ISO 与 IEC 两个标准族。

买方的问题不是这一行好不好看。而是：如果密钥在我手里，凌晨三点这台机器正出着问题，谁来给它打补丁？

这个问题背后的缺陷类别是公开的，它的三个特征就在美国国家漏洞数据库（NVD）里，2026 年 9 月 12 日在那里读到。固件完整性由校验和而不是签名来判定：CVE-2025-45467，一条更新路径 "implements an insecure verification mechanism that solely relies on MD5 checksums for firmware integrity validation"，即实现了一种不安全的校验机制，仅依赖 MD5 校验和来验证固件完整性。解密材料在整条产品线上共用：CVE-2024-52331，固件更新用一把 "deterministic symmetric key"（确定性对称密钥），有了它，"an attacker can create and encrypt malicious firmware that will be successfully decrypted and installed by the robot"，即攻击者可以制作并加密恶意固件，而机器人会成功解密并安装它。更新与控制路径终止于厂商：CVE-2025-2894，一个未记载的后门，"can enable the manufacturer, and anyone in possession of the correct API key, complete remote control"，即能让制造商以及任何持有正确 API 密钥的人取得完整的远程控制，途径是厂商自己的远程访问服务。

这里没有任何一句说的是这些记录今天的补丁状态。在每一条记录里，决定一份固件镜像是否为真的东西在厂商手里，镜像到达机器所走的路径也在厂商手里。姊妹篇逐条读了那份记录；本文不从它那里带来任何计数。

先说让步，因为本文最诱人的那个版本是假的。确实有一个监管者问了谁持有哪把密钥。FDA 的上市前网络安全指南，2026 年 2 月 3 日发布，按它自己的说法不具约束力——每一页页眉都印着 "Contains Nonbinding Recommendations"，即所载为不具约束力的建议——要求制造商记录每一项凭据由谁保管，制造商控制的资产与医疗机构控制的资产一视同仁。它问了。它没有规定答案。

本文的论点不是没有人想过这件事。现行文书里没有一份要求签名密钥由客户持有，原因也不是疏忽：NIST 在 2018 年写下了那道分割，而把密钥握在手里就是把它压垮。下面是一家工程公司对已发布文件的阅读，不是法律意见。我们没有在机器上量过任何东西，这里也没有任何东西跑在客户现场。

这些文书要求什么

英国的产品安全条例 SI 2023/1007，通常被当作联网产品的底线。它的附件 1（Schedule 1），2026 年 9 月 11 日读取，载有三项安全要求：密码、一个报告漏洞的地方、以及公布既定的支持期限。第 1(2) 段要求密码 "unique per product"（每件产品唯一）或 "defined by the user of the product"（由产品的用户定义）。然后是第 1(4) 段，全文引出，因为排除项才是重点：

"In this paragraph, passwords do not include— (a) cryptographic keys; (b) personal identification numbers used for pairing in communication protocols which do not form part of the internet protocol suite; or (c) application programming interface keys."

即：在本段中，密码不包括——(a) 加密密钥；(b) 在不属于互联网协议族的通信协议中用于配对的个人识别码；或 (c) 应用程序接口密钥。

这部法律定义了加密密钥——"data used to encrypt and decrypt data"，即用于加密和解密数据的数据——然后说密码规则不适用于它。以 signing、signature、integrity 与 authentic 通搜附件 1 全文，除第 1 段自身的定义之外一无所获。它根本够不到更新机制。我们没有搜 PSTI Act 2022、法定指南或任何一份执法决定。

国际基线比沉默更锋利。ETSI EN 303 645 V2.1.1 的条款 5.3-10 要求，"where updates are delivered over a network interface, the device shall verify the authenticity and integrity of each update via a trust relationship"，即凡更新经网络接口交付，设备应通过一种信任关系验证每一次更新的真实性与完整性。条款 5.4-4 要求用于这些校验的任何关键安全参数须逐台唯一——而它给的示例点了持有者的名字：

"EXAMPLE 6: The device uses the manufacturer's public key to verify a software update. This is not a critical security parameter and does not need to be unique per device."

即：示例 6：设备使用制造商的公钥验证软件更新。这不是关键安全参数，无需逐台唯一。

所以信任锚并没有被留白。标准假定制造商持有它，并把这个假定写进了对自身规则的一条豁免里。以 trust anchor、signing key 与 key management 通搜全文，没有一条条款把锚交给客户。我们没有取 ETSI TS 103 701，即符合性测试规范，测试用例会在那里。

有一份文书放下了一项真实的打补丁义务，它是美国的，也是医疗的。FD&C 第 524B 条要求申请人（sponsor）"make available postmarket updates and patches"，即提供上市后的更新与补丁，针对已知漏洞按固定周期进行，并且 "as soon as possible out of cycle, critical vulnerabilities that could cause uncontrolled risks"，即对可能造成不受控风险的严重漏洞尽快在周期外处理，还要提交软件物料清单。国会把凌晨三点的义务放在了器械的申请人身上，实践中也就是它的制造者。注意动词：是提供，不是安装，不是部署。全文检索：signing 0，cryptograph 0，key 0。这也是一位医院 CISO 早已内化的词汇，针对的却是我们不在其中的一类机器：清洁或配送机器人不是医疗器械，而 FCC 自己的机器人定义把依 FD&C 第 513 条归类为器械的物品排除在外 [背景——自此前一轮沿用，本轮未重新取回]。

新加坡的 CLS(MD)，即医疗器械网络安全标签计划，2024 年 10 月 16 日启动，属自愿性质；它的四个等级从基线要求一路到独立第三方的二进制分析、渗透测试与安全评估。已发布的等级描述与适用范围里，没有一处问签名密钥由谁持有。我们只能说到这里。技术要求规范不在我们读到的那个页面上，我们也没有找到它。

然后是医院自己的问题清单。MDS2 是买方发给器械厂商的披露声明，约 240 个问题，分 23 个安全能力类别 [二手——ANSI/NEMA HN 1-2019 本身在付费墙后面，未读]。Stein、Pilgermann 与 Sedlmayr 解析了 209 份填好的声明和 161 份白皮书，开篇便指出 MDS2 文件 "are rarely integrated into cybersecurity workflows"，即很少被整合进网络安全工作流；他们分析的器械上出现了 367 个不同的端口，其中约 40% 的器械用到 20 个以上。

既然标准在付费墙后面，我们改读了一份填好的 MDS2，由一家器械制造商发布，表面注明基于 ANSI/NEMA HN 1-2019，读取日期 2026 年 9 月 12 日。二十页，二十三个编号章节，signing key、code signing、private key、key management、key custody、escrow 与 root of trust 加起来出现零次。

它的升级一节，逐个组件类别地问：所有者或运营者能否安装补丁；器械是否 "require[s] vendor or vendor-authorized service"（需要厂商或厂商授权的服务）才能安装；制造商是否允许第三方安全更新 "without approval from the manufacturer"（未经制造商批准）就安装。两个完整性问题问器械是否有一种机制——"release-specific hash key, checksums, digital signature"，即版本专属的哈希密钥、校验和、数字签名——来确认已安装的软件与更新是经制造商授权的；第三个问所有者或运营者到底能不能做完整性检查。这份表格一遍又一遍地问谁可以安装一次更新，从不问谁可以为一次更新签名。一份填好的表格不是标准本身；如果有一个我们没看到的问题问到签名密钥由谁保管，我们仍然不会知道。这个洞比原来窄了。

于是到了转折。同一份不具约束力的 FDA 指南要求上市前提交材料包含

"A precise, detailed list of how each type of credential (e.g., password, key) is generated, stored, configured, transferred, and maintained, including both manufacturer- and healthcare facility-controlled assets (e.g., key management and public key infrastructure (PKI));"

即：一份精确、详细的清单，说明每一类凭据（如密码、密钥）如何生成、存储、配置、传输与维护，包括制造商控制的与医疗机构控制的资产（如密钥管理与公钥基础设施（PKI））。

它还要求给出端到端更新路径的全貌，并提醒这条路径 "will likely include traversing technology that the device manufacturer does not control"，即很可能要穿过器械制造商不控制的技术。六十四页全文检索：signing key 0，code signing 0，root of trust 0，secure boot 0，key custody 0。这整套文书管的是密码，并且在一个行业里明文问了由谁保管。其中没有一份给出答案。

固件签名密钥由谁持有

文书

• UK PSTI，SI 2023/1007，附件 1三项要求：密码、一个报告地址、一个公布的支持期限。第 1(4)(a) 段把加密密钥排除在“密码”之外。
• ETSI EN 303 645 V2.1.1更新须验证真实性与完整性（5.3-10）。示例 6 把制造商的公钥点名为豁免项（5.4-4）。
• 第 524B 条，21 U.S.C. §360n-2提供上市后更新与补丁，周期内与周期外都要；提交 SBOM。signing 0，cryptograph 0，key 0。
• 10 U.S.C. §4401可分离的主要系统部件，可增量添加、移除或替换。signing 0，cryptograph 0，key 0，firmware 0。
• 新加坡 CLS(MD)，自 2024 年 10 月 16 日起自愿性质；四个等级，最高到第三方二进制分析、渗透测试与安全评估。关于密钥由谁保管，没有任何已发布内容。
• FDA 上市前指南，2026 年 2 月 3 日问每一项凭据如何生成、存储与维护，制造商持有的与机构持有的一视同仁——并且不规定答案。signing key 0，code signing 0，root of trust 0，secure boot 0，key custody 0。

采购

• HSCC 示范合同语言第 2 版，53 页signing key、code signing、key management、key custody、escrow、private key、root of trust、secure boot：0。cryptographic key 一次，在 Data 的定义里。
• ENISA 医院采购指南，51 页cryptographic key、key management、escrow、signing key：0。patch 及其词形变化 23，firmware 2。
• 一家铁路运营商的供应商要求，32 页signing key 0；cryptographic key 8，全部是算法、密钥周期或术语表；escrow 1。
• TED，欧盟招标语料库客户持有签名密钥的九种表述：0。同一端点上的对照：firmware 2,927，penetration testing 333，secure boot 74，software bill of materials 26，code signing 24。

未读

• MDS2——约 240 个问题，23 个类别标准在付费墙后面，未读，因此这里不从它推出任何否定。正文改用一家制造商填好的表格，基于 ANSI/NEMA HN 1-2019，读取于 2026 年 9 月 12 日。
• 新加坡的 GeBIZ没有全文检索界面，文件放在登录之后——我们自己的市场，未搜。
• SAM.gov，美国联邦采购授予系统未搜。
• ISO 与 IEC 标准族我们的工具够不到它们；这里没有从其中任何一份引用、描述或归属任何内容。

这条边界之内没有任何东西要求一个答案。有一份文书问了这个问题。

• 2026 年 9 月 11 日通读全文——框内写的是它够得着什么
• 读不到，因此不从中推出否定

修改权在哪里写进了法律，锚又落在哪里

有一部法律给了买方修改所购之物的权利。10 U.S.C. §4401 要求主要国防采办项目采用一种架构，允许 "severable major system components and modular systems… to be incrementally added, removed, or replaced"，即可分离的主要系统部件与模块化系统能够被增量地添加、移除或替换，并遵守法定的技术数据权利。全文检索：signing 0，cryptograph 0，key 0，firmware 0。这项权利是架构上的、合同上的：一个美国作战平台必须能由其所有者替换部件，而没有一句说所有者可以给任何东西签名。

锚的位置是 NIST 在 2018 年 5 月的 SP 800-193 第 3.5 节里定下的：

"Authorization, however, is the permission to perform an update. While authentication is typically rooted in the device or system manufacturer, authorization to perform updates is typically rooted in the device or system owner."

即：而授权，是执行一次更新的许可。认证通常根植于设备或系统的制造商，执行更新的授权则通常根植于设备或系统的所有者。

我们在全部 45 页里搜了 "owner" 这个词。它出现一次，就是这一处。这份定义平台固件如何保持可信的文件，给机器的所有者留了一句话，而这句话把许可的那一半交给了所有者。第 4.2.1.1 节接着说：每一份更新镜像 "shall be signed by an authorized entity – usually the device manufacturer, the platform manufacturer or a trusted third party"，即应由一个获授权的实体签名——通常是设备制造商、平台制造商或可信第三方。三个实体，客户不在其中。所以问题不是为什么没有人遵守一项客户持有密钥的要求。问题是这些基线是写给谁的，而 NIST 八年前就回答了。

否定的其余部分，全部于 2026 年 9 月 11 日读取。HSCC 的《Model Contract-Language for MedTech Cybersecurity》第 2 版，2025 年 11 月——美国医疗行业自己的示范采购合同，53 页——signing key、code signing、key management、key custody、escrow、private key、root of trust 与 secure boot 全部为零；cryptographic key 出现一次，在 "Data" 的定义里，作为一种需要保护的东西。它跑着一整套打补丁的制度，其中谁来签名从未被提起。

ENISA 的《Procurement Guidelines for Cybersecurity in Hospitals》，2020 年 2 月，cryptographic key、key management、escrow 与 signing key 均为零；patch 及其词形变化出现 23 次，firmware 两次，都在同一个条目里，该条目把固件更新程序的缺失称为 "a top threat for healthcare organisations and namely hospitals"，即医疗机构、尤其是医院面临的一项头号威胁。一家铁路运营商 2019 年 3 月 8 日的供应商网络安全要求，signing key 为零，其八处 cryptographic key 是算法、密钥周期，以及定义这两个术语的术语表条目。

欧盟的招标语料库，同一天走了 TED 的全文检索运算符。九种表述——"firmware signing key"、"customer-held signing key"、"signing keys held by"、"customer shall hold the signing" 等——返回零。单独的 "signing key" 返回一条，是 2017 年的一项机场建设授予，其公告文本里并不出现这个短语，所以这个运算符在做模糊匹配，这让那些零更保守，而不是更宽松。同一端点上的阳性对照：firmware 2,927，penetration testing 333，secure boot 74，software bill of materials 26，code signing 24。一台未经检验的搜索引擎给出的否定一文不值；这些对照就是这一个不是的原因。

现在把洞当洞说。我们读不到 MDS2 标准本身，只读到上面那份填好的表格，也没有找到 CLS(MD) 的要求规范。GeBIZ 没有全文检索界面，文件放在登录之后，所以新加坡——我们自己的市场——没有搜过。我们没有搜 SAM.gov。UK Contracts Finder 对我们试的每一个词都返回结果，所以我们无法确定它的匹配语义，不从它推出任何否定；我们没有拿到 NHS DTAC 评估表，也不从那里推出任何否定。ISO 与 IEC 标准族，我们的工具完全够不到，这里没有从其中任何一份引用、描述或归属任何内容。

账单

我们在开源机器人领域找到的、客户控制程度最高的安全启动方案，是 ArduPilot 的。我们没有做过领域普查：它是我们在 2026 年 9 月 11 日找到的东西，是一条搜索结果，不是一个排名。它的 README 在说明能力的同一口气里说出了代价。一个引导程序可携带最多十把公钥；固件用一把私钥签名；与其中任何一把都不匹配的固件不会启动。然后是这一段：

"Note that this will include the 3 ArduPilot signing keys by default as well as your key. This allows the core dev team to help users who make mistakes during the secure boot setup process and prevents issues with vendors who can no longer provide firmware updates to users. If you have a very good reason for not including the ArduPilot signing keys then you can pass the option --omit-ardupilot-keys to the build_bootloaders.py script mentioned above."

即：请注意，这将默认包含 3 把 ArduPilot 签名密钥以及您自己的密钥。这让核心开发团队能够帮助在安全启动设置过程中出错的用户，并避免厂商无法再向用户提供固件更新时出现的问题。如果您有非常充分的理由不包含 ArduPilot 签名密钥，可以向上文提到的 build_bootloaders.py 脚本传入 --omit-ardupilot-keys 选项。

两条写明的理由，两条都是账单：恢复路径，和被弃置时的路径。同一份 README 给出了弄错的后果——"with a secure bootloader and an unsigned firmware the board will stay in the bootloader forever as it will be failing the secure boot checks"，即带着安全引导程序和一份未签名的固件，板子会永远停在引导程序里，因为它过不了安全启动检查。那是 ArduPilot 对 ArduPilot 自己方案的公开描述，作为他们的话引在这里。

下面是我们的推理，不是任何人的测量。这个区别要紧，因为我们去找过测量。没有已发表的、客户保管密钥条件下的平均补丁时间。没有一起因密钥持有人联系不上而延误的事故案例研究。两样我们都不会编。

约束有四条。一次非工作时间的修复，需要客户的签名人联系得上并且获得授权 [推断]；最接近的已发布依据是第 524B 条的周期外义务，而它落在制造商身上，签名能力却不在。供应商的响应能力受限于客户的值班表，而不是供应商自己的 [推断]。丢了密钥就是丢了整个机群，除非有恢复路径——ArduPilot 卡住的引导程序，以及 NIST 第 3.5.1 节的 "proper use of signatures thus necessitates provisions to recover from a key compromise"，即签名的正确使用因此需要从密钥泄露中恢复的准备。任何恢复路径都是第二个信任锚，这是 NIST 的观点，不是我们的：它给的例子从密钥层级到在更新镜像的同时更新密钥库。

两个毫不相干的行业回答了第四条约束，两个都说了托管。那家铁路运营商要求供应商 "provide a contingency plan for the security of the procured solution in the event the Supplier leaves the business (e.g., security-related procedures and products placed in escrow)"，即为供应商退出经营时所采购方案的安全提供应急计划（例如把安全相关程序与产品置于托管）。FDA 那份不具约束力的指南建议制造商 "establish and maintain custodial control of device source code… through different methods, such as source code escrow or source code backups"，即通过源代码托管或源代码备份等不同方法建立并维持对器械源代码的保管控制，其脚注把托管定义为存放在 "an independent third party ('escrow agent')"，即一个独立第三方（托管代理）处。两者都在买方与代码之间放了一个第三方。托管是另一个名字下的第二个信任锚，ArduPilot 默认的三把密钥也是。

镜像的另一面有个日期。微软的 Windows 安全启动证书页面，最后更新于 2026 年 5 月 18 日，给出了到期日：Microsoft Corporation KEK CA 2011 在 2026 年 6 月 24 日，Microsoft UEFI CA 2011 在 2026 年 6 月 27 日，Microsoft Windows Production PCA 2011 在 2026 年 10 月 19 日，此后尚未换上 2023 年替代证书的设备 "will no longer be able to receive new security protections for the early boot process"，即将不再能获得针对早期启动过程的新安全防护。一把由一方为全球规模的机器持有的密钥，在一个公布的日期到期。两种保管模式都有各自的凌晨三点。问题是谁的电话会响。

时钟已经在走。《网络韧性法案》第 14 条的义务，包括在纠正或缓解措施可用后不晚于 14 天提交最终报告，自 2026 年 9 月 11 日起已经适用，并且够得着已经售出的机器——另一篇文章论证了这一点。不对称只有一行。报告义务按供应商的时钟走；让一个修复到达机群的能力，按密钥持有人的时钟走。

上表每一格，要么是已发布文件的引文，要么是对这种安排的推断，并标记为推断。没有一格是测量，也没有测量可引。两栏是一般情形，描述的不是我们运营的任何东西：Tidewell 今天不持有任何客户的密钥，首套 Brain Kit 在设计中，我们规格表上那行客户持有的签名密钥，是研发中产品的设计目标，不是运营实践。

来源，全部于 2026 年 9 月 11 日读取：NIST SP 800-193，2018 年 5 月，第 3.5、3.5.1 与 4.2.1.1 节；21 U.S.C. §360n-2；ArduPilot 安全启动 README；微软 Windows 安全启动证书页面，2026 年 5 月 18 日更新；Regulation (EU) 2024/2847 第 14(2) 条，第 71(2) 条定下适用日期。

我们欠客户什么，而且还没有写

我们读了能找到的三家做去厂商化的服务商，全部在 2026 年 9 月 11 日。新加坡的 Movel AI 为 "multi-brand robots with outdated software"（软件过时的多品牌机器人）出售改装；它自己的案例研究结尾，是一支被救回的机群 "linked… up with our cloud-based FMS"，即接入了他们基于云的机群管理系统，而其服务包含远程支持。Movel 用自己的云换掉了一家厂商的云。Alias Robotics 出售一个 "Robot Endpoint Protection Platform"（机器人端点防护平台），防护的是机器人已经在跑的那套软件栈——telemetry、signing、cryptograph、key、isolation、firmware、cloud、vendor 与 replace 在那个页面上出现零次。Palladyne AI 描述的是平台无关的软件，对固件、密钥、配网或遥测不作任何声明 [单一来源——该厂商自己的页面，因主机拦截直接抓取而经摘要工具读取]。

我们没有找到一家同时出售遥测移除、配网替换与客户持有的更新路径这三样的服务商，而各卖其中一样的三家，每一家都白纸黑字地写着自己不做另外两样。

我们自己的页面说的就是它们说的，限度印在承诺旁边。Brain Kit 页面原文：

"改装机身的安全论证是独立监督控制器加网络隔离。它不是经认证的机身。我们不控制厂商的底层固件，数据表上如实说明。"

那张规格表里的每一行都是设计目标；套件质量、功耗与安装工时尚未依据工程记录定出预算，页面上如此说明。

剩下的，是我们还没写的那部分。客户持有的签名密钥，在我们这边是一个设计立场，不是运营实践：首套套件在设计中，没有任何东西跑在客户现场，而承诺另一边的那套安排——谁来签名、非工作时间怎么找到这个人、找不到时客户怎么办——不存在。我们没有写它，它也不是一份我们扣着不发的文件。读到这里的买方会注意到，也应该注意到。

任何答案要取的形状，我们是知道的。NIST 的分割是这个世界默认运行的方式，托管是这个世界对被弃置这件事已发布的答案，而两条恢复路径都把信任交给了第三方。我们写出的任何安排，都是在这三者——NIST 画下的那道分割、托管、或默认的上游密钥——之中的一个选择，而今天诚实的说法是：我们还没有选。

问题就按买方问的那样立在那里，它是该向我们、也该向任何出售一台会自我更新的机器的人提出的正确问题。如果密钥在我手里，凌晨三点谁来给这台机器打补丁？