8.2 设备安全与认证
8.2.1 设备身份管理与认证
设备身份认证是设备接入安全的第一道关口。如果身份被伪造或绕过，后续所有加密、授权、审计都将建立在虚假的基础上。物联网设备从几毛钱的传感器到边缘网关，算力、存储、功耗差距悬殊。身份认证方案必须在“足够安全”和“设备装得下”之间做取舍，不存在通用解决方案。
设备唯一标识：身份的原点
每台设备出厂时应被赋予一个全局唯一且难以篡改的身份标识。常见做法包括：
- 硬件绑定：利用芯片唯一序列号（如MCU的UID）、安全元件中烧录的设备ID。
- MAC地址：成本低，但MAC可被软件修改，不能单独作为信任根。
- 物模型标识：在平台侧为设备分配UUID或数字证书的主题。
实践中，设备唯一标识需要与加密凭证（证书或密钥）绑定，仅标识本身不提供认证能力，只解决“你是谁”的声明载体。对于生产环境，建议将标识固化在安全存储区（如一次性可编程寄存器），由Bootloader在初始化阶段读取并锁定修改权限（安全启动机制将在 8.2.2 展开）。
X.509证书与公钥基础设施：强认证的信任链
X.509证书是最成熟的公钥基础设施（PKI）。设备持有私钥与证书，平台持有CA根证书。TLS（Transport Layer Security，传输层安全）握手时，设备出示证书，平台校验证书签名，同时设备也验证平台侧的服务端证书——实现双向认证（mutual TLS, mTLS）。
优势：破译一个设备私钥不影响其他设备（非对称安全）；支持吊销（CRL/OCSP）；可管理大规模部署。
代价：证书链验证涉及非对称运算，对资源受限的MCU可能耗时显著增加；证书存储开销相对较大；需要部署CA与签发流程，运维成本较高。因此X.509更适合网关、边缘服务器或安全要求较高的智能设备。
预共享密钥（PSK）：极致轻量
对于计算和存储极度受限的传感器（例如单片机RAM仅数十KB），完整证书握手不可承受。PSK（Pre-Shared Key，预共享密钥）方案直接使用对称密钥进行会话认证，省去证书交换和非对称运算。TLS-PSK以及数据报传输层安全（DTLS, Datagram Transport Layer Security）-PSK让设备只需存储一个短密钥，握手消息量明显减少。代价是密钥分发困难：对称密钥通常需要在出厂时预置或通过安全通道分发，一旦泄露，所有使用该PSK的设备都需要重新部署。实践中PSK多用于设备数量可控、安全等级中等的私有网络（如楼宇自动化中的传感器）。
TLS/DTLS双向认证的标准路径
无论证书还是PSK，TLS/DTLS为设备到平台的通信提供了标准化安全通道。TLS 1.3优化了握手流程，减少了往返次数，同时移除不安全的密码套件。典型mTLS流程如下：
- ClientHello：设备发送支持的密码套件、随机数。
- ServerHello + 证书：平台回复随机数、密码套件选定、服务端证书。
- 设备验证证书后，发送客户端证书（若配置mTLS）、计算参数与Finished消息。
- 平台验证设备证书，计算并回复Finished。
- 双方生成会话密钥，后续数据使用对称加密传输。
对于UDP链路（如受限应用协议CoAP，Constrained Application Protocol），TLS不可用，需要使用DTLS 1.2/1.3，原理相同，但报文格式适配数据报。轻量级M2M（LwM2M, Lightweight Machine-to-Machine）规范正是基于DTLS 1.2为CoAP定义安全方案。
轻量级认证协议：EDHOC
对于比PSK更灵活的轻量需求，EDHOC（Ephemeral Diffie-Hellman Over COSE，临时Diffie-Hellman over CBOR对象签名与加密）是面向IoT受限设备的轻量认证协议。它基于COSE（CBOR Object Signing and Encryption，CBOR对象签名与加密）格式，通过少量消息交换完成双向认证与会话密钥协商：
- 消息1（设备→平台）：发送临时公钥、支持的密码套件、设备身份标识。
- 消息2（平台→设备）：发送平台临时公钥、证书或公钥凭证、认证签名。
- 消息3（设备→平台）：发送设备认证签名，确认密钥。
EDHOC 是 RFC 9528 定义的轻量级认证密钥交换，可提供双向认证、前向保密和身份保护。它的主要用途之一是为 OSCORE 建立安全上下文，并可通过 CoAP 传输；它不是给“CoAP + DTLS”再叠一层握手。EDHOC 依赖设备侧支持 CBOR/COSE 和所选密码套件，是否适合某款 MCU 应以实现代码体积、握手耗时、能耗和硬件加速实测为准，不能只按内核型号划线。
方案对比与选型建议
表8-4 设备认证方案对比（X.509 证书 / PSK / EDHOC）
| 特点 | X.509证书 + mTLS | PSK（预共享密钥） | EDHOC |
|---|---|---|---|
| 安全强度 | 高（非对称、不可否认、吊销支持） | 中（对称、无前向保密） | 高（非对称、前向保密、身份保护） |
| 设备存储开销 | 较大（证书+私钥，通常数KB） | 很小（仅对称密钥） | 较小（公钥+临时密钥） |
| 握手消息交换 | 1-2次往返（含证书传输） | 1次往返 | 3条消息（约1.5次往返） |
| 握手带宽占用 | 较大 | 很小 | 较小 |
| 密钥分发难度 | 高（需CA、CRL维护） | 高（每设备单独预置或安全通道） | 中等（可离线签发凭证） |
| 适用设备类型 | 网关、边缘服务器、高安全终端 | 极低端传感器、批量同型号设备 | 资源较丰富的受限设备、CoAP场景 |
| 典型标准 | TLS 1.3 | TLS-PSK | EDHOC协议 |
选型时需结合设备算力、带宽预算和安全等级（参见 8.1.1 的威胁分类）。对于大型物联网平台，通常采用混合策略：关键网关使用X.509证书，终端传感器使用EDHOC或PSK，平台侧通过统一身份管理服务（如访问控制列表和租户隔离）将不同认证方案映射到同一授权模型，避免安全短板。
8.2.2 固件安全与安全启动
固件是设备的“操作系统级”软件——硬件初始化、协议栈运行、业务逻辑执行都依赖它。一旦固件被篡改，设备便彻底不可信：传感器可以假装上报正常数据，实际在后台开启网络后门，甚至固件植入的持久后门，格式化存储都无法清除。防护思路并不复杂：让设备只运行经过签名的固件，且签名的私钥不被任何人（包括设备自身）直接读取。这需要在启动那一刻就建立信任链，同时保证每一次固件更新都经过严格验证。
安全启动流程：信任链的起点
安全启动（Secure Boot）不是单一功能，而是一条逐级校验的信任链。典型流程包含以下环节：
- BootROM（固化在芯片内的只读代码）上电后，加载第一阶段 Bootloader（通常称为 SBL 或 PBL）。BootROM 不做校验——因为它是信任的根，本身不可修改。
- 第一阶段 Bootloader 验证第二阶段 Bootloader（如 U-Boot）的数字签名，签名合法才加载，否则停止启动。
- 第二阶段 Bootloader 验证操作系统内核或固件镜像的签名，验证通过才解压并执行。
- 内核在挂载根文件系统前，校验根文件系统的完整性（通常通过 dm-verity 或类似机制实现）。
每一级都验证下一级的签名，构成“信任链”。链条的强度由最根部决定——即固化在芯片内、不可篡改的根密钥（Root of Trust, RoT）。如果根密钥没有被物理读出或替换，整条链就可信。
假设示例：一款工业边缘网关采用 ARM Cortex-A 系列 SoC，其安全启动配置中，BootROM 使用非对称签名（如 ECDSA，椭圆曲线数字签名算法，Elliptic Curve Digital Signature Algorithm）对第二阶段 Bootloader 进行验证，后者再以同样方式加载 Linux 内核与文件系统镜像。公钥本身如何防篡改，将在下文“固件签名与验证”中展开。
固件签名与验证：谁授权了这段代码
安全启动的信任链依赖数字签名机制。开发团队使用私钥对固件镜像签名，设备端用公钥验证签名。关键点在于：
- 私钥必须严格保护，通常存储在硬件安全模块（HSM，Hardware Security Module）或隔离的签名服务中，杜绝任何形式的直接导出。私钥泄露等同整个产品线的沦陷。
- 公钥可以公开，但它的完整性需在设备端得到保证——一旦外部可篡改设备上的公钥，攻击者就能用自己的私钥签发任意固件。
实践中，公钥的指纹（哈希）被写入芯片的 OTP 或 eFuse 区域，且只能写入一次。设备启动时，BootROM 从 OTP 读取该哈希，对照存储的公钥是否正确。任何篡改公钥的行为都会导致设备拒绝启动。
固件签名流程通常包含：编译生成二进制镜像 → 用私钥签名（签名数据附加到镜像末尾） → 打包（含版本号、目标设备标识、时间戳） → 分发到设备。设备端的验证流程为：
Bootloader 读取固件镜像及其签名数据 → 从 OTP 读取公钥/公钥指纹 → 使用公钥验证签名 → 通过则启动，否则停机或进入恢复模式。验证失败时，设备绝不能以任何方式执行未签名的代码。常见的扩展做法是故障安全恢复：如果主固件启动失败，设备回退到受保护的恢复模式，通过安全接口接收签名的修复固件。
信任根（RoT）：整条链的锚
信任根（Root of Trust, RoT）是设备安全模型中不可被攻陷的基点。它通常由两部分组成：不可修改的引导代码（BootROM，固化在硅片上）和不可篡改的密钥存储（烧录在 OTP 或物理不可克隆函数区域内的密钥材料）。
业界多种硬件方案用于实现 RoT。以 ARM Cortex-A 架构为例，可信固件（Trusted Firmware-A）在 EL3 异常级别运行，负责安全启动和运行时安全监控。Intel 的 SGX（Software Guard Extensions）虽主要面向可信执行环境，但其提供的硬件隔离能力也可用于保护信任根和密钥，部分实现中与固件验证结合。在轻量级 MCU 上，许多厂商的 TrustZone-M 方案将关键操作隔离在安全世界中，安全启动和密钥管理是典型用例。
选择 RoT 方案主要取决于成本与保护等级：
- 纯软件方案：在普通 Flash 中存储公钥哈希，依赖启动代码逻辑不被绕过。收益有限——Flash 可被物理篡改或通过调试接口读出。
- 专用 SE/TEE 芯片：具备独立处理器和安全存储，密钥物理不可读。适合关键设备（边缘网关、医疗设备、支付终端）。
- SoC 集成：许多现代 MCU 内部集成安全启动硬件支持，提供一次性编程区域和信任根，成本和防护等级居中。
权衡非常现实：带 SE/TEE 的芯片成本更高，OTA 通道也需要额外的签名与灰度机制。资源极受限的设备往往只做“验签升级 + 软件层密钥保护”，把更强的硬件信任根留给关键节点。
安全更新机制：别让升级变成漏洞
OTA（Over-the-Air）更新给攻击者打开了一扇新门。如果更新机制本身不安全——比如固件被明文传输、签名被跳过、回滚被允许——一次恶意 OTA 更新就能批量沦陷整片设备。
安全更新的工程实践应包括：
- 强制验证签名：设备在写入新固件前必须验证其数字签名，签名不合法绝不允许写入（即使触发用户手动操作也不行）。
- 回滚保护：设备应支持回滚到已知良好版本，但必须防止攻击者利用“降级到有漏洞的旧版本”。回滚保护通常通过安全版本号（SVN，Security Version Number）实现：设备仅允许更新到更高版本，拒绝低于已记录 SVN 的固件；SVN 存储在安全存储区（如 OTP 或 SE 中），只增不减。
- 原子性写入：更新过程中发生断电或通信中断，设备应能恢复到上一个稳定固件，而不是变成“砖头”。常用做法是双副本镜像（A/B 分区）：固件写入备用分区，写入完成后设备从备用分区启动，验证成功后将备用分区标记为活动分区。如果验证失败或启动异常，设备回退到原始分区。
回滚防护的意图很直白：攻击者试图把固件恢复到存在已知漏洞的旧版本时，设备必须能识别并拒绝。除安全版本号外，还有一种互补做法是密钥版本号验证：每次固件更新改用新的密钥对签名，旧密钥随版本退役——攻击者即使拿到旧私钥，也无法为已注销的版本签出有效镜像。
假设示例：某智能锁制造商修复了一个蓝牙协议漏洞，发布新固件并把安全版本号提升到 3。攻击者拿到旧私钥后，试图把设备降级到版本 2：Bootloader 检查到镜像的 SVN（2）低于已记录的 SVN（3），拒绝写入和启动，并将该镜像标记为不可用。
权衡归纳
将上述内容罗列为实践清单：
- 必须做到：固件签名与验证（哪怕只是软件层）、强制验证后写入的 OTA 更新、回滚防护（版本号或密钥版本）。
- 建议做到：支持 A/B 分区（降低变砖风险）、使用硬件信任根（OTP/PUF/SE）。
- 可选/视成本决定：TEE 隔离、物理防拆检测、实时固件完整性监控。
安全启动和生产环境不是一次性投入——它需要配套的密钥管理流程、签名服务、灰度发布机制以及异常检测能力。没有这些配套，再强的信任链也单独支撑不起整条防线。
8.2.3 物理安全与防篡改设计
网络层面的攻击看不见摸不着，但物联网设备常常部署在无人值守的户外、工厂车间甚至竞争对手的厂区。一台安装在管道上的温度传感器，可能被直接拧下来拆解；一台智能电表，可能被撬开外壳读取芯片上的数据。物理安全解决的是“设备落到攻击者手里之后，还能不能守住秘密”的问题。逻辑安全在物理可达面前往往不堪一击——如果攻击者能直接读取 Flash 里的私钥，再强的 TLS 加密也形同虚设。
物理安全的工程目标不是“完全防住所有物理攻击”——成本上做不到——而是提高攻击门槛，让破解成本超过攻击者的收益。防篡改外壳、安全元件（Secure Element, SE）、物理不可克隆函数（Physically Unclonable Function, PUF）和侧信道防护，构成了四道防线，其中前两道是绝大多数设备的标配，后两道取决于安全等级和成本预算。
防篡改外壳：第一道物理屏障
最简单的物理防护是让攻击者难以无损拆解设备。防篡改外壳通常包含以下设计：
- 密闭灌封：用环氧树脂等材料将电路板完全包裹，拆解必须破坏外壳和板卡，难以恢复原状。该方法成本较低，在中低端设备中广泛使用。
- 特殊螺丝 + 易碎贴纸：三角头、梅花带孔等特殊螺丝头需要专用工具；易碎贴纸一旦被揭开就会留下明显痕迹，适合产品保修和现场巡检判断设备是否被开过。
- 触发式自毁电路：在外壳内部布置微动开关或电容式感应电极，当外壳被打开或电路板被拔出时，触发密钥擦除或芯片自毁。该设计在高端门禁读卡器和金融 POS 机上比较常见，成本较高。
防篡改外壳的局限在于：一旦攻击者掌握了专业拆解手段（如热风枪软化灌封胶、化学溶剂溶解环氧树脂），仍然可以缓慢取出电路板。因此，真正的密钥必须存储在更深层的硬件中。
安全元件：密钥的保险柜
安全元件（SE）是一个独立的、防篡改的硬件芯片，专门用于安全存储密钥和执行加密运算。它有自己的处理器、存储器和防攻击电路，通过物理隔离和总线加密保护密钥不被主控芯片读取。典型的安全元件遵循 Common Criteria（CC，通用评估准则） 认证标准，安全等级从 EAL4+（入门级）到 EAL6+（高安全级）不等。高等级芯片在设计上能够防御常见的物理探测手段。
安全元件在物联网中的典型用途包括：
- 存储设备私钥和根证书，用于与平台的双向 TLS/DTLS 认证。主控芯片发起连接请求时，签名运算在安全元件内部完成，私钥从不离开芯片。
- 执行 OTA 固件签名的验证，避免主控芯片单独验签时泄露签名私钥。
- 生成一次性随机数（nonce）用于防重放攻击，因为安全元件通常内置硬件真随机数发生器。
在企业级 IoT 平台架构中，对安全要求高的关键节点（如网关、边缘服务器）推荐集成安全元件，利用其硬件隔离能力实现密钥“可用而不可读”。而在资源极受限的终端（如单颗 MCU 的温度传感器），往往只能退而求其次，在 SoC 内部利用可信执行环境（Trusted Execution Environment, TEE）或软件混淆来保护密钥——这属于成本与安全之间的工程权衡。
物理不可克隆函数：芯片的“指纹”
物理不可克隆函数（PUF）不是“存储”密钥，而是利用制造过程中芯片自身的随机物理差异来生成独一无二、不可克隆的“指纹”。每次上电时，PUF 电路会输出一个稳定的、设备唯一的标识符或密钥。
PUF 的核心优势是：密钥不需要显式存储在非易失性存储器中，攻击者无法通过读 Flash 或探针直接提取。即使同一张晶圆上相邻的两颗芯片，PUF 输出也完全不同。此外，PUF 具备防物理克隆特性——即使攻击者拿到芯片的版图，也无法造出一颗输出相同的克隆芯片。这一特性在反伪冒设备认证和一次性密钥生成中很有价值。
PUF 也有短板。输出可能受温度、电压和芯片老化影响而波动，需要纠错电路和辅助数据来稳定输出。目前大部分商用的 SRAM PUF 和环形振荡器 PUF 方案，其安全等级还不足以抵抗专业侧信道攻击，但低成本（不需要额外安全芯片）使其在智能门锁、消费类 IoT 设备中逐渐普及。
侧信道攻击防护：看不见的“耳朵”
侧信道攻击不直接破坏硬件，而是通过观察设备运行时的“副产物”来推测密钥：比如电源电流变化（功耗分析）、电磁辐射（电磁分析）、运算耗时（时序分析）或缓存命中率（缓存侧信道）。例如，AES 加密过程中不同轮次的操作会消耗不同电流，攻击者采集多条功耗曲线，用统计分析就能反推出密钥。
防护侧信道攻击需要在硬件和固件两个层面协同设计：
- 功耗平衡：使用恒功率电路或加噪技术，让每次运算的功耗曲线趋于一致。
- 随机延时插入：在加密操作中插入随机长度的空循环，打乱时序规律。
- 掩码技术：将敏感数据与随机数混合后再参与运算，使得攻击者从功耗曲线中提取的签名与真实密钥无关。
- 敏感操作隔离：对于关键运算（如私钥签名），优先在安全元件内部完成，不让主控芯片暴露任何侧信道信号。安全元件自身的电路通常已具备抗侧信道能力。
例子：户外燃气表的防篡改设计
假设某设备制造商需要设计一款户外燃气表，防止攻击者通过物理篡改来盗气。设计思路如下：
- 电路板整体灌封环氧树脂，并在外壳接缝处嵌入易碎贴纸。一旦外壳被强行开启，易碎贴纸破裂，留下不可恢复的痕迹。
- 电路板上集成一颗高安全等级的安全元件，内部存储设备私钥。每次与平台建立 TLS 连接时，安全元件完成证书签名——主控芯片仅发起请求，接触不到私钥原文。
- 安全元件内部利用 SRAM PUF 作为密钥派生根：每次上电，PUF 输出一个设备唯一的 128 位标识符，结合安全元件内部的非易失计数器，生成后续密钥材料。如果芯片被拆下尝试移植到其他计量模块，PUF 输出会不同，密钥也随之失效。
- 在安全元件和主控芯片之间的 SPI 通信线路上，串行插入电阻和电容，用于抑制电磁辐射。加密运算期间，主控芯片开启随机延时插入，防止攻击者通过功耗分析获取安全元件与主控之间的通信密钥。
实践边界：物理安全不是银弹
防篡改设计并非越强越好，部署前至少应评估两个实际约束。
成本边界。 一颗高安全等级的安全元件，物料成本可能是一颗普通 MCU 的数倍；加上灌封、特殊螺丝和自毁电路，单台设备的物理安全成本可能显著上升。在千万级出货量的消费类 IoT 产品上，这笔成本足以改变产品定价和利润率。因此，安全等级应与设备价值和攻击风险匹配：一台价值较低的智能灯泡，不值得为其配备高等级安全元件；而一台控制多条生产线的工业网关，为物理防护增加适当预算则是合理的工程决策。
失效模式。 物理防护引入了一个不可忽视的副作用：设备几乎不可维修。一旦外壳灌封、安全元件自毁电路触发，设备基本无法修复。在大量户外部署场景中，这意味着设备更换频率上升、运维成本增加。设计阶段需要明确“可维修”与“防篡改”之间的取舍，并将这一信息明确传达给运维团队。
物理安全是纵深防御的起点，但并非终点——设备在制造、部署、更新直到退役的整个生命周期中都要延续这份安全，这正是下一节要讨论的设备生命周期、SBOM 与安全供应链。
8.2.4 设备生命周期、SBOM 与安全供应链
第 8.2 小节前面已经解决“单台设备如何认证、启动和抗篡改”，但物联网系统的安全责任并不止于设备加电的那一刻。一台设备从工厂制造、上架、部署、更新、异常处置到最终退役，会经历若干年时间；同时，它运行的固件与云端软件都由多层第三方组件构成。生命周期治理和软件供应链一旦缺位，个别设备的漏洞会通过 OTA 或库更新在整个车队中放大。NIST 面向物联网的公开材料强调，制造商在设计、开发、生产、支持与退役各阶段都应承担明确的安全活动（NIST Cybersecurity for IoT Program）。
生命周期六阶段：先分清谁负责什么
表8-5 设备生命周期六阶段职责划分
| 阶段 | 主要活动 | 责任人 | 关键证据 |
|---|---|---|---|
| 制造 | 生成唯一身份、注入根密钥、烧写签名启动链、生产测试 | 硬件厂商与安全工程 | 出厂身份清单、根密钥托管记录 |
| 上架 | 首次注册、绑定租户、下发初始配置与最小权限 | 平台运营与集成商 | 注册审计、配置版本 |
| 运行 | 遥测、命令、密钥轮换、状态监测 | 运维与安全运营 | 心跳、审计、异常事件 |
| 更新 | 固件/驱动/模型/规则的签名发布与灰度 | 发布负责人 | 发布 manifest、版本回退目标 |
| 可疑事件 | 密钥泄漏、异常心跳、召回、事故响应 | 安全事件负责人 | 事件工单、隔离与撤销记录 |
| 退役 | 密钥失效、证书撤销、数据擦除、备件回收 | 平台运营与合规 | 退役审计、数据处置证据 |
各阶段之间必须能相互查证：出厂身份可以追到设备当前状态，运行时事件可以追到最近一次更新和审批人，退役操作可以查到密钥撤销与数据处置。跨阶段没有闭环时，密钥可能长期悬空、退役设备可能被重新激活、召回响应可能只覆盖部分批次。
SBOM：让固件里的“组件成分”变得可读
生命周期治理只解决“谁负责”，但供应链攻击往往来自设备固件与云端服务的第三方组件。软件物料清单（SBOM）用机器可读的方式记录一份软件里包含哪些组件、版本和供应商，让漏洞情报（如 CVE）可以在毫秒级映射到具体设备批次。SBOM 已经成为多国政策明确要求的最小共识，具体做法可以参照 NIST 的软件供应链安全指南（NIST Software Supply Chain Security）。
工程实践中建议：
- SBOM 由构建流水线自动生成（SPDX 或 CycloneDX 皆可），而不是发布后再手工补齐；
- SBOM 应覆盖固件、驱动、边缘代理和云端服务，包括嵌入式操作系统、库、字体、模型权重；
- SBOM 存储与发布制品同版本绑定；一个版本一份 SBOM，随设备清单可追溯到批次；
- SBOM 单独存在无法解决漏洞，需配合漏洞情报订阅、VEX（Vulnerability Exploitability eXchange）与响应流程；
- 高风险组件（如 TLS 库、启动加载器、AI 推理运行时）应列为敏感依赖，纳入强制审批与降级演练。
安全更新：签名、防回滚与失败恢复
设备生命周期中最容易被利用的窗口是更新链路。伪造更新包、把设备回滚到含漏洞版本、更新失败后卡在半执行态，是常见风险。工程上应覆盖：
- 签名与信任链：更新包由发布服务器用生产密钥签名，设备验证签名并绑定信任锚；密钥泄漏必须能通过 CA/信任锚更新撤销。
- 版本防回滚：设备记录已成功启动过的最低版本，拒绝低于该版本的降级；紧急降级需带独立签名和明确的策略。
- 灰度与批次：发布按设备批次、地区、租户分批，观察运行指标和心跳错误码；异常时暂停或回退，而不是继续扩量。
- 失败恢复：更新失败应能自动回到上一个已知安全版本，并向平台上报错误码；设备不允许长期停留在“半更新态”。
- 模型与规则视作制品：AI 模型、规则包、Tool schema 均按“制品 + 签名 + 版本 + 灰度”对待，与固件一致。
密钥、证书与身份的生命周期
设备身份不应“一次注入用一辈子”。密钥轮换、证书更新和撤销需要与设备生命周期联动：
- 每台设备至少有一枚不可导出的设备身份密钥，另有若干短期凭据；
- 密钥/证书轮换在设备正常运行期间完成，避免依赖设备重装；
- 密钥泄漏应能在生命周期系统中触发撤销，全车队心跳会话失效；
- 退役设备的密钥立即失效，防止“旧设备复活”；
- 所有身份状态变更进入审计，可反查到人、动作和证据。
把本节放回本章的脉络里：8.1.4 从治理层回答了“为什么要做”，本节把答案落到设备层的运行、更新与退役；8.2.1 至 8.2.3 给出的认证、启动链与物理防护机制，也因此多了一个时间维度——它们不是部署时的一次性配置，而是随生命周期持续运维的对象。这些持续产生的身份与更新证据，是 8.5.4 的 Agent 安全决策和 8.6 的事件响应的直接输入；设备身份与 OTA 通道所复用的物模型和运行时，分别在第 3、6 章展开，本节不再重复。
生命周期治理是一项持续工作，不是发布前的一份文档。任何允许接入 AIoT 平台的设备，都应能回答：出厂身份是谁签的、当前运行的是哪一版固件与模型、上一次密钥轮换发生在何时、退役后数据将如何处置。