3、SBOM与设备身份绑定：如何将SBOM与设备唯一标识关联
好，我们进入第三章。前面两章我们把SBOM的基础概念和它在物联网里的价值聊清楚了。但有个问题一直悬着——你拿到的SBOM，怎么证明它属于这台设备？
说白了，SBOM只是一份清单。如果它跟设备本身是脱钩的，那攻击者完全可以伪造一份干净的SBOM，贴到被篡改过的设备上。我在项目里见过这种案例：设备固件被替换了，但云端查SBOM还是旧的、安全的版本。为什么？因为SBOM和设备之间没有建立信任锚点。
这一章，我们就来解决这个核心问题——如何把SBOM和设备的物理身份绑死。
3.1 设备唯一标识：从软件到硬件的信任迁移
先想一个问题：设备的“身份”到底是什么？
传统做法是用MAC地址、序列号、IMEI。但这些玩意儿都是软件可读的，说白了就是一段字符串。攻击者改个系统文件就能换掉。你想想看，如果身份标识本身不可信，那基于它做的所有校验都是白搭。
所以，真正的信任必须下沉到硬件层。我们需要一个不可克隆、不可篡改的硬件锚点。
目前业界主流方案有两个：
- TPM（可信平台模块）：国际标准，有专门的密码协处理器，内置RSA/ECC密钥对、PCR寄存器、安全存储。
- 安全芯片（SE）：类似TPM，但更轻量，常见于IoT终端，如NXP SE050、Microchip ATECC608。
这两种芯片出厂时就会烧录一个唯一设备密钥（UDK），私钥永远不出芯片。这就是信任的起点。
核心原则：信任必须从硬件硅片开始，而不是从操作系统启动之后才开始。硬件锚定信任根，软件只能继承信任，不能创造信任。
3.2 硬件锚定信任根：TPM/Security Element的工作机制
我简单画个图，帮你理解硬件信任根是怎么工作的。
流程其实不复杂。核心就三步：
- 硬件生成密钥对：TPM或安全芯片在内部生成RSA-2048或ECC-P256密钥对，私钥永远不暴露给CPU或操作系统。
- 签发设备身份证书：用私钥签名一个CSR，交给工厂CA签发X.509证书。这个证书就是设备的“身份证”。
- SBOM签名绑定：在设备首次启动或固件更新时，用同一把私钥对SBOM的哈希值签名。签名结果和SBOM一起存储。
我的经验：曾经有个客户，为了省成本，把SBOM签名密钥放在文件系统里。结果设备被提权后，攻击者直接替换了SBOM和签名。后来改成用ATECC608存储密钥，同样的问题再没出现过。硬件锚定不是锦上添花，是底线。
3.3 绑定方案对比：TPM vs 安全芯片
很多工程师会问：我到底该用TPM还是安全芯片？我列个表，你一看就明白。
| 对比维度 | TPM（如Infineon SLB9670） | 安全芯片（如NXP SE050） |
|---|---|---|
| 标准规范 | ISO/IEC 11889, TCG 标准 | 无统一标准，厂商自定义 |
| 密钥存储 | NVRAM + PCR 保护 | 安全EEPROM/Flash |
| 密码算法 | RSA/ECC/SHA/HMAC，支持TPM2.0 | RSA/ECC/AES，部分支持国密 |
| 性能 | 中等，适合网关/边缘设备 | 高，适合传感器/终端节点 |
| 成本 | 较高（$2-$5） | 较低（$0.5-$2） |
| SBOM绑定方式 | TPM2_Quote + TPM2_Sign | 内部签名指令 + 证书链 |
我个人习惯这样选：如果设备是网关、路由器这类有Linux系统的，用TPM，因为它能配合IMA（完整性度量架构）做启动时度量。如果是传感器、智能锁这类MCU设备，用安全芯片，轻量、便宜、够用。
3.4 实战：用TPM2.0对SBOM签名
光说不练假把式。我写一段实际可用的代码，展示如何用TPM2.0对SBOM进行签名绑定。
前提：设备已初始化TPM，并已生成持久化密钥（Handle 0x81000001）。
#!/bin/bash
# SBOM签名绑定脚本 - 使用TPM2.0
# 1. 生成SBOM（假设已存在sbom.json）
SBOM_FILE="sbom.json"
SBOM_HASH="sbom.sha256"
# 2. 计算SBOM哈希
sha256sum $SBOM_FILE | awk '{print $1}' > $SBOM_HASH
# 3. 使用TPM私钥签名（持久化密钥handle）
# 注意：私钥永不出TPM，签名操作在芯片内部完成
tpm2_sign \
--key-context 0x81000001 \
--hash-algorithm sha256 \
--scheme rsassa \
--digest $SBOM_HASH \
--signature sbom.sig
# 4. 将SBOM + 签名打包
tar -czf sbom_bundle.tar.gz $SBOM_FILE sbom.sig
# 5. 可选：将签名块写入TPM NVRAM
tpm2_nvwrite \
--hierarchy o \
--index 0x01C00001 \
--size 256 \
--input sbom.sig
echo "SBOM签名绑定完成，签名块已写入TPM NVRAM"注意：上面的tpm2_sign命令中，--digest参数传入的是哈希文件，不是原始SBOM。TPM内部会对哈希再做一次填充和签名。另外，NVRAM索引需要提前定义好大小和属性，否则写入会失败。我曾经因为忘记设置nvdefine，调试了整整一个下午。
3.5 验证流程：如何证明SBOM属于这台设备
签名只是第一步。真正关键的是验证。我见过不少方案，签名做得花里胡哨，验证却形同虚设。
正确的验证流程应该是：
- 读取设备证书：从TPM/安全芯片中读取设备身份证书（或公钥）。
- 提取SBOM签名块：从NVRAM或安全存储中读取签名。
- 计算SBOM哈希：对当前SBOM重新计算哈希。
- 验签：用设备公钥验证签名是否匹配。
- 比对证书链：确认设备证书是由可信CA签发的，没有被吊销。
只有这五步全部通过，才能说“SBOM属于这台设备且未被篡改”。
避坑指南：我曾经在项目里只做了验签，没做证书链校验。结果攻击者用自己的CA签了个假证书，替换了设备证书。验签通过了，但设备已经被完全控制。记住：验签只证明签名有效，不证明签名者可信。证书链校验才是信任的闭环。
3.6 小结：硬件锚定是SBOM可信的基石
这一章的核心就一句话：SBOM必须和硬件身份绑定，绑定必须基于硬件信任根。
没有硬件锚定的SBOM，就像没有签名的合同——谁都可以伪造。TPM和安全芯片不是可选项，而是物联网设备身份认证的必选项。你想想看，如果连设备身份都保不住，那SBOM里列的那些组件信息还有什么意义？