searchusermenu
  • 发布文章
  • 消息中心
点赞
收藏
评论
分享
原创

iot设备通信安全相关调研

2024-12-11 08:57:55
0
0
以性能、安全为先:MQTT + 证书鉴权 +TLS加密 + 一机一密
以开发效率、成本为先:HTTP + 用户名/密码 + TLS加密 + 一型一密
其他基于安全效率平衡的考虑:HTTPS + 用户名/密码 + 一机一密
 
当前业务现状:
  1. 多家智能抓拍机公司并存,提交数据方式以http为主;
  2. 项目初期阶段,快速接入;
  3. 产品半年预期500家门店,需支持接入方自助接入;
 
鉴权方式:
      目前主流的http接口鉴权方式分为3种:1.基于base64编码的HTTP基本编码 2. 基于签名认证思想的鉴权 3. 基于OAUTH2.0的鉴权。 各种方案的优劣比对如下表
 
http基本编码/摘要验证
签名认证
oauth
性能
安全
适用范围
私有系统中可信网络环境
公网环境
公网环境
缺点
容易被拦截
明文秘钥暴露后,对系统危害大,危害范围广
接入方需要针对平台做sdk整合
需要在每个服务中做解析和签名生成,只能模块级重用
客户端如频繁申请token容易被截获,并且token泄露后果相对严重(在token过期之前,黑客可改变input参数进行重放)
每次请求都要与比对服务做一次交互,接入总qps限制整体团队项目
优点
实现简单
协议人眼可读,便于诊断
每一个请求都得到鉴权
可以防止秘钥泄露,并且利用timestamp过期可以防止请求重放
多个服务间共享,并且鉴权集中管理,可以实现服务及的重用
由于方案1不适用于公网环境,不予考虑。
方案2:
  1. 设备客户端在平台获取全局唯一id & secretCode;
  2. 客户端将请求中的通用信息+当前时间戳+随机字串和scretCode拼接后进行sha256/sha1/md5计算得到sign
  3. 客户端对服务端发起请求,在head中携带该sign
  4. 服务端根据参数中的id获取secretCode,计算出sign进行比对,如果sign相同,且时间戳在过期时间内,则鉴权成功。
 
方案3:
  1. 设备客户端在平台获取全局唯一id & secretCode;
  2. 客户端利用请求中的通用信息+当前时间戳+随机字串和scretCode拼接后进行sha256/sha1/md5计算得到sign
  3. 客户端对服务端auth服务发起请求,在header中携带该sign,获取一个有过期时间的token(一段时间内只需调用一次);
  4. 客户端利用该token调用上行接口,服务端auth进行比对,若对应id的token正确且未过期,则鉴权成功。
 
目前在设备数量较少(低于500),且希望通过服务方式提供iot设备的鉴权,初步设计使用方案3,单一服务(单一域名)提供id、secret生成、token生成以及token验证的服务。
 
背景:
因为是设备(摄像头)通过公网环境与IDC通信,因此需要对以下方面进行设计:
  1. 数据安全(加密)
  2. 身份验证(鉴权)
  3. 风险接口隔离
  4. 监控,限流与限速
 
物联网常用通信协议:
会话层协议:MQTT  COAP  DDS  XMPP  AMQP  HTTP  FTP  Telnet  SSH
网络/传输层协议:IPv4  IPv6  6LoWPAN  RPL
数据链路层协议
      近距离:Dash7 NFC Bluetooth/BTLE NFC RFID IRdA
      远距离蜂窝:GSM CDMA WiMax LTE NB-IoT
      远距离非蜂窝:Weightless ZigBee Z-Wave Insteon Neul wHART ANT/ANT+  802.15.4e WiFi EnOcean RFMesh 
 
物联网中通信主要链路包括:“设备-设备”、“设备-用户应用”、“设备-云”、“用户应用-云”
 
