从真实攻击案例看序列号设计

某智能门锁厂商曾因序列号可预测，导致攻击者通过脚本批量生成有效序列号并绑定到攻击者账号，最终触发大规模设备劫持事件。事后分析发现，其序列号仅为『型号前缀+8位自增数字』，攻击者仅需遍历1000万次即可覆盖所有可能组合。这种设计缺陷在智能家居、工业网关等联网设备中普遍存在。

攻击链完整复盘：攻击者首先通过公开渠道获取了10个真实序列号样本（来自电商平台用户晒单），发现其符合"LOCK-2023XXXX"的简单模式。随后编写Python脚本以每秒200次的速率向厂商API发起绑定请求，72小时内成功控制了超过12,000台设备。更严重的是，由于系统未做设备归属地校验，攻击者得以跨区域操控门锁。

行业现状调研：在对37家IoT厂商的抽样测试中，有23家（62%）的序列号存在可预测风险，其中： - 14家使用连续数字编号 - 5家将MAC地址作为序列号主体 - 4家采用未加盐的简单哈希算法

硬件序列号的三重身份

1. 生产标识：MES系统过站记录的核心索引，需要支持快速扫描与检索
2. 扫描枪识别时间应<50ms
3. 需兼容Code128/QR混合编码

4. 建议保留产线ID+工位ID等调试信息（需加密）

5. 安全令牌：设备与云端绑定的唯一凭证，必须抵抗重放攻击

6. 满足OWASP IoT Top 10中A2弱身份认证防护要求
7. 推荐使用FIPS 140-2 Level 2及以上安全模块

8. 有效期内防碰撞概率需<10^-9

9. 追踪依据：售后服务的生命周期锚点，需保持长期唯一性

10. 至少20年不重复（考虑设备换代周期）
11. 支持逆向解析生产批次/供应商等关键信息
12. 符合ISO/IEC 15459国际标识符标准

可预测序列号的典型反模式

• 纯自增计数器：直接使用STM32芯片UID未做哈希扩散，攻击者可推算生产批次

• 实测案例：某PLC设备UID末4位为连续值，可定位到具体生产周次

• 时间戳暴露：采用YYYYMMDD+流水号格式，泄露设备生产日期

• 风险场景：攻击者针对特定固件版本的漏洞设备发起定向攻击

• 弱校验算法：如Luhn算法校验的信用卡式编号，算法公开易破解

• 破解演示：使用Hashcat在RTX 4090上可达1.2亿次/秒的猜测速度

• 组合信息泄露：MAC地址末字节拼接固件版本号，暴露硬件配置

• 实际影响：某摄像头厂商因此泄露了85%设备的物理位置信息

硬件侧的防御性设计

生成阶段

• 真随机源：使用STM32H7的RNG外设，通过ADC采样噪声源产生熵
• 配置要点：启用时钟抖动补偿，确保熵值>0.9/bit

• 采样参数：建议采集8个LSB位，抖动周期设为32个HCLK

• 哈希扩散：对芯片UID执行SHA-256后取中间16字节

  SN_{secure} = SHA256(UID||Salt)[8:24]

• 盐值管理：每个产线使用独立盐值，存储于HSM模块

• 抗ASIC优化：迭代次数≥1000次

• 分层编码：采用[2字节厂商ID]_[1字节产线ID]_[13字节TRNG熵值]结构

• 字段说明：
  • 厂商ID：由IEEE统一分配
  • 产线ID：支持255条独立产线
  • 熵值段：包含温度传感器实时数据

存储阶段

• 熔丝位锁定：GD32的OPT字节支持一次性写入，防止后期篡改
• 写入电压：需2.7-3.6V专用编程电压

• 验证方法：读取OPT位后与期望值按位与

• 双区备份：在Nor Flash开辟两个独立分区存储序列号及CRC32校验值

• 分区规划：
  • Area1: 主存储区（地址0x08080000）
  • Area2: 镜像区（地址0x080A0000）

• 同步机制：上电时自动校验一致性

