对称密钥认证：主机和设备共享同一把密钥

对称密钥认证，是指主机和设备共享同一类密钥，通过相同算法计算认证结果，从而判断对方是否拥有正确密钥。

它的特点是：

• 速度快；
• 资源占用低；
• 实现相对简单；
• 适合 MCU、耗材、配件、传感器等资源受限场景。

在嵌入式系统中，对称密钥认证常用于：

• 耗材认证；
• 配件认证；
• 探头认证；
• 电池认证；
• 短报文消息认证；
• 主机与外设之间的挑战响应。

但它也有一个非常关键的工程风险：

关键词	工程含义
对称密钥 / 派生密钥	适合低成本认证，但必须避免全局共享密钥。

1. 什么是对称密钥认证

对称密钥认证的核心思想是：

主机和设备都持有同一类密钥。

谁能用这把密钥算出正确结果，谁就被认为是可信对象。

这里的"对称"指的是：

• 主机端知道密钥；
• 设备端也知道对应密钥；
• 双方使用相同算法计算认证结果。

例如，主机发送一个随机 Challenge，设备使用内部密钥计算 MAC，主机使用相同密钥计算期望 MAC。

如果两个结果一致，说明设备大概率持有正确密钥。

---

2. 典型认证流程

对称密钥认证最常见的形式是 Challenge-Response 挑战响应。

典型流程如下：

1. 主机读取设备 SN
2. 主机生成随机 Challenge
3. 主机将 Challenge 发送给设备
4. 设备使用内部密钥计算 MAC
5. 设备返回 Response
6. 主机使用对应密钥计算 Expected_Response
7. 主机比较 Response 和 Expected_Response
8. 一致则认证通过，不一致则拒绝使用

可以简化表示为：

Host → Device:
    Challenge

Device:
    Response = HMAC(Device_Key, Challenge)

Device → Host:
    Response

Host:
    Expected = HMAC(Device_Key, Challenge)

if Response == Expected:
    认证通过
else:
    认证失败

这个过程中，设备不需要把密钥发送出来。

设备只需要证明：

我拥有正确密钥。

---

3. 为什么不能所有设备共用一把密钥

最简单的设计是：

所有设备都使用同一把 Global_Key

这种方式实现简单，但风险非常高。

因为一旦攻击者从某一台设备中提取出 Global_Key，就可以伪造所有设备。

后果包括：

• 可以批量克隆耗材；
• 可以伪造合法配件；
• 可以绕过探头认证；
• 可以伪造通信报文；
• 可以生产山寨设备；
• 可以影响整批产品安全。

这就是典型的全局共享密钥风险。

所以工程上应尽量避免：

Device_A_Key = Global_Key
Device_B_Key = Global_Key
Device_C_Key = Global_Key
...

更合理的方式是：

Device_A_Key != Device_B_Key != Device_C_Key

也就是每台设备都有自己的唯一密钥。

---

4. 唯一派生密钥

为了避免所有设备共用一把密钥，工程上常用唯一派生密钥。

基本思想是：

使用一个父密钥 Root_Key，再结合设备唯一信息，派生出每台设备自己的密钥。

例如：

Device_Key = KDF(Root_Key, Device_SN)

或者：

Device_Key = HMAC-SHA256(Root_Key, Device_SN)

其中：

字段	含义
Root_Key	父密钥，只存在于安全产线系统、HSM 或主机安全模块中
Device_SN	设备唯一序列号
Device_Key	每台设备最终保存的唯一密钥

这样做的好处是：

• 每台设备密钥不同；
• 单台设备密钥泄露，不会直接泄露父密钥；
• 攻击者不能直接推导其他设备密钥；
• 主机可以根据 SN 动态计算对应设备密钥；
• 产线可以按设备唯一身份写入不同密钥。

---

5. 派生密钥的工程示例

假设有 3 个耗材：

SN_A = 100001
SN_B = 100002
SN_C = 100003

使用父密钥派生：

Key_A = HMAC-SHA256(Root_Key, SN_A)
Key_B = HMAC-SHA256(Root_Key, SN_B)
Key_C = HMAC-SHA256(Root_Key, SN_C)

最终结果是：

Key_A != Key_B != Key_C

耗材 A 内部只保存 Key_A。

耗材 B 内部只保存 Key_B。