各云厂商IOT通信协议以及数据安全方案、身份验证方案对比一览:
物联网平台
通信协议(设备->云)
通信安全(设备->云)
身份认证(设备-> 云)
百度物接入IOT HUB
MQTT
TCP:端口1883,不支持传输数据加密,可以通过MQTT.fx客户端连接。
SSL:端口1884,支持SSL/TLS加密传输,MQTT.fx客户端连接
WSS:端口8884,支持WebSocket浏览器方式连接,同样包含SSL加密
双向安全连接、SSL传输
设备级认证、策略授权;
ali物联网套件
MQTT、CoAP、HTTPS
支持TLS(MQTT\HTTP)、DTLS(CoAP)数据传输通道,保证数据的机密性和完整性,适用于硬件资源充足、对功耗不是很敏感的设备。安全级别高。
支持TCP(MQTT)、UDP(CoAP)上自定义数据对称加密通道,适用于资源受限、功耗敏感的设备。安全级别普通。
支持设备权限管理机制,保障设备与云端安全通信。
支持设备级别的通信资源(TOPIC等)隔离,防止设备越权等问题。
提供芯片级安全存储方案(ID²)及设备秘钥安全管理机制,防止设备密钥被破解。安全级别很高。
提供一机一密的设备认证机制,降低设备被攻破的安全风险,适合有能力批量预分配ID密钥烧入到每个芯片的设备。安全级别高。
提供一型一密的设备预烧,认证时动态获取三元组,适合批量生产时无法将三元组烧入每个设备的情况。安全级别普通。
tx物联网通信
 MQTT 基于 TCP 和 TLS 加密接入,主流的物联通信协议,适用于设备间消息通信,或需要收取反向控制信令、配置场景。
CoAP 基于 UDP 和 DTLS 加密接入,适用于设备纯数据上报场景,对资源的消耗和要求更低。
MQTT 基于 WebSocket 接入,适用于浏览器类应用与物联网通信平台建立连接与通信能力。
http 接入,接入协议门槛低,适用低功耗、短连接的数据上报场景。(实际在官网的设备接入中,只有MQTT与CoAP2协议的接入说明,待求证)
基于 TLS、DTLS 协议进行客户端和服务器端的双向鉴权、数据加密传输,防范非法接入和数据窃取、篡改等风险。介于设备资源和使用场景的多样性,支持选择非对称(设备证书加密验证、适用高安全要求场景)和对称加密(密钥加密验证、适用资源受限设备)方式。
设备级粒度身份认证,保证云到设备和设备到云的消息的保密性。
AWS iot hub
 MQTT、HTTP 或 WebSockets。AWS IoT Core 也支持其他行业标准和自定义协议,而且即使设备使用不同的协议,也可以相互通信。
TLS(注册CA证书)
1、使用CA证书对产品证书认证 
2、使用产品证书认证 
3、使用私匙签名 
4、交换AES对称加密密匙 
5、通信
AWS IoT 在所有连接点处提供相互身份验证和加密。AWS IoT 支持 AWS 身份验证方法(称为"SigV4")以及基于身份验证的 X.509 证书。使用 HTTP 的连接可以使用任一方法,使用 MQTT 的连接可以使用基于证书的身份验证,使用 WebSockets 的连接可以使用 SigV4。
使用 AWS IoT 生成的证书以及由首选证书颁发机构 (CA) 签署的证书,将所选的角色和/或策略映射到每个证书,以便授予设备或应用程序访问权限,或撤消访问权限。
通过控制台或使用 API 创建、部署并管理设备的证书和策略。这些设备证书可以预配置、激活和与使用 AWS IAM 配置的相关策略关联。
AWS IoT 还支持用户移动应用使用 Amazon Cognito 进行连接,Amazon Cognito 将负责执行必要的操作来为应用用户创建唯一标识符并获取临时的、权限受限的 AWS 凭证。
IBM Watson IOT
MQTT与HTTP
提供了针对通过 TLS (V1.2) 的连接的完全支持。
设备通过只有用户知道的 clientId 和认证令牌的唯一组合进行连接。
AZURE IOT
MQTT、AMQP 和 HTTP
TLS·
每个设备设置独有的安全密钥,IoT 中心标识注册表会存储设备标识和密钥,后端可将个别设备加入允许列表或方块列表,以便完全控制设备访问权限。
 
