3、设备身份与信任根：设备唯一标识、信任锚点、预置密钥

好，我们进入第三章。这一章要聊的东西，是整条安全链路的基石。你想想看，如果设备连「我是谁」都说不清楚，那后面签发的证书再漂亮，又有什么意义？

设备身份与信任根，说白了就是三件事：唯一标识、信任锚点、预置密钥。这三者缺一不可，而且顺序不能乱。我在项目里见过太多「先烧密钥再写标识」的案例，结果后面追溯的时候，设备跟密钥对不上，整个批次都得返工。

3.1 设备唯一标识：从出生就带着的身份证

设备唯一标识，英文叫 Device Unique Identifier，简称 DUID。它不是简单的 MAC 地址或者 UUID，而是一个不可篡改、不可伪造、全球唯一的硬件级身份。

我个人习惯把 DUID 分成三类：

类型	载体	特点	典型长度
芯片级 ID	MCU/MPU 内部 OTP	出厂即固化，不可改写	64-128 bit
安全元件 ID	SE/TEE 内部	由安全芯片厂商预置	128-256 bit
自定义标识	外部 EEPROM/Flash	产线烧录，可追溯批次	可变

这里有个坑，我得提醒你：千万不要用 MAC 地址当唯一标识。为什么？MAC 地址可以软件修改，而且同一型号的设备 MAC 地址段是固定的，攻击者很容易猜出其他设备的 MAC。我曾经在一个智能门锁项目里，发现厂商直接用 WiFi MAC 做设备身份，结果攻击者改个 MAC 就能冒充合法设备开门——嗯，那场面挺尴尬的。

3.2 信任锚点：谁说了算？

信任锚点，英文叫 Trust Anchor。这个概念其实很简单：你凭什么相信这台设备是合法的？

在 PKI 体系里，信任锚点通常是一个根证书或者根公钥。设备在出厂时，会把厂商的根证书或者根公钥预置进去。后续所有证书的验证，最终都会回溯到这个锚点。

我建议你记住这个公式：

设备信任链 = 信任锚点 + 证书链 + 签名验证

举个例子。设备启动时，会收到服务器下发的证书。设备怎么验证这个证书？它会用预置的根公钥去验证证书链上的每一级签名。如果全部验证通过，说明这个证书是可信的。如果中间任何一环断了，对不起，直接拒绝。

你可能会问：根证书过期了怎么办？嗯，这是个好问题。我一般会在设备里预置两个信任锚点：一个是当前有效的根证书，另一个是备用根证书。备用根证书的有效期更长，而且签名密钥离线保存。这样即使主根证书轮换，设备也能通过备用锚点完成过渡。

3.3 预置密钥：安全注入的最后一公里

预置密钥，就是设备在出厂时烧录的私钥或者对称密钥。它是设备身份的核心凭证，也是整个安全体系的阿喀琉斯之踵。

预置密钥有三种常见形态：

1. 非对称密钥对：私钥留在设备，公钥上传服务器。这是最推荐的方式。
2. 对称密钥：设备和服务器共享同一个密钥。适合资源受限的设备。
3. 预共享密钥（PSK）：用于 TLS-PSK 或类似协议，轻量但安全性依赖密钥管理。

我个人强烈建议：能用非对称就别用对称。为什么？对称密钥一旦泄露，所有设备都得换。而非对称密钥，即使某个设备的私钥泄露，也只影响那一台设备。

3.4 三者关系：一张图说清楚

好，我们来看一张图。这张图展示了设备身份、信任锚点和预置密钥之间的关系：

这张图的核心逻辑是：设备唯一标识、信任锚点、预置密钥，三者必须同时存在，且绑定关系不可被软件修改。它们共同构成了设备的「数字身份证」。

3.5 避坑指南：我踩过的那些坑

最后，分享几个我亲身经历过的坑，希望能帮你少走弯路：

• 坑一：标识和密钥分离存储。 有一次，我把 DUID 写在 Flash 里，密钥写在 OTP 里。结果设备升级时，Flash 被擦除了，DUID 丢了，密钥还在。设备变成了「有钥匙没身份证」的孤儿。后来我学乖了，要么全部放 OTP，要么用安全芯片统一管理。
• 坑二：信任锚点写死在固件里。 固件是可以被逆向的。攻击者拿到固件，就能提取出根公钥，然后伪造证书链。正确的做法是：信任锚点放在安全存储区，固件只保留对锚点的引用。
• 坑三：产线密钥注入没有校验。 我曾经在一个项目里，产线烧录完成后没有做回读校验。结果有 5% 的设备密钥写入失败，但产线报告「全部成功」。等到设备部署到现场才发现，那些设备根本无法完成身份认证。从那以后，我坚持「烧录必校验，校验必记录」。