以性能、安全为先:MQTT + 证书鉴权 +TLS加密 + 一机一密
以开发效率、成本为先:HTTP + 用户名/密码 + TLS加密 + 一型一密
其他基于安全效率平衡的考虑:HTTPS + 用户名/密码 + 一机一密
当前业务现状:
-
多家智能抓拍机公司并存,提交数据方式以http为主;
-
项目初期阶段,快速接入;
-
产品半年预期500家门店,需支持接入方自助接入;
鉴权方式:
目前主流的http接口鉴权方式分为3种:1.基于base64编码的HTTP基本编码 2. 基于签名认证思想的鉴权 3. 基于OAUTH2.0的鉴权。 各种方案的优劣比对如下表
http基本编码/摘要验证
|
签名认证
|
oauth
|
|
性能
|
高
|
中
|
低
|
安全
|
低
|
高
|
中
|
适用范围
|
私有系统中可信网络环境
|
公网环境
|
公网环境
|
缺点
|
容易被拦截
明文秘钥暴露后,对系统危害大,危害范围广
|
接入方需要针对平台做sdk整合
需要在每个服务中做解析和签名生成,只能模块级重用
|
客户端如频繁申请token容易被截获,并且token泄露后果相对严重(在token过期之前,黑客可改变input参数进行重放)
每次请求都要与比对服务做一次交互,接入总qps限制整体团队项目
|
优点
|
实现简单
协议人眼可读,便于诊断
|
每一个请求都得到鉴权
可以防止秘钥泄露,并且利用timestamp过期可以防止请求重放
|
多个服务间共享,并且鉴权集中管理,可以实现服务及的重用
|
由于方案1不适用于公网环境,不予考虑。
方案2:
-
设备客户端在平台获取全局唯一id & secretCode;
-
客户端将请求中的通用信息+当前时间戳+随机字串和scretCode拼接后进行sha256/sha1/md5计算得到sign
-
客户端对服务端发起请求,在head中携带该sign
-
服务端根据参数中的id获取secretCode,计算出sign进行比对,如果sign相同,且时间戳在过期时间内,则鉴权成功。
方案3:
-
设备客户端在平台获取全局唯一id & secretCode;
-
客户端利用请求中的通用信息+当前时间戳+随机字串和scretCode拼接后进行sha256/sha1/md5计算得到sign
-
客户端对服务端auth服务发起请求,在header中携带该sign,获取一个有过期时间的token(一段时间内只需调用一次);
-
客户端利用该token调用上行接口,服务端auth进行比对,若对应id的token正确且未过期,则鉴权成功。
目前在设备数量较少(低于500),且希望通过服务方式提供iot设备的鉴权,初步设计使用方案3,单一服务(单一域名)提供id、secret生成、token生成以及token验证的服务。
背景:
因为是设备(摄像头)通过公网环境与IDC通信,因此需要对以下方面进行设计:
-
数据安全(加密)
-
身份验证(鉴权)
-
风险接口隔离
-
监控,限流与限速
物联网常用通信协议:
会话层协议: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 中心标识注册表会存储设备标识和密钥,后端可将个别设备加入允许列表或方块列表,以便完全控制设备访问权限。
|
从上表可以得出以下结论:
-
通信协议以MQTT为行业既定标准,除百度和腾讯外也支持HTTP协议
-
安全统一使用TLS协议
-
鉴权方法则种类较多,从算法上区分有用户名+密码与使用证书,从策略上有一机一密与一型一密。
协议名称
|
效率
|
灵活性
|
标准化
|
第三方接入成本
|
MQTT
|
高
吞吐量:93倍
发送数据电量消耗: 1/11
接收数据电量消耗:1/170
连接保持电量消耗:1/2
网络开销:1/8
|
支持服务质量配置
最多一次 (QoS0)
至少一次 (QoS1)
恰好一次 (QoS2)
|
IOT行业标准
|
普通
|
HTTPS
|
低
|
需业务逻辑实现重放策略
|
通用标准
|
低
|
鉴权算法
|
安全系数
|
计算资源成本
|
复杂度
|
第三方接入成本
|
用户名 + 密码
|
高
|
普通
|
普通
|
普通
|
证书
|
普通
|
高
|
高
|
高
|
鉴权策略
|
安全系数
|
复杂度
|
第三方接入成本
|
一机一密
|
高
|
高
|
高
|
一型一密
|
普通
|
普通
|
普通
|
具体鉴权算法流程,以ali iot,用户名+密码鉴权为例:
-
云控制台注册设备,获取 productKey,deviceName
-
设备端将步骤1中2个字串设置到设备中
-
设备端根据两者生成sign串调用auth接口生成token(48小时超时,只需调用1次)
-
设备调用HTTPS上行将生成的临时token塞到header内,以post方式将数据上传到云平台。(token超时更新)