从上表可以得出以下结论:
  1. 通信协议以MQTT为行业既定标准,除百度和腾讯外也支持HTTP协议
  2. 安全统一使用TLS协议
  3. 鉴权方法则种类较多,从算法上区分有用户名+密码与使用证书,从策略上有一机一密与一型一密。
协议名称
效率
灵活性
标准化
第三方接入成本
MQTT
吞吐量:93倍
发送数据电量消耗: 1/11
接收数据电量消耗:1/170
连接保持电量消耗:1/2
网络开销:1/8
支持服务质量配置
最多一次 (QoS0)
至少一次 (QoS1)
恰好一次 (QoS2)
 
IOT行业标准
普通
HTTPS
需业务逻辑实现重放策略
通用标准
 
鉴权算法
安全系数
计算资源成本
复杂度
第三方接入成本
用户名 + 密码
普通
普通
普通
证书
普通
 
鉴权策略
安全系数
复杂度
第三方接入成本
一机一密
一型一密
普通
普通
普通
 
具体鉴权算法流程,以ali iot,用户名+密码鉴权为例:
  1. 云控制台注册设备,获取 productKey,deviceName
  2. 设备端将步骤1中2个字串设置到设备中
  3. 设备端根据两者生成sign串调用auth接口生成token(48小时超时,只需调用1次)
  4. 设备调用HTTPS上行将生成的临时token塞到header内,以post方式将数据上传到云平台。(token超时更新)

 

 
0条评论
0 / 1000
范****平
4文章数
0粉丝数
范****平
4 文章 | 0 粉丝
原创

iot设备通信安全相关调研

2024-12-11 08:57:55
0
0
以性能、安全为先:MQTT + 证书鉴权 +TLS加密 + 一机一密
以开发效率、成本为先:HTTP + 用户名/密码 + TLS加密 + 一型一密
其他基于安全效率平衡的考虑:HTTPS + 用户名/密码 + 一机一密
 
当前业务现状:
  1. 多家智能抓拍机公司并存,提交数据方式以http为主;
  2. 项目初期阶段,快速接入;
  3. 产品半年预期500家门店,需支持接入方自助接入;
 
鉴权方式:
      目前主流的http接口鉴权方式分为3种:1.基于base64编码的HTTP基本编码 2. 基于签名认证思想的鉴权 3. 基于OAUTH2.0的鉴权。 各种方案的优劣比对如下表
 
http基本编码/摘要验证
签名认证
oauth
性能
安全
适用范围
私有系统中可信网络环境
公网环境
公网环境
缺点
容易被拦截
明文秘钥暴露后,对系统危害大,危害范围广
接入方需要针对平台做sdk整合
需要在每个服务中做解析和签名生成,只能模块级重用
客户端如频繁申请token容易被截获,并且token泄露后果相对严重(在token过期之前,黑客可改变input参数进行重放)
每次请求都要与比对服务做一次交互,接入总qps限制整体团队项目
优点
实现简单
协议人眼可读,便于诊断
每一个请求都得到鉴权
可以防止秘钥泄露,并且利用timestamp过期可以防止请求重放
多个服务间共享,并且鉴权集中管理,可以实现服务及的重用
由于方案1不适用于公网环境,不予考虑。
方案2:
  1. 设备客户端在平台获取全局唯一id & secretCode;
  2. 客户端将请求中的通用信息+当前时间戳+随机字串和scretCode拼接后进行sha256/sha1/md5计算得到sign
  3. 客户端对服务端发起请求,在head中携带该sign
  4. 服务端根据参数中的id获取secretCode,计算出sign进行比对,如果sign相同,且时间戳在过期时间内,则鉴权成功。
 
