基于MQTT的数据加密传输算法①

于振中,洪辉武,徐 国,朱丹青

1(江南大学 物联网工程学院,无锡 214122)

2(哈工大机器人(合肥)国际创新研究院,合肥 230601)

在设计工业机器人数据采集系统的时候,我们发现在物联网场景下,应用最多的数据传输协议便是MQTT (Message Queuing Telemetry Transport,消息队列遥测传输协议).MQTT是由IBM发布的一种基于发布/订阅(publish/subscribe)模式的轻量级通讯协议,由于规范简单,非常适合用于低性能和网络带宽有限的物联网领域.MQTT协议支持绝大部分平台以及编程语言[1],这也使得它的开发非常方便.但是MQTT协议有一个非常大的缺陷,它的数据传输默认是不加密的,数据的安全性得不到保障.

许多作者在物联网的数据安全传输方面已经做了大量的研究.巫钟兴和李辉提出了一种软硬件结合的数据加密传输方案[2],这种方案需要使用硬件加密卡,大大增加了数据的传输成本.刘文浩和许春香提出了一种无双线性对的无证书两方密钥协商方案[3],该方案基于无证书密码体制,规避了证书管理需要占用大量资源的缺点,但仍需要第三方密钥生成中心(KGC)为通信双方生成部分私钥.Raza等人提出了一种适合在物联网场景使用的轻量级安全传输协议Lithe[4],该协议集成了DTLS (Datagram Transport Layer Security)和CoAP (Constrained Application Protocol),使用 DTLS 作为身份验证机密通信的底层协议,并且使用6LoWPA标准来降低传输过程的能耗.Lesjak等人设计了一套基于硬件的TLS客户端系统来保证MQTT协议的安全性[5],这种方法同样存在成本与证书管理的问题.Sainandan Bayya Venkata和Prabhakara Yellai等人提出了一种新的轻量级传输方法LWTM (Light Weight Transport Method)[6].LWTM算法分为控制平面和数据平面,控制平面传输物联网设备与服务器之间交换密钥生成参数、加密数据块在消息中的位置、加密数据块的大小等信息,使用安全传输通道TLS或DTLS.数据根据加密块的大小和加密块的位置进行加密,并且通过TCP/UDP等不安全传输发送,服务器通过使用相同的参数解密部分加密的数据.LWTM通过数据部分加密的策略,加快了加解密效率并且能够节省CPU计算资源.高锐强,朱虹的研究证明了通过TLS/SSL协议实现数据传输安全不可避免地会造成性能的损失[7].

1 MQTT-EA算法

上文提到的方法存在成本高、资源消耗大、实现复杂等一些问题,因此难以在我们的工业机器人数据采集系统中应用.为了更好地满足数据采集系统的需要,我们在MQTT协议的基础上,自行设计了一种加密改进算法MQTT-EA,该算法有以下一些优点:(1)该算法不需要额外的硬件支持、实现简单、成本更低;(2)该算法是一种无证书协商算法,不需要进行证书管理,可以减少网络资源的浪费;(3)该算法不需要依赖于任何第三方,降低了私钥泄露的风险;(4)该算法是基于MQTT协议而不是CoAP协议,能够更好地支持多对多的通信;(5)该算法是基于MQTT技术设计的,由于MQTT技术已经非常成熟,在各种编程语言中都有很好的支持,在使用该算法进行项目开发的时候,我们只要修改mqttv3 jar包以及Apollo服务器部份源码,便能实现对MQTT-EA的支持,这样能大大减少项目的工作量,减少开发成本.

1.1 设计需求分析

作为物联网中使用最广泛的通信协议,MQTT本身并没有提供数据加密的功能.但大多数的物联网场景都对数据的安全性有很高的要求.直接使用MQTT协议进行数据传输具有以下风险:

(1)窃听风险(eavesdropping):第三方可以通过监听的手段轻易获知通信内容.

(2)篡改风险(tampering):第三方可以修改通信内容.

(3)冒充风险(pretending):第三方可以冒充他人身份参与通信.

为了弥补MQTT协议安全性的不足,保障物联网设备的数据安全,我们的改进算法必须具备以下特性:

(1)所有数据都进行加密传输,防止第三方进行数据窃取.

(2)具有校验机制,接收端能够校验数据是否被篡改.

(3)具有身份验证机制,防止第三方冒充我方设备.

1.2 安全策略

针对上文提出的MQTT协议的安全风险,MQTTEA在数据传输中采用了以下的安全策略:

(1)黑白名单策略:只有白名单中的设备才能够与服务器建立连接,黑名单中的设备禁止与服务器连接.

(2)格式验证策略:设备端的数据必须按规定的格式存储,如{rpm:1000,temperature:59,angle:30}.SERVER端将接收到的加密数据解密后,首先对数据进行格式验证,只有格式验证通过的数据才会被保存.

(3)将最终会话生成密钥算法写入我们的设备及服务器,最终会话密钥在客户端和服务器直接生成,不在会话过程中出现,这样就能保证最终会话密钥不会被破解.

(4)强制中断连接:在任意阶段只要发送了不符合要求的控制报文或者是验证未通过,连接将会被强制中断.

(5)数据加密传输:所有的数据均通过DES加密后进行传输,这样即使数据包被他人截获也不会造成数据泄露.

以上的安全策略的目的主要有两点,一是加密数据,并保证解密密钥不被破解,二是实现敌我设备的认证.在这些安全策略中,加密数据的安全依赖于最终会话密钥生成算法不被破解,设备认证则是通过设备号+白名单+数据格式认证的组合认证策略来实现的.

1.3 加密传输过程

MQTT-EA的密钥协商是在MQTT建立连接的同时进行的,流程如图1所示,具体步骤为:

Step 1.由CLIENT端向SERVER端发送一个CONNECT+deviceID控制报文.SERVER端在接收到报文后会对其中的deviceID进行验证,只有在白名单中的设备才能进行下一步操作.在CLIENT端与SERVER端成功连接后,SERVER随机生成ServerKey.

图1 MQTT-EA流程图

Step 2.SERVER 端向 CLIENT 端发送一个 CONNECK+ServerKey控制报文,CLIENT端在接收到报文后将ServerKey提取出来存储到本地,同时随机生成ClientKey.

Step 3.在CLIENT第一次进行PUBLISH时,将自己的ClientKey发送到SERVER端.SERVER端将已知的ServerKey和ClientKey作为变量,利用自定义的秘钥生成算法f (ServerKey,ClientKey)获得会话主密钥SessionKey.

Step 4.SERVER 端向 CLIENT 端发送一个 PUBCOMP控制报文,表示数据传输前的密钥生成工作已经完成.CLIENT端在接收到该报文后通过相同的密钥生成算法f (ServerKey,ClientKey)获得会话主密钥SessionKey.至此,CLIENT端与SERVER端的连接成功建立,可以进行数据的传输.

Step 5.CLIENT端使用SessionKey对固定格式的数据进行DES加密,然后再将加密后的数据PUBLISH到SERVER端.

Step 6.SERVER端通过相同的SessionKey对接收到的加密数据进行DES解密,之后对解密后的数据进行格式验证,验证通过则将解密后的数据写到云端或者进行本地存储.否者将舍弃该数据并将CLIENT的ID列入黑名单.

之后的数据传输过程重复Step 5和Step 6即可.若是由于网络故障或者验证未通过等原因导致连接中断,则需要从Step 1重新开始连接.

2 源码修改

为了使mqttv3 jar包和apache apollo 1.7.1服务器支持MQTT-EA的开发,需要对客户端mqttv3 jar包以及部署在服务器的apache apollo 1.7.1源码进行改写,部分改写如下:

(1)在源码MqttConnect类中加入deviceID变量.相应地服务器源码的解析类里面也需要添加白名单列表和对deviceID变量的解析方法.

(2)在建立连接的时候服务器需要产生一个随机的ServerKey,因此需要在服务器相关类中加入生成ServerKey的方法.

(3)服务器向Client返回CONNACK+ ServerKey控制报文.相应地需要对mqttv3 jar包里面的CONNACK报文接收方法进行改写,使其能够接收新的CONNACK+ServerKey控制报文.

(4)需要在服务器配置好获取会话主密钥Session Key的算法函数f (ClientKey,ServerKey).

源码修改完成便能进行项目的开发了mqttv3 jar包以及apache apollo 1.7.1服务器对MQTT-EA的支持,能让项目的开发更加方便、高效.

3 安全性分析

在我们的数据采集系统中,可能受到的攻击有两种:(1)敌手伪装成我们的设备,向服务器发送虚假数据.(2)敌手监听我们设备与服务器的会话,窃取我们的设备数据.我们将模拟系统遭受到这两种攻击的过程,验证系统的安全性.

