CN110855561A

CN110855561A - 一种物联网智能网关

Info

Publication number: CN110855561A
Application number: CN201911245380.4A
Authority: CN
Inventors: 赵小海
Original assignee: Shanghai Industrial Utechnology Research Institute
Current assignee: Shanghai Industrial Utechnology Research Institute
Priority date: 2019-12-07
Filing date: 2019-12-07
Publication date: 2020-02-28

Abstract

本发明提供一种管理设备的物联网智能网关，包括传感端、网关、云端和用户端；所述在传感端与云端之间设置可处理加密与解密运算的网关，降低传感端信息处理运算，保证传感端与云端之间信息交互通畅。所述在智能网关中设计场景规则，根据传感器状态自动触发场景，并上报告警信息和接受下行的控制命令。所述在智能网关中可根据场景需要选择https或者mqtt和云端通信。所述在智能网关中通过CA证书加密数据，保证数据传输安全。

Description

一种物联网智能网关

技术领域

本发明涉及一种物联网智能网关，尤其涉及一种在物联网中使用安全加密协议的智能网关。

背景技术

物联网(The Internet of Things，简称IOT)是指通过传感器实时采集任何需要监控、连接、互动的物体或过程，通过各类可能的网络接入，实现物与物、物与人的泛在连接，实现对物品和过程的智能化感知、识别和管理。物联网是一个基于互联网、传统电信网等的信息承载体，它让所有能够被独立寻址的普通物理对象形成互联互通的网络。

物联网的应用领域涉及到方方面面，在工业、农业、环境、交通、物流、安保等基础设施领域的应用，有效的推动了这些方面的智能化发展，使得有限的资源更加合理的使用分配，从而提高了行业效率、效益。

传统的互联网发展成熟、应用广泛，尚存在安全漏洞。物联网作为新兴产物，体系结构更复杂、没有统一标准，各方面的安全问题更加突出。信息安全，如今企业之间、国家之间合作都相当普遍,一旦网络遭到攻击,后果将更不敢想象。如何在使用物联网的过程做到信息化和安全化的平衡至关重要。

现有物联网网关，一端连接着传感器，另一端连接着信息控制和处理端(如云端)，此两端之间的信息交互均通过网关实现，安全的信息交互一般需要较为复杂的加密与解密技术，要求两端具备一定计算处理能力。现有技术中，传感器主要作为监测端，计算与处理能力较弱，难以满足较大规模的加密与解密运算处理。

发明内容

本发明提供一种物联网智能网关，在传感端与云端之间设置可处理加密与解密运算的网关，降低传感端信息处理运算，保证传感端与云端之间信息交互通畅。

本发明提供一种物联网智能网关，包括传感端、网关、云端和用户端；所述网关向所述云端发送第一信息，所述云端向所述网关发送第二信息；其特征在于，

所述第一信息包括传感端的状态信息、报警信息、场景触发信息和反馈信息；

所述第二信息包括传感控制信息；

所述第一信息通过包含ssl或tls的第一协议发送；

所述第二信息通过包含ssl或tls的第二协议发送；

所述第一信息和所述第二信息是字符串格式信息。

优选地，还包括；

所述字符串格式是JSON字符串格式。

优选地，所述第一协议是MQTT SSL。

优选地，所述第一协议是HTTPS。

优选地，所述第二协议是MQTT SSL。

优选地，所述第二协议是HTTPS。

附图说明

附图1是本发明物联网智能网关示意图。

具体实施方式

下面结合附图对本发明提供的物联网智能网关的具体实施方式做详细说明。

在附图中，为了描述方便，层和区域的尺寸比例并非实际比例。当层(或膜)被称为在另一层或衬底“上”时，它可以直接在另一层或衬底上，或者也可以存在中间层。此外，当一层被称为在另一层“下”时，它可以直接在下面，并且也可以存在一个或多个中间层。另外，当层被称为在两个层之间时，它可以是两个层之间的唯一层，或者也可以存在一个或多个中间层。相同的附图标记始终表示相同的元件。另外，当两个部件之间称为“连接”时，包括物理连接，除非说明书明确限定，此种物理连接包括但不限于电连接、接触连接、无线信号连接。

