【网络协议】IoT 设备入网认证机制

IOT 设备入网认证机制

• [一、基于对称密钥（Pre-shared Key, PSK）](#一、基于对称密钥（Pre-shared Key, PSK）)
• • [1. 普通 PSK 一机一密（静态方式）](#1. 普通 PSK 一机一密（静态方式）)
  • [2. PSK 一机一密（动态方式）](#2. PSK 一机一密（动态方式）)
• [二、基于 X.509 证书的双向 TLS（Mutual TLS / mTLS）](#二、基于 X.509 证书的双向 TLS（Mutual TLS / mTLS）)
• • [1. 硬件安全加密芯片](#1. 硬件安全加密芯片)
• 三、基于令牌机制（Token）
• • [1. 为什么要拆成认证服务器 + IoT 服务器](#1. 为什么要拆成认证服务器 + IoT 服务器)
  • [2. 对比PSK动态方式](#2. 对比PSK动态方式)
• [四、SIM/eSIM/IoT SIM 认证（基于运营商）](#四、SIM/eSIM/IoT SIM 认证（基于运营商）)

在 IoT 设备与云端建立安全连接时，核心目标是确保设备的真实身份，防止伪造设备接入或数据被篡改。

常见的身份验证方案主要有以下几类：

一、基于对称密钥（Pre-shared Key, PSK）

这是最简单的方式，尤其适用于资源受限的设备。

工作原理：在每个设备出厂时，将一个唯一的密钥（如密码、API Key）烧录到设备的安全存储中。设备连接云端时，通过该密钥来证明自己的身份。这通常与TLS/SSL连接结合使用，密钥可能直接作为MQTT的密码，或用于生成访问令牌（如Token）。

1. 普通 PSK 一机一密（静态方式）

• 初始部署时：每台设备烧录一个唯一的预共享对称密钥（PSK），云端也保留一份。

• 认证过程：设备和云端在握手时直接用这个静态 PSK 导出会话密钥，用于后续通信加密。

• 特点

  • 简单、快速，但 PSK 长期不变。

  • 一旦密钥泄露 → 必须更新设备端和云端的密钥数据库，管理非常麻烦。

• 流程示意 ：
  设备 -> 连接请求（携带预置密钥） -> 云平台 -> 验证密钥合法性 -> 允许/拒绝连接

• 优点

  • 实现简单，资源消耗低。
  • 适合算力有限的低功耗设备。
  • 网络延迟与握手开销小。

• 缺点

  • 密钥需要在出厂或配置时分发，管理困难。
  • 一旦密钥泄露，难以更新（尤其批量设备）。
  • 不具备很好扩展性，适合小规模部署。

2. PSK 一机一密（动态方式）

这种方案是PSK的一种增强变体，由于静态方式中，PSK长期不变的，存在安全风险，在动态方式中，优化了这一点。

工作原理 ：设备在出厂时带有一个"根密钥"或"种子密钥"。设备首次连接时，使用这个根密钥通过一个安全的引导流程（如基于挑战-响应的认证）向云端证明身份。认证通过后，云端会动态生成一个临时的、作用域受限的密钥（如对称密钥或Token）下发给设备，用于后续的通信，设备的根密钥在此之后可以不再使用。

• 优点：

  • 比静态PSK更安全：根密钥仅在首次连接时使用，大部分时间设备使用临时密钥。即使临时密钥泄露，影响范围也有限，且可以通过让设备重新引导来更新。
  • 密钥轮换：支持定期或根据需要更换通信密钥，提升了安全性。
  • 适合批量生产：设备可以拥有相同的根密钥（虽然不推荐），通过唯一的设备标识符（如IMEI、SN）来区分。

• 缺点：

  • 引导过程复杂：需要设计一个安全可靠的引导协议。
  • 仍然依赖一个主密钥：根密钥的安全性依然是整个系统的单点故障。如果根密钥泄露，所有设备都会面临风险。
  • 实现复杂度介于PSK和证书之间。

二、基于 X.509 证书的双向 TLS（Mutual TLS / mTLS）

这是目前公认最安全，使用最广泛的方案，广泛应用于对安全性要求高的场景。

采用证书，每个设备都有了唯一的身份，服务器能够对各个设备访问权限做到精准控制。

工作原理 ：每个设备在出厂时被烧录一个唯一的设备证书 （包含公钥）和对应的私钥。私钥永远不离开设备。设备连接时，云端会要求设备用其私钥对一个随机挑战码进行签名，设备端签名后送回云端，云端用设备证书中的公钥验证签名。整个通信过程通常建立在双向TLS/SSL认证之上（mTLS）。

典型协议：MQTT over TLS/SSL（双向认证）

• 优点 ：
  • 极高的安全性：私钥不出设备，即使证书被窃取，攻击者也无法冒充设备。
  • 强大的身份鉴别 ：每个设备拥有独一无二的身份凭证，易于追溯和管理。
  • 完美的前向保密：如果与具备PFS的TLS密码套件结合，即使一个会话的密钥被破解，也不会影响其他会话的安全。
  • 自动化生命周期管理：证书可以设置有效期，并可以通过证书吊销列表（CRL）或在线证书状态协议（OCSP）方便地撤销某个设备的访问权限。
• 缺点 ：
  • 计算和存储开销大 ：非对称加密（如RSA、ECC）对设备的计算能力有较高要求，且证书和私钥需要一定的存储空间。不过，现在已有专为IoT设计的轻量级加密算法（如ECC）。
  • 实现复杂：需要部署PKI（公钥基础设施）来管理证书的签发、吊销和更新，增加了系统的复杂性。
  • 成本较高：对硬件有一定要求，且PKI的管理和维护需要投入。

1. 硬件安全加密芯片

在没有安全芯片的普通设备中，密钥和证书通常以文件形式存储在设备的闪存中。无论开发者如何加密隐藏，理论上，攻击者只要能够完全控制设备操作系统，就有可能通过逆向工程等手段提取出密钥。

"数字证书 + 安全芯片"是目前公认的安全等级最高的标准组合，能为设备身份认证提供最坚实的基础。

安全芯片通过硬件手段解决了这个问题：

1. 安全存储：将加密密钥、证书等敏感数据存储在芯片内部的一个受保护的隔离区域。这个区域无法通过常规的软件接口直接访问，即使设备的主处理器被攻破，攻击者也很难读取到原始密钥。

2. 安全执行 ：关键的加密运算（如数字签名、解密）在芯片内部完成。私钥永远不离开安全芯片 。当设备需要进行认证时（例如，在TLS握手过程中需要签名），主处理器将需要签名的数据发送给安全芯片，安全芯片在内部使用私钥完成签名，然后只把签名结果返回给主处理器。私钥本身在整个生命周期中都不会暴露在芯片之外。

   优点：

   • 极高的密钥保护：私钥不可提取，是最高级别的密钥存储方案。
   • 抵御物理攻击：能有效防止侧信道攻击、功耗分析、故障注入等物理攻击手段。
   • 增强的软件完整性：可用于验证设备固件的完整性，防止固件被恶意篡改。
   • 满足合规要求：对于医疗、金融、工业控制等强监管领域，使用安全芯片通常是满足安全合规性的必要条件。
   • 提供真正唯一的设备身份：芯片在制造时就被赋予了唯一性，无法克隆。

   缺点：

   • 成本增加：增加了硬件BOM成本和供应链复杂性。
   • 设计复杂性：需要在硬件设计和软件驱动层面进行集成，开发难度更高。
   • 潜在的性能瓶颈：加密运算可能在安全芯片内部完成，速度可能不如在主处理器上快（但对于物联网认证场景通常足够）。

三、基于令牌机制（Token）

这种方案常见于使用标准OAuth 2.0/OpenID Connect协议的物联网平台，设备被视作一个"客户端"。

工作原理 ：设备首先向云端的认证授权服务器 请求一个访问令牌（通常是JWT格式）。为了获取这个令牌，设备需要使用其凭证（如PSK或证书）进行认证。获取到JWT后，设备在后续请求中携带此令牌访问IoT服务器，验证通过后，即可和IoT服务器通信。

Token 认证的典型模式通常是：

1. 设备先找认证服务（Auth Server / Identity Server）
   • 设备用 根凭证（比如预置的设备证书、PSK、出厂分配的密钥）去和认证服务器交互。
   • 认证服务器验证设备身份是否合法。
2. 认证服务下发 Token（常见是 Access Token 或 Access+Refresh）
   • 认证服务会给设备颁发一个短期有效的 Token，并带上允许访问的资源范围（Scope）。
3. 设备用 Token 访问 IoT 业务服务（IoT Server / Resource Server）
   • 设备之后连接 MQTT Broker、HTTP API 服务、数据上报/订阅系统时，把 Token 带上，IoT 平台只校验 Token，不再校验根凭证。

1. 为什么要拆成认证服务器 + IoT 服务器

1. 分工清晰 ：
   • 认证服务器只负责身份验证和 Token 的颁发/吊销。
   • IoT 服务器专心处理数据传输、消息队列、指令下发。
2. 安全性提高 ：
   • 设备的长期凭证只在认证阶段用一次，之后都用 Token，避免凭证频繁暴露。
   • IoT 服务器不需要保存设备根凭证，只验签 Token，攻击面更小。
3. 可扩展性 ：
   • 不同业务系统都可以共用同一套认证中心。
   • 支持集中化的 Token 管理（过期、刷新、吊销）。

2. 对比PSK动态方式

维度	PSK 动态分配	Token 机制
目标	建立安全通信（加密 & 会话认证）	控制资源访问（身份认证 & 授权）
凭证形式	对称密钥（秘密值，存放在设备和云端）	令牌字符串（如 JWT，带签名可验证，不一定是秘密）
使用场景	作为传输协议的密钥（TLS/DTLS 加密用）	作为 API 请求头的凭证（HTTP、MQTT topic 权限控制）
生命周期	相对较长（会话级/设备周期性更新）	较短（分钟级或小时级）
更新机制	云端生成后下发给设备	云端颁发，客户端刷新或重取
依赖条件	需要初始信任根（证书/根密钥）	需要身份认证服务（IAM/Auth Server）
常见场景	IoT 设备到云平台的加密链路	用户/设备访问云 API、消息主题订阅权限验证

四、SIM/eSIM/IoT SIM 认证（基于运营商）

基于运营商网络的SIM/eSIM/IoT SIM认证，其核心机制可以概括为一次严密的"数字身份核查"。它依赖于存储在SIM卡芯片中的密钥和网络侧的认证中心相互配合，通过"挑战-应答"机制来确认设备的合法身份。

长期密钥（Ki） ：

每一张SIM/eSIM都内置了一个全球唯一的128位认证密钥（Ki），这个密钥在卡制造时写入，同时安全地存储在运营商网络的认证中心（AuC）里。至关重要的是，Ki在任何通信过程中都绝不会在网络上传输，从而避免了被截获的风险。

"挑战-应答"协议：

• 认证过程本质上是网络对设备的一次挑战。网络侧生成一个随机数（RAND）作为"挑战"发送给设备。设备中的SIM/eSIM芯片利用密钥Ki和特定的密码算法（如3G网络使用的Milenage算法）对这个随机数进行计算，生成一个响应值（SRES）和会话密钥（Kc）。网络侧也在本地进行同样的计算，并验证设备返回的SRES是否与自己计算出的预期值（XRES）一致。随机数的使用确保了每次认证过程都是独一无二的，有效防止重放攻击。

会话密钥与通信加密

认证成功后，双方会生成一个临时的会话密钥（Kc），用于对后续的通信数据进行加密，保障了空中接口传输的安全。

总结：

• SIM/eSIM/IoT SIM 的认证本质是依托于移动通信网络的 AKA 挑战-应答协议 ，依赖 SIM 卡内的不可导出密钥 Ki 和运营商核心网的匹配校验来确认设备身份。
  这种方式的特点是：安全等级高、认证机制成熟、难以被伪造或克隆，但灵活性和成本较高，且依赖运营商生态。