物联网设备身份认证方案_ 一机一密实现原理与安全芯片落地路径 | 上海耀罡电子

为什么共用密钥等于没有安全

一个真实的攻击路径

设想一个智能网关厂家的常见做法：所有出厂设备刷入同一份固件，固件里内置一个 AES 密钥，设备用它向云端建立 TLS 连接。

这个方案在设备出厂时是安全的。问题出现在第一台设备被破解之后：

攻击者从一台设备里读出了这个共享密钥，于是他可以：

批量伪造设备接入云平台，让平台以为有几万台真实设备在线；解密其他所有设备的通信，包括传感数据和控制指令；冒充合法设备下发固件升级，把恶意固件推给全网设备。

这就是为什么「一机一密」不是过度设计，而是规模越大越必须——你有 1 万台设备时，一台被破就等于全部被破。

身份认证与数据加密是两件事

很多人会把这两件事混在一起。

身份认证解决的是「连接的这一端是不是它声称的那台设备」；数据加密解决的是「传输的内容会不会被看到或篡改」。

TLS 双向认证（mTLS）同时做了两件事：客户端用证书证明身份，服务器校验证书；双方协商出会话密钥，之后的数据用会话密钥加密。

所以「我们的通信是加密的」不代表安全——如果所有设备共用一张证书，攻击者拿到任意一台的证书就能冒充所有设备。身份这一层没做扎实，后面的加密都是空中楼阁。

设备身份的三层构成

三个要素缺一不可

一个可用的设备身份体系由三部分组成：

唯一 SN 为什么必须是硬件级的

如果唯一 ID 存在 Flash 里，攻击者拿到读写权限就能改写它，复制一台设备出来。只有存在芯片内部、无法通过外部接口读取修改的 SN，才具备身份锚点的资格。

DX 系列的每颗芯片都具备全球唯一 SN，这个 SN 在出厂时由安全芯片内部机制保证唯一性，应用程序读得到但改不了。

这就是硬件根信任（Hardware Root of Trust）的最基础形态：「有一个值，我保证它从我出生起就没变过」。

信任链怎么建

典型流程是标准的 PKI 体系：

根证书（Root CA，厂商自持，离线保管）
  └─ 中间 CA（生产环境使用）
       └─ 设备证书（每台设备一张，含唯一 SN 与公钥）

关键设计点在于：设备证书在产线烧录环节签发，签发过程必须使用中间 CA 的私钥，而中间 CA 的私钥只在产线环境存在。

这样即使产线被物理接触，攻击者拿到的也只是已签发的设备证书，无法伪造出新的合法设备。

一机一密的核心：唯一 SN 派生

三种实现路径

「一机一密」的落地方式主要有三种：

派生方案的关键前提

用 SN 派生密钥，前提是 SN 本身不可预测且不可枚举。

如果 SN 是连续递增的（比如 000001、000002），攻击者可以批量尝试：拿到一台设备的 SN，就能推算出下一台的密钥。

所以使用派生方案时，必须确保 SN 是真正随机的、不可枚举的，并且派生时引入了设备专属的秘密因子（比如芯片内一次性生成的设备密钥参与 KDF）。

DX 系列同时支持唯一 SN 与芯片内不可读写的存储区，可以把「SN + 设备密钥」作为派生的双输入，这是派生方案能安全使用的必要条件。

派生算法的一个实用建议

派生不要用简单的哈希拼接，要用正规 KDF：HKDF（HMAC-based Extract-and-Expand Key Derivation Function）或 PBKDF2。

原因是需要满足两个性质：不同 SN 派生出完全独立的密钥（即使 SN 只差一位，派生结果也要毫无关联）；派生过程可加入上下文信息（把用途、设备型号、协议版本一起作为 info 参数，这样同一台设备用于「设备认证」和「固件加密」的密钥也不同）。

分层密钥体系：不同环节用不同密钥

一个典型的五层结构