方案3:
  1. 设备客户端在平台获取全局唯一id & secretCode;
  2. 客户端利用请求中的通用信息+当前时间戳+随机字串和scretCode拼接后进行sha256/sha1/md5计算得到sign
  3. 客户端对服务端auth服务发起请求,在header中携带该sign,获取一个有过期时间的token(一段时间内只需调用一次);
  4. 客户端利用该token调用上行接口,服务端auth进行比对,若对应id的token正确且未过期,则鉴权成功。
 
目前在设备数量较少(低于500),且希望通过服务方式提供iot设备的鉴权,初步设计使用方案3,单一服务(单一域名)提供id、secret生成、token生成以及token验证的服务。
 
背景:
因为是设备(摄像头)通过公网环境与IDC通信,因此需要对以下方面进行设计:
  1. 数据安全(加密)
  2. 身份验证(鉴权)
  3. 风险接口隔离
  4. 监控,限流与限速
 
物联网常用通信协议:
会话层协议:MQTT  COAP  DDS  XMPP  AMQP  HTTP  FTP  Telnet  SSH
网络/传输层协议:IPv4  IPv6  6LoWPAN  RPL
数据链路层协议
      近距离:Dash7 NFC Bluetooth/BTLE NFC RFID IRdA
      远距离蜂窝:GSM CDMA WiMax LTE NB-IoT
      远距离非蜂窝:Weightless ZigBee Z-Wave Insteon Neul wHART ANT/ANT+  802.15.4e WiFi EnOcean RFMesh 
 
物联网中通信主要链路包括:“设备-设备”、“设备-用户应用”、“设备-云”、“用户应用-云”
 
各云厂商IOT通信协议以及数据安全方案、身份验证方案对比一览:
物联网平台
通信协议(设备->云)
通信安全(设备->云)
身份认证(设备-> 云)
百度物接入IOT HUB
MQTT
TCP:端口1883,不支持传输数据加密,可以通过MQTT.fx客户端连接。
SSL:端口1884,支持SSL/TLS加密传输,MQTT.fx客户端连接
WSS:端口8884,支持WebSocket浏览器方式连接,同样包含SSL加密
双向安全连接、SSL传输
设备级认证、策略授权;
ali物联网套件
MQTT、CoAP、HTTPS
支持TLS(MQTT\HTTP)、DTLS(CoAP)数据传输通道,保证数据的机密性和完整性,适用于硬件资源充足、对功耗不是很敏感的设备。安全级别高。
支持TCP(MQTT)、UDP(CoAP)上自定义数据对称加密通道,适用于资源受限、功耗敏感的设备。安全级别普通。
支持设备权限管理机制,保障设备与云端安全通信。
支持设备级别的通信资源(TOPIC等)隔离,防止设备越权等问题。
提供芯片级安全存储方案(ID²)及设备秘钥安全管理机制,防止设备密钥被破解。安全级别很高。
提供一机一密的设备认证机制,降低设备被攻破的安全风险,适合有能力批量预分配ID密钥烧入到每个芯片的设备。安全级别高。
提供一型一密的设备预烧,认证时动态获取三元组,适合批量生产时无法将三元组烧入每个设备的情况。安全级别普通。
tx物联网通信
 MQTT 基于 TCP 和 TLS 加密接入,主流的物联通信协议,适用于设备间消息通信,或需要收取反向控制信令、配置场景。