为解决物联网中传感端运算处理能力有限，无法达到安全的信息交互的问题，本发明提出一种物联网智能网关。

本发明提出一种物联网智能网关，如图1所示，包括传感端1、网关2、云端3和用户端4；所述网关2向所述云端3发送第一信息，所述云3端向所述网关2发送第二信息；其特征在于，

所述第一信息包括传感端1的状态信息、报警信息、场景触发信息和反馈信息，其中状态信息是传感端1对设计检测目标或场所内的设计目标检测指标信息，如工厂湿度、公租房内的烟雾浓度、办公室内的温度等；报警信息是传感端1对设计检测目标或场所内的设计目标检测指标超过预设阈值后的警告信息，如工厂湿度过高、公租房内的烟雾浓度过高、办公室内的温度过低或过高等发出的报警信息；场景触发信息是传感端1对设计检测目标或场所内的的设计目标检测指标发生变化所做针对安排信息，如工厂湿度过高应采取的降低湿度措施、公租房内烟雾浓度过高采取的人为或自动通风措施、办公室内温度过低或过高应采取的降温或加温措施；反馈信息是指传感端1对云端3下发的传感控制信息处理结果的反馈。

所述第二信息包括传感控制信息，包括控制指令，用以控制传感端1；

所述第一信息通过包含ssl或tls的第一协议发送；

所述第二信息通过包含ssl或tls的第二协议发送；

所述第一信息和所述第二信息是字符串格式信息。

在本实施例中，所述字符串格式是JSON字符串格式。

在本实施例中，所述第一协议是MQTT SSL。

在其他实施例中，所述第一协议是HTTPS。

在本实施例中，所述第二协议是MQTT SSL。

在其他实施例中，所述第二协议是HTTPS。

MQTT SSL和HTTPS均是使用ssl或tls安全传输机制的通讯协议，下面就本发明采用的MQTT SSL和HTTPS技术进行进一步阐述。

MQTT(Message Queuing Telemetry Transport，消息队列遥测传输)是IBM开发的一个即时通讯协议，因其是为计算能力有限、低宽带工作、可适应使用不可靠网络的远程传感器的特点，渐渐成为物联网最为可靠的传输技术。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器(比如通过Twitter让房屋联网)的通信协议。

本发明网关使用的MQTT SSL包括处理模块，用以加密形成第一信息和或解密信息形成第二信息；、传感模块，用于接收传感端1发送来的信息，经所述处理模块加密形成第一信息；云端模块，用以接收云端信息，经处理模块加密形成第二信息。

步骤1.设定MQTT处理模块

本发明根据MQTT协议规范设计对应的传感端和云端。

a)、提供传感端服务，处理传感端请求。

b)、云端服务，向其传输传感端的信息。

本发明可供选择的MQTT处理模块有Mosquitto、EMQTT、HiveMQ等

step 2.云端

云端模块作为MQTT subscribe client将从MQTT处理模块接收所述作为MQTTpublish client的传感端发送的经加密形成的第一信息。

step 3.传感端信息

传感端作为MQTT publish client将向MQTT处理模块传输信息，每个消息包含topic和传感端的状态信息、报警信息、场景触发信息和反馈信息，这些信息在本实施例中是JSON数据，在其他实施例中，是二进制信息。MQTT处理模块经过加密后，根据设定将向与该topic绑定的云端3转传输该信息。在本实施例中，这些信息经过加密后形成第一信息向云端3传输。

step 4.云端接收并做应对

云端3接收第一信息进行对应处理并向所述网关2发送第二信息。

以公租房为例，

申请人新建了1000套公租房，每套公租房面有温度控制***，不同季节需采用不同的温度：

