1、远程证明概述

什么是远程证明

远程证明，说白了就是让一台设备向远程服务器证明「我是我，我没被篡改」。

我习惯用一个比喻来解释：你去银行办业务，柜员要看你的身份证。身份证上有照片、有发证机关、有防伪水印。柜员核对照片是你本人，再确认证件没被伪造，这才相信你的身份。

远程证明干的事，本质上一样。只不过——

• 「身份证」变成了设备的硬件指纹或度量值
• 「发证机关」变成了芯片内部的信任根
• 「柜员」变成了远程的验证服务器

设备把自己的运行状态、固件版本、关键配置打包成一个证明报告，用硬件私钥签名，发给验证方。验证方检查签名是否有效、报告内容是否合规，从而判断设备是否可信。

为什么需要远程证明

你想想看，物联网设备部署在无人值守的现场——路灯、电表、工业传感器、医疗终端。攻击者物理接触设备太容易了。换个固件、注入恶意代码、篡改配置，这些事在物理层几乎防不住。

我在项目中遇到过一件事：某客户部署了上千台边缘网关，用来采集工厂设备数据。结果发现部分网关上报的数据异常，排查了三个月，最后定位到——有人在现场用 JTAG 接口刷了第三方固件，把数据采集逻辑改了。

如果没有远程证明，你根本不知道设备已经被「调包」了。

远程证明解决三个核心问题：

1. 身份真实性——设备是不是声称的那个设备？有没有被克隆？
2. 完整性——设备的固件、配置、运行时状态有没有被篡改？
3. 可信连续性——设备从启动到当前时刻，每一步是否都经过了验证？

远程证明的信任根与信任链

信任根（Root of Trust）是整个证明体系的基石。它必须满足一个条件：不可篡改。

放在哪里最安全？芯片内部。具体来说，是 SoC 里的一块独立硬件区域——通常叫安全飞地（Secure Enclave）或可信执行环境（TEE）。

信任根里存什么？

• 设备唯一私钥（永远不离开芯片）
• 公钥证书（由设备制造商签发）
• 度量引擎（计算固件哈希的硬件模块）

从信任根出发，逐级验证，就形成了信任链。我画了一张图，帮你理解这个链条是怎么串起来的：

这张图展示了典型的信任链结构。从硬件信任根开始，逐级度量 Boot ROM、Bootloader、操作系统内核、应用层。每一级在加载下一级之前，先计算它的哈希值，扩展到平台配置寄存器（PCR），然后才跳转执行。

最终，验证方拿到的是：

• 完整的度量日志（记录了每一级的哈希值）
• 硬件签名的 PCR 摘要
• 设备证书链

验证方重新计算一遍度量日志，比对 PCR 值，再验证签名——全部通过，才认定设备可信。

信任根的类型对比

不同场景下，信任根的选择不一样。我整理了一个对比表：

信任根类型	实现方式	安全等级	成本	典型场景
硬件 TPM	独立安全芯片	高	中	PC、服务器、工业设备
TEE（如 ARM TrustZone）	SoC 内部安全区	高	低（集成在 SoC）	手机、IoT 网关、边缘设备
软件信任根	Boot ROM 固化代码	中	极低	低成本 MCU、传感器
虚拟 TPM（vTPM）	虚拟机/容器内模拟	低	低	云环境、虚拟化场景

信任链的两种模式

实际工程中，信任链有两种主流模式：

静态信任链（Static Root of Trust for Measurement, SRTM）

• 只在设备启动时度量一次
• 度量值固定，可预测
• 适合固件不频繁更新的设备
• 缺点：运行时被篡改无法感知

动态信任链（Dynamic Root of Trust for Measurement, DRTM）

• 可以在运行时随时发起度量
• 度量值随运行状态变化
• 适合需要持续证明的场景
• 缺点：实现复杂，需要硬件支持

我个人的建议是：能用 DRTM 就别用 SRTM。虽然实现成本高一些，但安全性提升是质的飞跃。我在一个金融支付终端项目里，就是因为用了 DRTM，才在运行时检测到了内存注入攻击——如果只用 SRTM，那批终端可能早就被攻破了。