CoAP 基于 UDP 和 DTLS 加密接入,适用于设备纯数据上报场景,对资源的消耗和要求更低。
MQTT 基于 WebSocket 接入,适用于浏览器类应用与物联网通信平台建立连接与通信能力。
http 接入,接入协议门槛低,适用低功耗、短连接的数据上报场景。(实际在官网的设备接入中,只有MQTT与CoAP2协议的接入说明,待求证)
基于 TLS、DTLS 协议进行客户端和服务器端的双向鉴权、数据加密传输,防范非法接入和数据窃取、篡改等风险。介于设备资源和使用场景的多样性,支持选择非对称(设备证书加密验证、适用高安全要求场景)和对称加密(密钥加密验证、适用资源受限设备)方式。
设备级粒度身份认证,保证云到设备和设备到云的消息的保密性。
AWS iot hub
 MQTT、HTTP 或 WebSockets。AWS IoT Core 也支持其他行业标准和自定义协议,而且即使设备使用不同的协议,也可以相互通信。
TLS(注册CA证书)
1、使用CA证书对产品证书认证 
2、使用产品证书认证 
3、使用私匙签名 
4、交换AES对称加密密匙 
5、通信
AWS IoT 在所有连接点处提供相互身份验证和加密。AWS IoT 支持 AWS 身份验证方法(称为"SigV4")以及基于身份验证的 X.509 证书。使用 HTTP 的连接可以使用任一方法,使用 MQTT 的连接可以使用基于证书的身份验证,使用 WebSockets 的连接可以使用 SigV4。
使用 AWS IoT 生成的证书以及由首选证书颁发机构 (CA) 签署的证书,将所选的角色和/或策略映射到每个证书,以便授予设备或应用程序访问权限,或撤消访问权限。
通过控制台或使用 API 创建、部署并管理设备的证书和策略。这些设备证书可以预配置、激活和与使用 AWS IAM 配置的相关策略关联。
AWS IoT 还支持用户移动应用使用 Amazon Cognito 进行连接,Amazon Cognito 将负责执行必要的操作来为应用用户创建唯一标识符并获取临时的、权限受限的 AWS 凭证。
IBM Watson IOT
MQTT与HTTP
提供了针对通过 TLS (V1.2) 的连接的完全支持。
设备通过只有用户知道的 clientId 和认证令牌的唯一组合进行连接。
AZURE IOT
MQTT、AMQP 和 HTTP
TLS·
每个设备设置独有的安全密钥,IoT 中心标识注册表会存储设备标识和密钥,后端可将个别设备加入允许列表或方块列表,以便完全控制设备访问权限。
 
从上表可以得出以下结论:
  1. 通信协议以MQTT为行业既定标准,除百度和腾讯外也支持HTTP协议
  2. 安全统一使用TLS协议
  3. 鉴权方法则种类较多,从算法上区分有用户名+密码与使用证书,从策略上有一机一密与一型一密。
协议名称
效率
灵活性
标准化
第三方接入成本
MQTT
吞吐量:93倍
发送数据电量消耗: 1/11
接收数据电量消耗:1/170
连接保持电量消耗:1/2
网络开销:1/8
支持服务质量配置
最多一次 (QoS0)
至少一次 (QoS1)
恰好一次 (QoS2)
 
IOT行业标准
普通
HTTPS
需业务逻辑实现重放策略
通用标准
 
鉴权算法
安全系数
计算资源成本
复杂度
第三方接入成本
用户名 + 密码
普通
普通
普通
证书
普通
 
鉴权策略
安全系数
复杂度
第三方接入成本
一机一密
一型一密
普通
普通
普通
 
具体鉴权算法流程,以ali iot,用户名+密码鉴权为例:
  1. 云控制台注册设备,获取 productKey,deviceName
  2. 设备端将步骤1中2个字串设置到设备中
  3. 设备端根据两者生成sign串调用auth接口生成token(48小时超时,只需调用1次)
  4. 设备调用HTTPS上行将生成的临时token塞到header内,以post方式将数据上传到云平台。(token超时更新)

 

 
文章来自个人专栏
开发实录
4 文章 | 1 订阅
0条评论
0 / 1000
请输入你的评论
0
0