一、设备证明概述：从“你是谁”到“你真的是你”

大家好，欢迎来到《设备证明机制深度拆解》的第一章。

咱们先聊个场景。你想想看，一个智能门锁收到一条指令：“开门”。它该不该执行？

如果这条指令来自你手机上的官方 App，经过加密、签名，那大概率没问题。但如果这条指令是某个攻击者伪造的呢？或者，更隐蔽一点——指令本身是合法的，但发送指令的设备已经被篡改过，里面跑着恶意代码呢？

嗯，这就是设备证明要解决的核心问题。

1.1 什么是设备证明

设备证明（Device Attestation），说白了就是让一个设备向另一个实体（云端、网关、或者另一个设备）证明“我确实是我，而且我没被篡改过”。

它和我们常说的身份认证有什么区别？

维度	传统身份认证	设备证明
验证对象	你是谁（身份标识）	你是什么状态（完整性 + 身份）
核心凭证	密钥、证书、密码	硬件信任根 + 度量值签名
对抗目标	身份伪造	身份伪造 + 固件篡改 + 运行时篡改
典型协议	TLS 客户端证书	TPM 远程证明、DICE、PSA Attestation

我刚开始做物联网安全时，也以为设备证明就是“证书 + TLS”。后来在一个智能网关项目里踩了坑——设备证书没泄露，但固件被替换成了挖矿程序，云端完全没察觉。那次之后我才真正理解：身份认证只能证明“你是谁”，设备证明才能证明“你没有被篡改”。

1.2 为什么需要设备证明

你可能会问：我做好代码签名、做好安全启动，不就行了吗？

行，但不够。

安全启动保证的是设备启动时的完整性。可设备运行起来之后呢？内存被注入了怎么办？文件系统被挂载了恶意模块怎么办？

设备证明要覆盖的是运行时状态的可信性。它让验证方能够拿到一份“证据”，证明设备当前运行的固件、配置、关键数据都没有被篡改。

我归纳了几个最典型的场景：

• 云端接入控制：只有通过证明的设备才能接入 IoT 平台，防止仿冒设备注入数据。
• 边缘计算节点验证：边缘网关在执行业务逻辑前，先向管理平台证明自己的完整性。
• 金融支付终端：POS 机、ATM 每次交易前向后台证明固件未被篡改。
• 自动驾驶 V2X：车辆之间交换信任凭证，确保对方不是被远程控制的“僵尸车”。

1.3 设备证明的核心目标

我个人习惯把设备证明的目标拆成三个层次：

1. 身份真实性——证明设备确实是声称的那个合法设备，不是仿冒品。
2. 完整性可信性——证明设备的固件、配置、关键数据没有被篡改。
3. 行为可预期性——证明设备运行在预期的安全状态中，没有异常行为。

这三个目标层层递进。第一层是基础，第二层是核心，第三层是理想态。目前大多数商用方案能做到前两层，第三层还在演进中。

1.4 设备证明面临的核心挑战

做设备证明，说起来简单，做起来全是坑。我挑几个最头疼的讲讲。

挑战一：硬件信任根的依赖

设备证明必须有一个不可篡改的信任根。没有硬件信任根（比如 TPM、Secure Element、TEE），证明就变成了“软件自证清白”，攻击者完全可以伪造度量值。我在一个低成本的 MCU 项目里试过纯软件方案，结果被一个简单的内存 dump 就绕过了。

挑战二：证明协议的交互开销

一次完整的远程证明，通常需要挑战-响应、度量值收集、签名、验证等多个步骤。对于资源受限的设备（比如 100MHz 的 Cortex-M0、几十 KB 内存），这个开销可能直接导致业务超时。

挑战三：隐私与匿名性

设备证明往往需要暴露设备的唯一标识和固件版本。这在某些场景下会带来隐私风险——比如车联网中，车辆的固件版本可能暴露车辆的漏洞信息。如何做到“证明完整性但不暴露具体版本”，是个很棘手的问题。

挑战四：证明的时效性

设备在证明通过后，下一秒就被攻击了怎么办？证明结果是有时效窗口的。太短则影响性能，太长则留下攻击窗口。这个平衡很难拿捏。

1.5 设备证明的通用架构

不管具体实现怎么变，设备证明的架构骨架是固定的。我画了一张图，帮你快速建立整体认知。

这张图展示了设备证明的核心流程：

• 第一步：验证方生成一个随机挑战（防止重放攻击），发送给设备。
• 第二步：设备收到挑战后，由硬件信任根引导度量引擎收集当前固件、配置的哈希值。
• 第三步：度量值用信任根的私钥签名，形成“证据”返回给验证方。
• 第四步：验证方用设备的公钥验证签名，再比对度量值是否在白名单或基线中。

1.6 本章小结

设备证明不是银弹，但它确实是物联网安全体系中不可或缺的一环。它解决了“身份认证解决不了的问题”——设备是否处于可信状态。

记住三个关键词：信任根、度量、验证。后面所有章节，都是围绕这三个词展开的。

嗯，第一章就到这里。内容不多，但都是基础。打好这个底，后面讲 DICE、TPM 远程证明、PSA Attestation 的时候，你会轻松很多。