申请人为每套公租房配置一颗的芯片，比如连接温度控制***的温度芯片。每颗温度芯片作为MQTT云端，订阅申请人发布的温度信息，比如:

subscribe/publicrenthouse/1sthouse/UpdateTemperature

以后申请人无需人工去调节公租房温度，只需要在办公室，控制手机端APP或网页控制***，发布MQTT消息就可以控制公租房温度。比如：

MQTT publish/publicrenthouse/1sthouse/UpdateTemperature "temperature:15"

那么1sthouse所在公租房的ESP32收到15摄氏度的请求后，将这个命令，传到温度控制***来控制公租房实际温度。

上面介绍了MQTT信息交互，下面就MQTT信息交互中的信息进行ssl或tls加密进行介绍。

MQTT自有CA证书授权中心(Certificate Center)，MQTT是证书签发机构，CA证书有两个重要属性，即：一、本身受信任，国际认可；二、给他受信任的申请对象签发证书。

MQTT处理模块生成请求文件Server.csr，该文件内容主要是Server.key、组织信息、个人信息。提交给CA，CA审核之后签发给Server证书即Server.crt。该证书包括签名和明文信息两部分，其中签名使用ca.key即ca的私钥加密，通过ca.pub也就是CA的公钥就能解密该签名信息。

其中有ssl单向和单向验证

单向SSL工作流程

(1)申请证书：MQTT处理模块生成请求文件Server.csr提交给CA

(2)审核：CA审核MQTT处理模块真实性

(3)签发证书：证书内容就是上面提到的全部内容。到这里已经完成了整个SSL应用的部署，后面的步骤是具体的SSL工作流。

(4)TCP请求：当云端1要和MQTT处理模块端通信，需要云端3发起一个TCP请求

(5)返回证书：Server接收到Client的请求后会将证书Server.crt发送给Client。

(6)验证证书：Client收到MQTT处理模块证书Server.crt之后会对证书的签名解密，因此要用到对应的公钥，也就是CA的公钥，CA的公钥在CA证书里可以找到，CA证书是提前安装在云端3的。解密签名之后就可以校验摘要信息，域名信息等正确性

(7)协商通信密钥：如果证书校验通过，Server和Client将进行秘钥协商，然后Server和Client通信过程会采用对称秘钥加密。

单向认证和双向认证是什么？

大多情况下，尤其是web站点大多是单向认证即云端3只校验传感端1真实性。双向认证在安全要求比较高的场景下需要双方都校验对方，两个过程极其类似，只是在Client认证完MQTT处理模块证书后，Client会将自己的证书client.crt传给MQTT处理模块，MQTT处理模块验证通过后然后开始秘钥协商。

使用脚本自签证书

将req_distingushed_name CN 192.168.10.253和192.168.10.26更改为自己的传感端1和云端3IP或者域名，如果云端3不提供CN，直接将云端3的该项目删除即可。

生成证书如下：

EMQ配置用户名密码授权

启用emq_auth_username插件:

./bin/emqttd_ctl plugins load emq_auth_username

EMQ配置单向SSL认证

listener.ssl.external.handshake_timeout＝15

listener.ssl.external.keyfile＝etc/certs/server/server.key

listener.ssl.external.certfile＝etc/certs/server/server.crt

EMQ配置双向SSL认证

##开启双向认证

listener.ssl.external.cacertfile＝etc/certs/ca/ca.crt

listener.ssl.external.verify＝verify_peer

listener.ssl.external.fail_if_no_peer_cert＝true

测试

Python写的基于Paho的双向认证测试脚本

下面介绍本发明使用的Https：

HTTPS(全称：Hypertext Transfer Protocol over Secure Socket Layer)，是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL

Https的作用

内容加密建立一个信息安全通道，来保证数据传输的安全；

身份认证确认网站的真实性

数据完整性防止内容被第三方冒充或者篡改

Https的劣势

对数据进行加解密决定了它比http慢