耗材 C 内部只保存 Key_C。

即使攻击者破解了耗材 A，拿到 Key_A，也不能直接得到 Key_B、Key_C，更不能反推出 Root_Key。

这就把攻击影响范围限制在单台设备或单个耗材上。

---

6. 认证时主机如何得到设备密钥

使用唯一派生密钥后，主机认证设备时通常有两种方式。

---

6.1 方式一：主机保存父密钥并动态派生

主机读取设备 SN 后，动态计算：

Device_Key = HMAC-SHA256(Root_Key, Device_SN)

然后用 Device_Key 验证设备 Response。

优点是：

• 不需要保存所有设备密钥表；
• 只要知道 SN，就能计算对应密钥；
• 适合大量设备、耗材和配件认证。

缺点是：

• 主机必须保护 Root_Key；
• 如果主机 Root_Key 泄露，可能影响大量设备；
• 主机端最好使用安全芯片、安全区域或受控模块保存 Root_Key。

---

6.2 方式二：主机保存设备密钥表

主机或服务器保存：

SN_A → Key_A
SN_B → Key_B
SN_C → Key_C

认证时根据 SN 查找对应 Device_Key。

优点是：

• 主机不需要保存 Root_Key；
• 单个密钥泄露影响范围可控；
• 可以单独吊销某个设备密钥。

缺点是：

• 密钥表管理复杂；
• 大批量设备时存储和维护成本较高；
• 离线设备可能不方便同步密钥表。

---

7. 产线设计

对称密钥认证是否安全，很大程度取决于产线密钥管理。

生产阶段应由 HSM 或受控产线系统完成密钥派生和写入。

推荐流程：

1. 产线系统读取设备 SN
2. HSM 根据 Root_Key 和 SN 派生 Device_Key
3. 产线系统将 Device_Key 写入设备安全区域或加密芯片
4. 写入后锁定调试口和读保护
5. 产线记录 SN、批次、证书编号、写入状态
6. Device_Key 不以明文形式保存在普通产线电脑中

关键原则是：

父密钥不应出现在普通产线电脑、脚本、日志、烧录文件或 MCU 固件中。

设备端只保存派生密钥。

主机端可以保存父密钥，也可以通过安全模块动态派生。

---

8. 父密钥不能放在哪里

工程上应避免把父密钥放在以下位置：

• 普通 PC 脚本；
• Excel 表格；
• 烧录配置文件；
• MCU 固件源码；
• 固件常量数组；
• 调试日志；
• 产线明文数据库；
• 邮件或网盘文档；
• 普通外部 Flash；
• 未保护的 EEPROM。

一旦 Root_Key 泄露，攻击者可能批量派生合法设备密钥。

因此，Root_Key 应尽量只存在于：

• HSM；
• 安全服务器；
• 安全芯片；
• MCU 安全区域；
• 受控密钥管理系统。

---

9. 设备端密钥存储

设备端保存的是 Device_Key，而不是 Root_Key。

设备端密钥应尽量存放在：

• 加密芯片；
• 安全认证芯片；
• MCU 安全存储区域；
• OTP / eFuse；
• 读保护 Flash；
• TrustZone 安全区；
• 不可直接读取的密钥槽。

如果只能存放在普通 MCU Flash 中，应至少采取：

• 开启读保护；
• 关闭 SWD/JTAG；
• 禁止调试口量产开放；
• 固件中避免明文打印密钥；
• 产线写入后立即锁定；
• 防止升级包覆盖密钥区；
• 对密钥区做访问权限隔离。

---

10. 对称认证的优点

对称密钥认证在嵌入式系统中非常实用，主要优点包括：

10.1 速度快

HMAC、AES-CMAC 等算法计算速度较快。

对于 MCU 来说，认证一次通常可以在较短时间内完成。

---

10.2 资源占用低

相比非对称算法，对称算法通常占用更少的 Flash、RAM 和 CPU。

这对低成本 MCU、耗材芯片、传感器模块非常重要。

---

10.3 实现简单

主机和设备使用相同算法即可完成认证。

协议流程清晰，容易嵌入到现有通信流程中。

---

10.4 适合短报文认证

对于控制命令、状态包、配置包、耗材认证包等短报文，对称 MAC 很适合。

---

11. 对称认证的缺点