• 反篡改设计：使用AES-128加密存储，密钥由硬件安全模块保护

• 典型方案：ATECC608A的Secure Boot配置
• 密钥轮换：每10万设备更换一次主密钥

云端协同方案实施步骤

1. 预置令牌：生产时在设备写入一次性激活令牌（基于TOTP算法）
2. 令牌参数：
   • 有效期：30天
   • 步长：60秒
   • 长度：6位数字

3. 防重放：使用单调递增计数器

4. 双向认证：设备首次联网时提交令牌+芯片UID哈希，云端验证通过后发放正式凭证

5. 通信协议：MQTT over TLS 1.3
6. 证书链：设备端预置中级CA证书

7. 超时设置：3次失败后锁定24小时

8. 速率限制：同一IP地址每小时最多发起5次绑定请求

9. 限流算法：令牌桶算法（burst=5，rate=1/12min）

10. 异常处理：触发CAPTCHA验证

11. 异常检测：连续3次无效请求触发设备锁定，需物理复位解除

12. 锁定机制：写入EFUSE特定位
13. 恢复流程：需售后人员用专用设备复位

应急响应清单

执行细节： - 识别期需同步更新WAF规则，拦截包含旧序列号的请求 - 过渡期OTA包应包含回滚保护机制 - 修复期需对近3个月生产设备进行标记 - 审计期应重建覆盖所有分片的全局唯一索引

成本与选型建议

低成本方案对比

• STM32F0系列：$0.8/片，需外挂ATECC608A安全芯片（$0.6/片）
• 开发成本：需设计双芯片通信协议

• 典型应用：智能插座等对成本敏感设备

• GD32E230系列：$0.95/片，内置AES+TRNG，BOM节省$0.45

• 注意事项：需验证TRNG的NIST SP800-22合规性
• 适用场景：需要国密支持的物联网终端

产线影响评估

• 烧录时间：安全序列号写入耗时增加200ms/设备
• 优化方案：采用并行烧录架构

• 设备要求：需支持JtagESP协议的编程器

• 良率控制：需增加UID哈希校验工位，直通率下降约0.5%

• 补偿措施：引入机器学习进行早期故障预测
• 监控指标：CPK值需维持在1.33以上

工程验证方法

1. 预测性测试：用已知前100个序列号尝试推导第101个
2. 通过标准：连续1000次猜测命中率为0

3. 工具推荐：Python hypothesis库

4. 熵值检测：使用NIST STS测试套件验证随机性

5. 关键指标：
   • P-value > 0.01
   • Approximate Entropy ≥ 7.5

6. 样本量：至少1MB原始数据

7. 碰撞测试：生成100万个序列号检查重复率

8. 允许范围：重复数≤3个（符合泊松分布预期）
9. 扩展测试：在不同温度（-40°C~85°C）下重复测试

开放讨论

• 算法透明度：可公开哈希算法但保留盐值私密，符合Kerckhoffs原则
• 平衡点建议：每年更新一次哈希算法版本

• 审计要求：通过第三方密码学评估

• 合规要求：医疗设备需满足FDA UDI标准，与安全设计如何平衡？

• 解决方案：采用HIBC+安全序列号的混合编码

• 实施案例：某血糖仪厂商采用"UDI-PI+128bit熵"格式

• 产线追溯：测试接口建议采用独立编号体系，与正式序列号隔离

• 编码规则：TEST_[日期][工位ID][随机4HEX]
• 生命周期：测试完成后自动失效

总结

硬件序列号设计需要跨越『生产可追溯』与『安全防预测』的双重要求。通过芯片级熵源+分层编码+云端协同的三段式方案，可在增加<$0.2/BOM成本的前提下，将撞库风险降低3个数量级。建议厂商在下一代产品设计中采用基于物理不可克隆函数(PUF)的终极解决方案，该技术已在国内多家安防设备厂商实现量产验证。同时需建立从芯片到云端的全链路安全审计体系，定期进行红队演练以验证防御有效性。