需要进行非对称的加解密，且需要三次握手。首次连接比较慢点，当然现在也有很多的优化。

出于安全考虑，浏览器不会在本地保存HTTPS缓存。实际上，只要在HTTP头中使用特定命令，HTTPS是可以缓存的。Firefox默认只在内存中缓存HTTPS。但是，只要头命令中有Cache-Control:Public，缓存就会被写到硬盘上。IE只要http头允许就可以缓存https内容，缓存策略与是否使用HTTPS协议无关。

HTTPS和HTTP的区别

https协议需要到CA申请证书。

http是超文本传输协议，信息是明文传输；https则是具有安全性的ssl加密传输协议。

http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

http默认使用80端口，https默认使用443端口

SSL与TLS

SSL(Secure Socket Layer，安全套接字层)

SSL为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取，当前为3.0版本。

SSL协议可分为两层：SSL记录协议(SSL Record Protocol)：它建立在可靠的传输协议(如TCP)之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。SSL握手协议(SSL Handshake Protocol)：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

TLS(Transport Layer Security，传输层安全协议)

用于两个应用程序之间提供保密性和数据完整性。

TLS 1.0是IETF(Internet Engineering Task Force，Internet工程任务组)制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本，可以理解为SSL3.1，它是写入了RFC的。该协议由两层组成：TLS记录协议(TLS Record)和TLS握手协议(TLSHandshake)。较低的层为TLS记录协议，位于某个可靠的传输协议(例如TCP)上面。

SSL/TLS协议作用：

认证用户和MQTT处理模块，确保数据发送到正确的客户机和MQTT处理模块；

加密数据以防止数据中途被窃取；

维护数据的完整性，确保数据在传输过程中不被改变。

TLS比SSL的优势

对于消息认证使用密钥散列法：TLS使用“消息认证代码的密钥散列法”(HMAC)，当记录在开放的网络(如因特网)上传送时，该代码确保记录不会被变更。SSLv3.0还提供键控消息认证，但HMAC比SSLv3.0使用的(消息认证代码)MAC功能更安全。

增强的伪随机功能(PRF)：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，则数据仍然是安全的。

改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上，这也比SSLv3.0更安全。

一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。

特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

SSL、TLS的需要经过握手过程，如下。

云端3首次发出请求

由于云端3(如浏览器)对一些加解密算法的支持程度不一样，但是在TLS协议传输过程中必须使用同一套加解密算法才能保证数据能够正常的加解密。在TLS握手阶段，云端3首先要告知传感端1，自己支持哪些加密算法，所以云端3需要将本地支持的加密套件(Cipher Suite)的列表传送给传感端1。除此之外，云端3还要产生一个随机数，这个随机数一方面需要在云端3保存，另一方面需要传送给传感端1，云端3的随机数需要跟传感端1产生的随机数结合起来产生后面要讲到的Master Secret。

云端3需要提供如下信息：

支持的协议版本，比如TLS 1.0版

一个云端3生成的随机数，稍后用于生成”对话密钥”

支持的加密方法，比如RSA公钥加密

支持的压缩方法

传感端1首次回应

传感端1在接收到云端3的Client Hello之后，传感端1需要确定加密协议的版本，以及加密的算法，然后也生成一个随机数，以及将自己的证书发送给云端3一并发送给云端3，这里的随机数是整个过程的第二个随机数。

传感端1需要提供的信息：

协议的版本

加密的算法

随机数

MQTT处理模块证书

云端3再次回应

云端3首先会对MQTT处理模块下发的证书进行验证，验证通过之后，则会继续下面的操作，云端3再次产生一个随机数(第三个随机数)，然后使用MQTT处理模块证书中的公钥进行加密，以及放一个ChangeCipherSpec消息即编码改变的消息，还有整个前面所有消息的hash值，进行MQTT处理模块验证，然后用新秘钥加密一段数据一并发送到MQTT处理模块，确保正式通信前无误。

