在设计工业机器人数据采集系统的时候, 我们发现在物联网场景下, 应用最多的数据传输协议便是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协议的安全风险, MQTT-EA在数据传输中采用了以下的安全策略:

(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.

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

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

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

5 总结与展望

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