📚 课程目录第3章设备身份基石

3. 设备身份基石：设备唯一标识（Device ID）、基于硬件的信任根（TPM/SE）、设备证书签发与管理

大家好，我是老周。今天咱们聊点实在的——设备身份。你想想看，零信任的核心逻辑是「永不信任，始终验证」。那验证什么？说白了，就是验证「你是谁」。在 IoT 的世界里，这个「谁」就是设备的唯一标识。

我见过太多项目，设备上线后直接被仿冒，原因就是身份太弱。有的用 MAC 地址当身份，有的甚至写死在配置文件里。嗯，这跟把家门钥匙挂在门口没啥区别。所以这一章，咱们把设备身份的根给扎牢。

3.1 设备唯一标识（Device ID）—— 身份的起点

设备唯一标识，就是设备在网络世界里的「身份证号」。但这个号码不能随便编，它得满足几个硬性条件：

全球唯一性：不能跟别的设备撞车。
不可篡改性：至少得防住普通攻击者。
可撤销性：设备报废了，身份得能注销。

我习惯把 Device ID 分成两类：

类型	生成方式	典型例子	安全性
软件 ID	算法生成 + 存储	UUID、MAC+序列号哈希	低（可被复制）
硬件绑定 ID	芯片熔丝 / OTP	芯片唯一序列号、TPM 背书密钥	高（物理不可克隆）

⚠️ 避坑指南： 我曾经在一个智能门锁项目里，直接用 Wi-Fi MAC 地址当 Device ID。结果发现攻击者可以轻松伪造 MAC 地址，导致门锁被远程开锁。后来全部换成了芯片内置的 OTP 序列号，才堵住这个漏洞。

3.2 基于硬件的信任根（TPM / SE）—— 信任的锚点

光有 ID 还不够。你得证明「这个 ID 确实属于这台设备」。这时候就需要硬件信任根了。

TPM（可信平台模块）和 SE（安全元件）就是干这个的。它们是一颗独立的芯片，或者集成在 SoC 里的安全区域。核心能力就三样：

安全存储：私钥永远不出芯片。
加密运算：在芯片内部完成签名、解密。
平台度量：测量固件和系统的完整性。

我举个例子。TPM 内部有一组被称为「背书密钥（EK）」的根密钥。这个 EK 是在芯片出厂时烧录的，全世界唯一，且无法读取。设备身份认证的链条，就是从 EK 开始的。

  💡 核心逻辑： 信任根 = 硬件保护的私钥 + 不可伪造的公钥证书。没有硬件信任根，设备身份就是「裸奔」。

为什么会这样？因为纯软件方案，私钥总归要存在 Flash 或文件系统里。攻击者拿到固件，就能把私钥 dump 出来。而 TPM/SE 的私钥，你就算把芯片泡在硝酸里也读不出来。

3.3 设备证书签发与管理 —— 身份的「护照」

有了硬件信任根，下一步就是给它发一本「护照」——也就是设备证书。设备证书通常采用 X.509 格式，里面包含了 Device ID、公钥、有效期、签发者等信息。

我习惯把证书签发流程分成三步：

生成密钥对：在设备端，利用 TPM/SE 生成公私钥对。私钥留在芯片内，公钥导出。
证书签名请求（CSR）：设备用私钥对 CSR 签名，然后发给 CA（证书颁发机构）。
CA 签发：CA 验证设备身份后，签发设备证书，并返回给设备。

这里有个关键点：CA 怎么验证设备身份？我见过两种主流做法：

预置密钥方式：设备出厂时，CA 把设备公钥或证书预置在数据库中。设备上线时，CA 通过挑战-应答验证设备是否持有对应私钥。
链式信任方式：设备使用 TPM 的 EK 证书向 CA 证明身份。CA 验证 EK 证书的合法性后，再签发设备证书。

下面这张图，展示了完整的设备证书签发与认证流程：

3.4 证书生命周期管理 —— 从出生到销毁

证书不是发完就完事了。它跟人一样，有完整的生命周期。我把它分成五个阶段：

阶段	操作	关键点
注册	设备首次上线，CA 签发证书	必须验证设备硬件身份
使用	设备用证书进行身份认证	每次认证都需验证证书有效性
更新	证书到期前，设备发起续签	需重新验证设备身份
撤销	设备报废或泄露，CA 撤销证书	通过 CRL 或 OCSP 实时同步
销毁	设备退役，清除证书和密钥	TPM 提供安全擦除指令

🔧 实战技巧： 我建议在设备端实现一个「证书健康检查」模块。每次设备上线前，先检查本地证书是否在有效期内，是否被撤销。如果证书异常，自动触发重新注册流程。这样能避免设备因证书过期而「失联」。

3.5 代码实战：基于 TPM 的设备证书签发示例

光说不练假把式。下面我用一个简化示例，展示设备如何利用 TPM 生成密钥对并签发证书。这里假设设备端使用 tpm2-tools，CA 端使用 OpenSSL。

设备端：生成密钥对并创建 CSR

# 1. 在 TPM 内生成 RSA 密钥对，并持久化到 handle 0x81000001
tpm2_createprimary -C e -c primary.ctx
tpm2_create -C primary.ctx -G rsa2048 -u key.pub -r key.priv
tpm2_load -C primary.ctx -u key.pub -r key.priv -c key.ctx
tpm2_evictcontrol -C o -c key.ctx 0x81000001

# 2. 从 TPM 导出公钥
tpm2_readpublic -c 0x81000001 -o device_pub.pem -f pem

# 3. 生成 CSR 配置文件 (device_csr.conf)
# [ req ]
# default_bits = 2048
# distinguished_name = req_distinguished_name
# req_extensions = v3_req
# [ req_distinguished_name ]
# CN = device_001
# [ v3_req ]
# subjectAltName = DNS:device_001.iot.example.com

# 4. 使用 TPM 私钥签名 CSR
openssl req -new -key "handle:0x81000001" -keyform engine \
  -engine tpm2tss -config device_csr.conf -out device.csr

CA 端：验证并签发证书

# 1. CA 验证 CSR 签名（需要设备公钥）
openssl req -in device.csr -verify -noout

# 2. CA 签发设备证书，有效期 365 天
openssl x509 -req -in device.csr \
  -CA ca_cert.pem -CAkey ca_key.pem -CAcreateserial \
  -out device_cert.pem -days 365 -sha256 \
  -extfile device_csr.conf -extensions v3_req

# 3. 将证书返回给设备，设备存入 TPM 安全存储区
# 设备端接收证书后，使用 tpm2 存储到 NVRAM

⚠️ 注意： 上面的示例中，-key "handle:0x81000001" 表示使用 TPM 内的私钥进行签名。实际生产环境中，需要确保 tpm2-tss-engine 正确安装并配置。我曾经在一个项目里因为引擎版本不匹配，折腾了两天才搞定签名问题。

3.6 总结与思考

好了，这一章的内容就到这里。咱们把设备身份的基石给夯实了：

Device ID 是设备的身份证号，必须唯一且不可篡改。
TPM/SE 是信任的锚点，私钥永远不出芯片。
设备证书 是身份的护照，需要完整的生命周期管理。

我个人觉得，设备身份是零信任体系里最容易被忽视的一环。很多团队把精力花在传输加密和访问控制上，却忘了最根本的问题——你怎么确定对面那台设备是它自己？

记住一句话：没有硬件信任根，零信任就是空中楼阁。