从安全事件看序列号设计的致命误区

今年某智能门锁品牌曝出漏洞：攻击者通过简单递增规律，暴力遍历设备序列号完成云端账号绑定，最终控制数万台设备。这暴露了硬件开发中序列号生成-存储-绑定链路的系统性缺陷。本文基于工业级安防设备实战经验，拆解防预测攻击的工程方案。

序列号不是计数器，是安全地基

常见错误实践

• 连续分配：产线直接用自增整数（如从000001开始）
• 时间戳裸编码：将生产日期+流水号明文拼接（如20260815-1234）
• 哈希伪装：对简单ID做MD5运算但熵源不足（攻击者仍可逆推）

硬件熵源采集方案

产线端：MES系统与密码学隔离

1. 预烧录阶段：
2. 在芯片烧录环节注入加密种子（如通过ST-Link的Option Bytes）

3. 使用AES-CTR模式生成序列号流，避免暴露原始熵源

4. 过站记录：

5. MES数据库对sn字段建立唯一索引+写入保护
6. 存储哈希值而非明文（如SHA256(sn+产线盐值)）

首次绑定抗暴破设计

// 设备端实现一次性令牌（示例逻辑）
void generate_binding_token() {
    uint8_t challenge[32];
    hw_random_read(challenge, 32); // 读取硬件随机源
    sha256_hmac(challenge, server_key, token); // 生成时效性令牌
    flash_write(TOKEN_AREA, token); // 写入保护分区
}

关键策略： - 设备在首次上电时生成不可预测的绑定令牌 - 云端验证后立即失效，防止重放攻击 - 通过BLE/WiFi Provisioning传输时启用ECDH密钥交换

深度防御：从芯片到云的联动方案

芯片级防护

• 安全启动：确保序列号生成代码未被篡改（参考STM32 TrustZone方案）
• 防回滚：通过OTP存储器锁定算法版本（如GD32的Anti-rollback机制）

网络层加固

• 速率限制：云端API限制同一IP的绑定请求（建议≤5次/分钟）
• 设备指纹：结合MAC地址、PCB阻抗特征等生成辅助认证因子

生产测试陷阱

• 虚假序列号注入：在测试固件中植入伪随机SN生成器，与量产算法隔离
• 工装校验：通过治具物理按键确认设备合法性（防产线内盗）

应急响应预案

当发现序列号规律泄露时： 1. 立即禁用受影响批次的云端注册接口 2. 推送紧急OTA更新，在设备端重构序列号（需保留原始SN备份） 3. 对已绑定设备强制二次认证（如物理按键确认）

成本与方案选型指南

争议点：是否应该公开序列号生成算法？经过FIPS认证的密码学模块可以公开设计，但自制算法建议通过模糊处理增加逆向成本。

工程师自查清单

1. 是否所有量产设备SN均通过密码学算法生成？
2. 产线MES系统是否禁止SN字段的人工修改？
3. 首次绑定流程是否包含时效性令牌？
4. 应急OTA通道是否能绕过常规认证？
5. 测试模式下的SN生成器是否与量产隔离？

实际部署案例表明，采用L3级方案的智能电表设备，在渗透测试中成功抵御了超过200万次撞库攻击。这印证了硬件级熵源与系统化防御的价值。