对称认证最大的挑战是密钥管理。

11.1 密钥分发压力大

因为主机和设备都要知道对应密钥，所以密钥必须安全写入双方。

密钥在产线、维修、升级、备份过程中都有泄露风险。

---

11.2 主机密钥保护压力大

如果主机需要保存 Root_Key 或大量 Device_Key，就必须有足够保护。

否则一旦主机被破解，攻击者可能伪造大量设备。

---

11.3 不适合公开验证场景

对称认证要求验证方也知道密钥。

如果有很多第三方系统都需要验证设备，就必须把密钥分发给多个验证方。

这会增加密钥泄露风险。

这种场景更适合使用非对称签名或证书机制。

---

11.4 密钥轮换和吊销复杂

当某个密钥泄露后，需要考虑：

• 如何吊销；
• 如何更新；
• 如何通知主机；
• 如何兼容旧设备；
• 如何防止攻击者继续使用旧密钥。

这些都需要在架构阶段提前设计。

---

12. 对称认证适合哪些场景

对称密钥认证适合：

• 耗材认证；
• 探头认证；
• 电池认证；
• 传感器模块认证；
• 主机与固定外设认证；
• 短报文完整性保护；
• 成本敏感设备；
• 低资源 MCU；
• 离线认证场景。

尤其适合主机和设备关系比较固定的系统，例如：

主机 ↔ 耗材
主机 ↔ 探头
主机 ↔ 电池
主机 ↔ 传感器模块
主控 MCU ↔ 安全芯片

---

13. 不太适合哪些场景

对称认证不太适合：

• 多个第三方都要验证设备；
• 验证方不可信；
• 主机容易被攻击者拿到并逆向；
• 大规模开放生态；
• 需要公开验证固件来源；
• 需要跨组织信任链；
• 需要强身份体系和证书链。

例如，固件升级包验证通常不推荐只依赖对称 MAC。

因为设备端如果保存验证密钥，一旦设备被破解，攻击者可能伪造升级包。

对于固件发布验证，更常见做法是：

发布方私钥签名
设备端公钥验证

也就是使用数字签名。

---

14. 工程注意事项

14.1 避免全局共享密钥

不要让所有设备使用同一把密钥。

应尽量做到：

一机一密
一耗材一密
一探头一密
一模块一密

---

14.2 密钥与设备身份绑定

派生密钥时应绑定设备唯一信息，例如：

Device_Key = HMAC-SHA256(Root_Key, Device_SN || Product_Type || Batch_ID)

这样可以避免不同产品线、不同批次之间密钥混用。

---

14.3 Challenge 必须随机且一次性

对称认证通常依赖挑战响应。

因此 Challenge 必须满足：

• 由验证方生成；
• 随机或不可预测；
• 一次性使用；
• 绑定当前会话；
• 超时失效；
• 成功或失败后都失效。

否则截获的 Response 可能被重放。

---

14.4 MAC 比对使用常量时间比较

验证 Response 时，不建议使用普通字符串比较函数。

应使用常量时间比较，避免因为提前退出导致时序泄露。

---

14.5 不要自己设计算法

不要自行设计类似下面的认证算法：

Response = CRC(Key + Challenge)
Response = Hash(Key + Challenge)
Response = Challenge XOR Key
Response = AES_Encrypt(Challenge) 的部分字节

工程上应使用成熟算法，例如：

• HMAC-SHA256；
• AES-CMAC；
• 安全芯片提供的 MAC 认证接口；
• 经过验证的密码库。

---

15. 工程总结

对称密钥认证适合资源受限、成本敏感、主机与设备关系固定的嵌入式场景。

它的核心优势是：

速度快、成本低、实现简单。

但它的核心风险是：

密钥一旦泄露，攻击者就可以伪造合法设备或合法报文。

因此，对称认证工程落地时必须注意：

• 避免全局共享密钥；
• 每台设备使用唯一派生密钥；
• 父密钥只存在于 HSM 或安全系统中；
• 设备端只保存派生密钥；
• Challenge 必须随机、一次性、短时有效；
• 密钥写入、调试口关闭、读保护和产线记录必须形成闭环。

简单来说：

对称认证不是难在算法，而是难在密钥管理。

一机一密、安全产线、密钥隔离，是对称认证能否真正安全的关键。