单一密钥无法同时满足所有需求。成熟的做法是按用途分层，每层独立管理：

为什么必须分层

如果所有环节共用一把密钥，那么任何一个环节的密钥泄露都会导致全线失守。

分层之后：

L4 会话密钥每台设备每次连接都不同，即便被截获也只影响这一次连接，这直接消除了「长期密钥被复用」这个最致命的风险；L3 固件密钥泄露只影响固件保密性，不影响身份认证体系；L1 根密钥永不出芯片，它只是派生的种子，即便攻击者拿到部分设备密钥也无法反推根密钥。

DX 系列的分层密钥体系正是基于这个思路设计的。

会话密钥是分层的核心价值

在 mTLS 握手中，设备证书里的公钥用于身份验证，而真正加密通道数据的是双方临时协商出的会话密钥。

这意味着：每次连接的加密密钥都是全新的。攻击者即使抓取了全部历史流量，也无法解密未来的通信。

这一点是很多客户在评估方案时最容易忽略的——「我们的数据是加密的」和「我们的数据每次都用新密钥加密」在抗分析能力上差着一个量级。

安全芯片在其中的不可替代性

软件加密为什么不够

理论上所有加密算法都能用软件实现，那为什么还需要一颗专用芯片？因为软件加密的密钥必须存在于内存里，而内存是可以被读出来的。

攻击者的路径通常是：找到漏洞拿 shell → 内存 dump 或 DMA 读取 → 搜出密钥 → 解密或伪造。

安全芯片改变的正是这一点：

密钥永远不进主控内存。主控只能通过标准协议发起「用这把密钥做这个运算」的请求，运算在芯片内部完成，密钥本身不被读出。

这就是安全芯片提供的核心保证：密钥的机密性由硬件保证，而不是由软件的保密性保证。

硬件算法协处理器的价值

DX 系列内置 ECC / SHA1 / 3DES / TRNG 硬件算法协处理器。

这里的关键是 TRNG（真随机数发生器）。加密强度依赖随机数质量——而软件伪随机数（rand()）的输出是可预测的，用可预测的随机数生成密钥，等于没有加密。

硬件 TRNG 基于热噪声或振荡器抖动，输出不可预测。

另一个现实考量是性能与功耗：硬件做一次 ECC 运算可能几十毫秒，软件实现要占用主控算力并推高功耗。在电池供电的设备上，这个差别直接决定续航。

对应到 DX 各系列的分工

DX 系列的五大系列针对不同的攻击面各有侧重：

落地流程：从产线烧写到云端校验

六个环节

① 产线注入    根密钥 / 设备密钥写入芯片，锁定为不可读
        ↓
② 出厂标定    读取唯一 SN，与产线数据库绑定
        ↓
③ 证书签发    用中间 CA 为该 SN 签发设备证书
        ↓
④ 写入设备    证书 + 公钥 + 端点地址写入 Flash
        ↓
⑤ 云端登记    SN 与证书指纹登记入库，作为白名单
        ↓
⑥ 运行时验证  mTLS 握手，链上校验证书与白名单

第 ⑤ 步最容易被忽略

很多项目只做了前四步就上线，结果云端「谁都能连」——因为没有 SN 白名单做二次过滤。

正确的做法是：云端维护一份已登记设备的 SN 列表，收到连接请求时，除了校验证书链，还要检查证书里的 SN 是否在登记列表内。

这一层是防证书泄露的关键——即便某张设备证书被复制，没有对应的 SN 登记记录也无法接入。

证书轮换与吊销

设备证书有有效期，也会有泄露风险。需要规划：

存量设备的过渡方案

如果现场已有大量设备在跑、固件无法立刻更新，可以采用网关侧统一认证：由网关完成设备身份校验，网关自身使用安全芯片与云端建立 mTLS。

这个方案的安全强度低于一机一密，但能以较低改造成本覆盖存量设备。理想路径仍然是逐步把认证能力下沉到每台设备——这也是安全芯片方案的核心价值所在。