云端3使用前面的两个随机数以及刚刚新生成的新随机数，使用与MQTT处理模块确定的加密算法，生成一个Session Secret。

ChangeCipherSpec

ChangeCipherSpec是一个独立的协议，体现在数据包中就是一个字节的数据，用于告知传感端1，云端3已经切换到之前协商好的加密套件(Cipher Suite)的状态，准备使用之前协商好的加密套件加密数据并传输了。

MQTT处理模块再次响应

传感端1在接收到云端3传过来的第三个随机数的加密数据之后，使用私钥对这段加密数据进行解密，并对数据进行验证，也会使用跟云端3同样的方式生成秘钥，一切准备好之后，也会给云端3发送一个ChangeCipherSpec，告知云端3已经切换到协商过的加密套件状态，准备使用加密套件和Session Secret加密数据了。之后，传感端1也会使用SessionSecret加密一段Finish消息发送给云端3，以验证之前通过握手建立起来的加解密通道是否成功。

后续云端3与MQTT处理模块间通信

确定秘钥之后，MQTT处理模块与云端3之间就会通过商定的秘钥加密消息进行通讯了。整个握手过程也就基本完成了。

需要说明的是：

SSL协议在握手阶段使用的是非对称加密，在传输阶段使用的是对称加密，也就是说在SSL上传送的数据是使用对称密钥加密的！因为非对称加密的速度缓慢，耗费资源。其实当云端3和主机使用非对称加密方式建立连接后，云端3和主机已经决定好了在传输过程使用的对称加密算法和关键的对称加密密钥，由于这个过程本身是安全可靠的，也即对称加密密钥是不可能被窃取盗用的，因此，保证了在传输过程中对数据进行对称加密也是安全可靠的，因为除了云端3和主机之外，不可能有第三方窃取并解密出对称加密密钥！如果有人窃听通信，他可以知道双方选择的加密方法，以及三个随机数中的两个。整个通话的安全，只取决于第三个随机数(Premaster secret)能不能被破解。

其他补充

对于非常重要的保密数据，传感端1还需要对云端3进行验证，以保证数据传送给了安全的合法的云端3。传感端1可以向云端3发出Cerficate Request消息，要求云端3发送证书对云端3的合法性进行验证。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张云端3证书。

PreMaster secret前两个字节是TLS的版本号，这是一个比较重要的用来核对握手数据的版本号，因为在Client Hello阶段，云端3会发送一份加密套件列表和当前支持的SSL/TLS的版本号给传感端1，而且是使用明文传送的，如果握手的数据包被破解之后，攻击者很有可能串改数据包，选择一个安全性较低的加密套件和版本给传感端1，从而对数据进行破解。所以，传感端1需要对密文中解密出来对的PreMaster版本号跟之前Client Hello阶段的版本号进行对比，如果版本号变低，则说明被串改，则立即停止发送任何消息。

https是在TCP层与http层之间加入了SSL/TLS来为上层的安全保驾护航，主要用到对称加密、非对称加密、证书，等技术进行云端3与MQTT处理模块的数据加密传输，最终达到保证整个通信的安全性。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims

1.一种物联网智能网关，包括传感端、网关、云端和用户端；所述网关向所述云端发送第一信息，所述云端向所述网关发送第二信息；其特征在于，

所述第二信息包括传感控制信息；

所述第一信息通过包含ssl或tls的第一协议发送；

所述第二信息通过包含ssl或tls的第二协议发送；

所述第一信息和所述第二信息是字符串格式信息。

2.根据权利要求1所述的网关，其特征在于，还包括；

所述字符串格式是JSON字符串格式。

3.根据权利要求1所述的网关，其特征在于，所述第一协议是MQTT SSL。

4.根据权利要求1所述的智能门锁，其特征在于，所述第一协议是HTTPS。

5.根据权利要求1中所述的网关，其特征在于，所述第二协议是MQTT SSL。

6.根据权利要求1中所述的网关，其特征在于，所述第二协议是HTTPS。