假设有敌手A,A能将自己的设备号device-A加到白名单,并且能够监听CLIENT端和SERVER端通信的任意阶段,但是A不知道最终密钥的生成算法.A的目的是伪装成正常的设备向服务器发送虚假信息.A的攻击过程如下:

(1)A向SERVER端发送一个CONNECT+device-A控制报文,设备验证通过,SERVER生成(ServerKey)A.

(2)SERVER端向A发送一个CONNECK+(ServerKey)A控制报文,A保存(ServerKey)A并生成(ClientKey)A.

(3)A将(ClientKey)APUBLISH到SERVER端,SERVER端生成(SessionKey)A.

(4)SERVER端向A发送一个PUBCOMP控制报文.A在接收到该报文后生成错误的会话密钥(SessionKey)WRONG.

(5)A使用(SessionKey)WRONG对需要传输的数据DES加密得到DES{DATA,(SessionKey)WRONG},然后再将DES{DATA,(SessionKey)WRONG} PUBLISH到SERVER端.

(6)SERVER端使用(SessionKey)A对DES {DATA,(SessionKey)WRONG}解密后得到(DATA)WRONG.SERVER端对数据进行格式验证,验证失败.SERVER端舍弃该数据,强制断开与A的连接,并将设备号device-A加入黑名单.

敌手A的攻击失败.

假设有敌手B,B同样能够监听CLIENT端和SERVER端通信的任意阶段,但是B不知道最终密钥的生成算法.B的目的是通过监听正常设备C与SERVER的会话获取我们的设备数据.B的攻击过程如下:

(1)B通过监听会话过程中的Step 2截获SERVER端向C发送的CONNECK+(ServerKey)C控制报文,并从中提取出(ServerKey)C.

(2)B通过监听会话过程中的Step 3截获C向SERVER端发送的PUBLISH控制报文,并从中提取出(ClientKey)C.

(3)由于该次会话的SessionKey从来没有在会话中出现过,且B不知道会话密钥的生成算法,所以B只能获得错误的会话密钥(SessionKey)WRONG1.

(4)B 通过监听会话过程中的 Step 5截获 C 向 SERVER端发送的加密数据包DES{DATA,(SessionKey)C}.

(5)B使用(SessionKey)WRONG1对加密数据包DES{DATA,(SessionKey)C}解密,解密失败.

敌手B攻击失败.

由以上分析可知,在假设敌手不知道我们的最终会话密钥生成算法的假设下,MQTT-EA可以满足我们对数据传输安全性的需求.

4 传输性能提高

MQTT协议基于传统的Publisher-Broker-Subscriber模式,数据由发布者传递到订阅者需要代理服务器作为中转,经过了两次传输过程,不仅增大了被窃听的风险而且降低了数据的传输效率.本文中设计的MQTTEA不再基于传统的Publisher-Broker- Subscriber模式,而使用了Client-Server模式.在这种模式下,客户端与服务器在成功建立连接后,直接将加密数据发送到服务器,只需一次传输过程便可以实现数据的传递.理论上,采用MQTT-EA算法加密后MQTT的传输效率应该优于原始MQTT协议.

我们设计了一个简单的实验以验证使用MQTTEA算法改进后的MQTT协议的传输效率高于原始MQTT协议.对象一:HRG工业机器人A使用MQTT协议向代理服务器发布一定量数据包,再由HRG机器人云平台A订阅这些数据包并存储.对象二:HRG工业机器人B使用MQTT-EA改进的MQTT协议直接向HRG机器人云平台B发送等量数据包,云平台B接收后将数据包解密并存储.分别对对象一和对象二多次实验记录下消耗的时间,通过对比两者传输相同数据包的平均用时,我们便能知道它们的效率高低.实验参数如表1所示.

表1 实验的一些关键参数

实验结果如图2所示,在硬件及网络条件相同的情况下,使用MQTT-EA改进的MQTT数据传输相同数量的数据包所花费的时间小于MQTT协议,这说明使用MQTT-EA改进MQTT协议在保证数据安全性的同时,还提高了它的数据传输性能.

图2 两种协议传输相同数量数据包耗时对比

5 总结与展望

本文根据工业机器人数据采集系统中数据传输的安全性需求,在MQTT的基础上提出了MQTT的加密算法MQTT-EA.该算法实现简单、传输效率高,且具有不需要额外的硬件支持,不需要证书管理,不需要第三方KGC参与私钥生成,开发效率高等一系列优点.由此可见,MQTT-EA算法具有较高的实用价值,可以在物联网的数据传输中推广使用.