当前位置: 首页 > news >正文

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

IOT 设备入网认证机制

  • 一、基于对称密钥(Pre-shared Key, PSK)
    • 1. 普通 PSK 一机一密(静态方式)
    • 2. PSK 一机一密(动态方式)
  • 二、基于 X.509 证书的双向 TLS(Mutual TLS / mTLS)
    • 1. 硬件安全加密芯片
  • 三、基于令牌机制(Token)
    • 1. 为什么要拆成认证服务器 + IoT 服务器
    • 2. 对比PSK动态方式
  • 四、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 和运营商核心网的匹配校验来确认设备身份。
    这种方式的特点是:安全等级高、认证机制成熟、难以被伪造或克隆,但灵活性和成本较高,且依赖运营商生态
http://www.dtcms.com/a/410123.html

相关文章:

  • 微信小程序学习(二)
  • 微信小程序里 uni.navigateTo 用的多了, 容易报错,
  • LabVIEW通知器实现一对多数据分发
  • LabVIEW 流量检测
  • 海豚一键做淘宝网站wordpress数字链接出现404
  • 测试转C++开发面经(华为OD)
  • 新版Pycharm添加导入anaconda的python解释器
  • java_error_in_pycharm64.hprof 文件解析:作用、风险与处理建议
  • 基于微信小程序的扶贫助农系统【2026最新】
  • 免费开源的企业建站系统电子商务平台内的自然人经营者
  • Selenium+python自动化1-环境搭建
  • 大模型实时响应,通话告别预加载!
  • 解决Flexbox布局中元素无法居中的常见问题
  • AI时代:呼叫中心的存续与呼叫中心软件的蝶变
  • 基于单片机的按摩椅系统的设计(论文+源码)
  • 什么网站建设wordpress 显示文章固定链接
  • 学做沪江网站要多久广告设计培训班学校有哪些
  • pandas 基础:pandas.DataFrame.apply
  • uni-app 自定义 Android 插件详解
  • Spring IOC源码篇五 核心方法obtainFreshBeanFactory.doLoadBeanDefinitions
  • kafka和rocketmq的副本机制区别: isr 主从模式,Dledger模式
  • HTTP的持续与非持续连接,HTTP报文格式
  • 删除Notepad++关于弹窗的反动字样
  • angular2是做网站的还是手机的网站开发大概价格
  • 国内专业做悬赏的网站绵阳网站建设设计
  • 抗辐照MCU芯片在核工业水下探测耐辐照数字摄像机中的应用研究
  • 《测试视角下的软件工程:需求、开发模型与测试模型》
  • 电子证照系统国产化改造实践:从MongoDB到金仓数据库的平滑迁移与性能优化
  • 开源的容器化平台:Docker
  • 【Prompt学习技能树地图】思维链(CoT)提示技术工作原理、主要技术方法及实践应用