用于消息存储处理和安全认证的控制方法、系统和介质与流程

1.本发明涉及通信安全技术领域，尤其是一种用于消息存储处理和安全认证的控制方法、系统和介质。


背景技术：

2.mqtt协议作为一种轻量级的通信协议，其较小的通信开销及对不可靠网络的适应性等特点，使得其在如今的物联网领域有着广泛的应用。相关技术中，基于mqtt协议进行数据传输的方案中，目前对数据传输过程的安全保障方案，可以保证数据在传输和存储处理两方面兼具安全性，但是对消息进行加解密的密钥的安全性不能保证。


技术实现要素：

3.本发明旨在至少解决现有技术中存在的技术问题之一。为此，本发明提出一种用于消息存储处理和安全认证的控制方法、系统和介质，能够提高密钥的安全性。
4.一方面，本发明实施例提供了一种用于消息存储处理和安全认证的控制方法，包括以下步骤：
5.安全认证中心根据消息密钥生成过程密钥；
6.发布者客户端采用所述消息密钥对原始消息进行加密，得到第一加密消息，将所述第一加密消息传输到分布代理；
7.分布代理从所述安全认证中心获取所述过程密钥，采用所述过程密钥对所述第一加密消息进行二次加密，得到第二加密消息；
8.订阅者客户端接收所述分布代理转发的所述第二加密消息，采用所述消息密钥对所述第二加密消息进行解密，得到原始消息。
9.在一些实施例中，通过所述安全认证中心生成主题消息的消息密钥，并对所述消息密钥进行管控。
10.在一些实施例中，当根据独占公私钥对所述消息密钥进行加密或解密时，通过发布者客户端生成并管理主题消息在发布者客户端的消息密钥，通过安全认证中心生成主题消息在订阅者客户端的消息密钥。
11.在一些实施例中，所述消息密钥和所述过程密钥均为对称密钥；所述独占公私钥为非对称密钥。
12.在一些实施例中，所述第一加密消息包括通过消息密钥进行加密的消息和通过独占公钥加密的消息密钥；所述第二加密消息包括过程密钥加密的消息和订阅者客户端的消息密钥。
13.在一些实施例中，所述分布代理通过客户端信息和独占公钥加密的消息密钥向所述安全认证中心请求过程密钥，所述客户端信息包括订阅者客户端信息和发布者客户端信息。
14.在一些实施例中，所述安全认证中心在生成过程密钥前，通过独占私钥对分布代
理发送的独占公钥加密后的消息密钥进行解密，得到发布者客户端的消息密钥，根据发布者客户端的消息密钥随机生成订阅者客户端的消息密钥，通过独占私钥对所述订阅者客户端的消息密钥进行加密。
15.在一些实施例中，所述订阅者客户端通过独占公钥对通过独占私钥加密后的消息密钥进行解密，通过解密后的消息密钥对所述第二加密消息中的过程密钥加密的消息进行解密，得到原始消息。
16.另一方面，本发明实施例提供了一种用于消息存储处理和安全认证的控制系统，包括：
17.安全认证中心，用于根据消息密钥生成过程密钥；
18.发布者客户端，用于采用所述消息密钥对原始消息进行加密，得到第一加密消息，将所述第一加密消息传输到分布代理；
19.分布代理，用于从所述安全认证中心获取所述过程密钥，采用所述过程密钥对所述第一加密消息进行二次加密，得到第二加密消息；
20.订阅者客户端，用于接收所述分布代理转发的所述第二加密消息，采用所述消息密钥对所述第二加密消息进行解密，得到原始消息。
21.另一方面，本发明实施例提供了一种存储介质，其中存储有计算机可执行的程序，所述计算机可执行的程序被处理器执行时用于实现所述的用于消息存储处理和安全认证的控制方法。
22.本发明实施例提供的一种用于消息存储处理和安全认证的控制方法，具有如下有益效果：
23.本实施例在发布者客户端采用消息密钥对原始消息进行加密，在订阅者客户端采用消息密钥进行解密，使得原始消息在传输过程中处于加密状态，从而提高原始消息的安全性，并且，在安全认证中心根据消息密钥生成过程密钥，使分布代理从安全认证中心获取过程密钥后，采用过程密钥对第一加密消息进行二次加密，使得分布代理在仅仅知道过程密钥时，无法推出消息密钥，从而解决消息在代理端以明文形式进行处理时的安全问题，提高密钥安全性。
24.本发明的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。
附图说明
25.下面结合附图和实施例对本发明做进一步的说明，其中：
26.图1为一种实施例的ssl/tls协议方案在网络模型中的位置关系示意图；
27.图2为本发明实施例的分发代理、安全认证中心、发布者客户端和订阅者客户端的交互示意图；
28.图3为本发明实施例的一种用于消息存储处理和安全认证的控制方法的流程图。
具体实施方式
29.下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附
图描述的实施例是示例性的，仅用于解释本发明，而不能理解为对本发明的限制。
30.在本发明的描述中，需要理解的是，涉及到方位描述，例如上、下、前、后、左、右等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。
31.在本发明的描述中，若干的含义是一个以上，多个的含义是两个以上，大于、小于、超过等理解为不包括本数，以上、以下、以内等理解为包括本数。如果有描述到第一、第二只是用于区分技术特征为目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量或者隐含指明所指示的技术特征的先后关系。
32.本发明的描述中，除非另有明确的限定，设置、安装、连接等词语应做广义理解，所属技术领域技术人员可以结合技术方案的具体内容合理确定上述词语在本发明中的具体含义。
33.本发明的描述中，参考术语“一个实施例”、“一些实施例”、“示意性实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。
34.相关技术中，mqtt协议作为一种轻量级的通信协议，其较小的通信开销及对不可靠网络的适应性等特点，使得其在如今的物联网领域有着广泛的应用。但是，由于mqtt协议在最初是在私人网络环境下进行设计的，关注的重点更多的在于消息的发布分发的轻量性，而非一些消息处理或者传输过程中的安全性，其本身除了通过用户名密码认证的方式之外，并未有其他的保证安全性的措施。在物联网领域飞速发展的今天，随着用户量的增长，相应的安全隐患和问题也日渐凸显。
35.在基于mqtt协议的物联网通信现状进行调查分析中发现，在公网条件下总共有78829台代理端使用mqtt协议进行通信，其中使用端口1883(mqtt协议的默认通信端口，不使用ssl/tls进行安全认证)的服务器占比为99.69％，即当前公网环境下绝大多数的mqtt服务器均未对通信过程进行相关的安全加密措施。很多研究实践结果表明，60％以上的服务器未对客户端进行用户名密码验证，并且绝大多数代理端均可以使用任意客户端订阅所有的主题及收到相应的明文推送。
36.这也就从实际角度说明了当前基于mqtt协议的通信现状不容乐观。本发明实施例的侧重点在于数据在传输和存储处理两方面的安全性，所以本发明实施例不考虑分析一些侧重于主题权限控制的方案或是侧重于加解密算法性能的方案。侧重于保证数据在传输方面的安全性的方案中，比较常见的是ssl/tls协议方案，以及新兴的augpake协议方案。但是，由于augpake方案就是ssl/tls方案的简化版本，它其实就是将ssl/tls方案的认证步骤放在了线下：客户端和代理端需要在线下进行认证，以保证安全，这对于大量客户端存在的场景并不适用。并且，其后的线上执行过程和ssl/tls方案类似，本质上都是为了协商后续用于保证数据传输方面的安全性的对称密钥，所以对这两种方案进行重复分析没有必要。
37.下面对ssl/tls协议方案进行分析，总结其在本专利的研究侧重点下的不足之处，然后再介绍本发明实施例的具体内容。
38.如图1所示，ssl/tls协议方案位于应用层和tcp/ip层之间。在图1所示的网络模型中，ssl/tls协议方案主要用于保证基于tcp协议的通信的安全性，基本的加密思路采用的是非对称加密和对称加密结合的形式，其加密通信流程如下：
39.步骤一、客户端向服务端发起请求索取服务端的公钥；
40.步骤二、双方协商好本次会话使用的会话密钥，该密钥属于对称密钥；
41.步骤三、在本次会话的后续阶段双方都采用协商好的会话密钥进行通信。
42.通信的前两步也被称为握手过程，这也是ssl/tls协议最核心的部分，它包括了一系列加密相关信息的协商以及后续加密所用到的安全参数的确定。
43.具体地，客户端在首次请求加密通信时向服务端发送clienthello请求，主要包括几个字段：versionnumber(当前支持的tls协议的最高版本)、randomly generated data(后续将被用于生成会话密钥)、cipher suite(客户端支持的加密套件)等；
44.服务端收到客户端的clienthello请求之后，需要向客户端发送响应，其中最主要的字段有三个：serverhello，servercertificate及serverhellodone。serverhello中包含的字段和客户端发送的clienthello请求中的字段一一对应；servercertificate为服务端提供给客户端用于认证自身身份的证书，该证书用于证明服务端的合法性及传递公钥。最后，serverhellodone表示服务端响应完成，等待客户端后续响应；
45.客户端在收到服务端的响应之后，首先认证服务端的证书的合法性。在服务端的证书合法性认证通过后，客户端向服务端再次发送的信息主要包括：加密后的最后一个随机数premasterkey，changecipherspec及clientfinished。changecipherspec表示使用之前协商的加密套件进行后续的通信的加密。clientfinished表示客户端的握手结束，这一项也是前面发送的所有内容的hash值，用于供服务端进行校验；
46.服务端收到客户端发送的响应后，首先使用对应的私钥将最后一个随机数premasterkey解密，然后结合前面通信过程中的两个随机数计算本次会话后续使用的对称密钥，最后再向客户端发送以下信息：changecipherspecmessage及serverfinishedmessage。前者用于通知客户端后续将使用前面协商好的对称密钥及加密算法进行通信，后者表示把整个会话进行hash计算得到hash值用于客户端认证，在客户端认证成功后后续就通过协商好的对称密钥进行加密通信。
47.通过上述流程可以看到，ssl/tls协议通过额外的握手过程来协商后续用于加密数据的对称密钥，从而解决了数据传输方面的安全性问题。但是基于ssl/tls协议的方案还是存在以下问题：第一、未解决消息在代理端存储处理时可能存在的安全问题，例如，由于越来越多的消息代理被部署到云端，假设消息代理被入侵了，由于消息在代理端是以明文存储的，那么大量明文消息就很有可能被泄露和篡改；第二、ssl/tls协议为了协商后续的对称密钥而额外增加了握手流程，即增加了信息的额外两次往返，在网络状况比较拥堵的情况下，对于追求轻便和快速的物联网通信，尤其是通信中的客户端而言有可能会造成负担。
48.为了同时兼具传输和存储处理两方面的安全性，尤其是保证数据在代理端存储处理方面的安全性，最基本的一个要求就是保证数据在代理端进行分发处理时依旧是加密状态。那么在现有的基础上，就是发布者客户端在某个主题上进行消息的发布前先对原始消息部分进行加密处理。这样一来只要选用的加密算法恰当并且密钥未被泄露的话，可以保
证消息在传输和存储处理时均维持在加密状态而不暴露原始的消息内容。并且消息代理将消息转发给相应的订阅者客户端之后，订阅者客户端可以使用对应发布者的密钥对密文进行解密得到原始消息。
49.但是，假设采取的是对称加密的方式，也就是说密钥k会存在于多个客户端手中，这增加了密钥被泄露的风险。只要某个客户端被侵入导致密钥k被获取了，再加之某个分发代理也被入侵，那么后续的所有消息加密形同虚设，攻击者可以将分发代理收到的所有消息进行解密并随意篡改转发。假设订阅者客户端本身可能是由某个攻击者伪装而成的，那么这个攻击者可以直接获取到密钥k，进一步地，分发代理再被入侵之后，加密的消息也就可以被攻击者轻松解密。采用非对称加密的方式可以解决前面对称加密所面临的密钥容易被泄露的问题。假设每个客户端本身都有一对公私钥：pubkey、privkey，那么发布者需要发布消息时只需将原始消息使用订阅者客户端的公钥进行加密即可。订阅者客户端收到了分发代理转发的加密消息之后使用自己的私钥就可以解密得到原始消息。即使某个客户端被入侵导致自身的私钥泄露了，后续就算分发代理被入侵，攻击者也只能解密得到转发给被入侵的客户端的消息，因为每个客户端的公私钥是独立的。但是此方案也存在缺陷：首先，从mqtt协议通信模型中可以看到，发布者本身并不知晓某个主题上的订阅者客户端的信息，那么也就无法知道发布的消息到底会被分发代理转发给哪些订阅者客户端，发布者也就不知道该使用哪个订阅者客户端的公钥对消息进行加密；其次，假设通过对原始的mqtt协议进行修改使得发布者可以知道当前要发布消息的主题上存在的订阅者客户端相关信息。但由于订阅者客户端可能存在多个，而发布者客户端发布消息时单次只能采用一个订阅者客户端的公钥对原始消息进行加密。由于订阅者客户端的公钥信息都是独立不相关的，那么该方案就无法满足存在多个订阅者客户端时的要求；再次，假设通过某种方式修改了原始的mqtt协议使得发布者客户端单次可以传输多个通过不同订阅者公钥进行加密的消息的组合，并且分发代理能够将报文中属于不同订阅者客户端的加密消息正确分割开来并转发到不同的订阅者客户端。那么当某个主题的订阅者客户端数目很大时，发布者客户端发布的publish报文的长度会很长，并且客户端作为发布者时需要存储大量的订阅者的公钥等信息。而实际场景中客户端往往是硬件资源如内存、cpu受限的终端设备，该方案对于这些终端设备而言难以承受。
50.综上所述，虽然上述这种方案可以保证数据在传输和存储处理两方面兼具安全性，但是，对消息进行加解密的密钥的安全性不能保证，并且，在存在大量客户端时无法有效地对密钥进行管控。
51.基于此，本发明实施例提供了一种用于消息存储处理和安全认证的控制方法、系统和介质。本实施例通过将mqtt协议的安全认证与消息存储处理分离，拥有消息存储处理功能的消息代理可以在云端进行分布式部署，记为分发代理，而具有消息安全认证功能的部分则进行单独部署，记为安全认证中心。具体地，分发代理、安全认证中心、发布者客户端和订阅者客户端的交互过程如图2所示。在图2所示的交互系统中，如图3所示，本发明实施了提供了一种用于消息存储处理和安全认证的控制方法，包括以下步骤：
52.s31、安全认证中心根据消息密钥生成过程密钥。
53.在本实施例中，安全认证中心可以是可信的第三方机构，其用于处理以下两项内容：
54.第一、根据分发代理的请求，使用相关发布者客户端及订阅者客户端的消息密钥生成过程密钥，以便后续分发代理使用过程密钥对消息密文进行二次加密处理；
55.第二、使用生成的独占公私钥对客户端的消息密钥进行加解密处理，通过过程密钥来解决消息在分布代理端以明文形式进行存储处理时，由于分布代理端不可信而导致的消息被大量泄漏和篡改的问题，同时，通过独占公私钥来改进存在大量客户端时的消息密钥的安全性问题及管控问题。
56.s32、发布者客户端采用消息密钥对原始消息进行加密，得到第一加密消息，将第一加密消息传输到分布代理。
57.在本实施例中，发布者客户端在向分发代理发布消息前，使用消息密钥对原始消息进行加密处理。由于消息在传输前己经处于加密的状态，在消息密钥未被泄露的前提下，攻击者难以获取到消息的原文，不需要类似ssl/tls方案那样增加额外的握手流程来协商后续的对称密钥。
58.s33、分布代理从安全认证中心获取所述过程密钥，采用过程密钥对所述第一加密消息进行二次加密，得到第二加密消息。
59.在本实施例中，分发代理还需要与安全认证中心进行通信，以便获取到对发布者传输的消息进行二次加密的过程密钥。在每次向订阅者转发消息时，分发代理使用获取到的过程密钥对发布者客户端传输的消息密文进行二次加密得到新的密文，之后再将处理后的结果转发给订阅者客户端。在仅仅知道过程密钥的前提下，分发代理无法推出发布者或订阅者客户端的消息密钥，这也就解决了消息在代理端以明文形式进行存储处理时的问题。
60.s34、订阅者客户端接收分布代理转发的第二加密消息，采用消息密钥对第二加密消息进行解密，得到原始消息。
61.在本实施例中，订阅者客户端是接收己订阅的主题上的消息的客户端。在本方案中，订阅者客户端在收到分发代理二次加密后的密文之后，会通过自己的消息密钥对密文进行解密处理从而得到消息原文。和发布者客户端类似的是，在分发代理转发数据前，消息仍处于加密状态，在消息密钥未被泄露的前提下，攻击者难以获取到消息的原文。
62.在本发明实施中，主要使用以下三种密钥：
63.第一、消息密钥。消息密钥属于对称密钥，由发布者客户端和订阅者客户端使用，用于对消息进行加密或解密。发布者客户端在发布消息之前会使用它的消息密钥对原始消息进行加密处理，而订阅者客户端最终也会使用它的消息密钥对加密的消息进行解密处理。需要特别说明的是，当不使用独占公私钥时，消息密钥是由安全认证中心所生成并管控的，发布者客户端发送消息或者分发代理转发消息时不存在加密的消息密钥；当独占公私钥时，发布者客户端的消息密钥将由发布者客户端生成，而订阅者客户端的消息密钥则由安全认证中心生成，其中，第一加密消息包括通过消息密钥进行加密的消息和通过独占公钥加密的消息密钥；第二加密消息包括过程密钥加密的消息和订阅者客户端的消息密钥。可以看到，由于消息在传输转发前就己经进行了加密处理，所以不需要像ssl/tls方案一样执行额外的握手流程来协商后续的对称密钥，从而解决ssl/tls方案需要额外的网络往返可能造成的开销问题。
64.第二、过程密钥。过程密钥属于对称密钥，由安全认证中心使用相关发布者客户端
和订阅者客户端的消息密钥进行生成并交付给分发代理进行使用，用于对发布者客户端传输的密文消息进行二次加密，加密后的数据仍然为密文消息，最终可以由订阅者客户端使用其消息密钥直接进行解密得到原始消息。并且，分发代理无法仅从过程密钥反推出发布者或订阅者客户端的消息密钥。过程密钥是为了解决ssl/tls方案中消息在代理端以明文形式进行存储处理的问题。
65.第三、独占公私钥。属于非对称密钥，由发布者客户端、订阅者客户端及安全认证中心生成，用于对发布者客户端、订阅者客户端使用的消息密钥进行加解密。独占公私钥主要用于解决无安全认证的方案在大量客户端存在时的消息密钥管控问题以及消息密钥的安全问题。
66.在本实施例中，过程密钥过程密钥prockeysrc-dest-t是通过发布者客户端和订阅者客户端的消息密钥enckeysrc、enckeydest共同生成，并且仅由分发代理进行使用，用于对发布者传输的消息密文进行二次加密，加密后的密文再由订阅者客户端进行解密即可得到原始消息内容。而消息密钥由发布者客户端、订阅者客户端及主题共同决定，随着客户端或主题的不同而不同。
67.以异或加密为例，假设发布者客户端的消息密钥为“00011010”，订阅者客户端的消息密钥为"00000100"，那么生成的过程密钥即为两个消息密钥异或后的结果："00011110"。假设需要加密的原文消息为“abc"，那么发布者客户端在使用其消息密钥对其进行加密后产生的密文为：“{xy”，分发代理使用过程密钥对该密文进行二次加密后的结果为：“efg”，订阅者客户端使用其消息密钥对二次加密后的密文进行解密，最终得到消息原文：“abc”。
68.发布者客户端使用消息密钥对想要发布的消息进行加密并将密文发送给分发代理集群中的某个节点，订阅者客户端使用消息密钥对收到的转发消息直接进行解密得到原始的消息内容。而与客户端使用消息密钥对数据进行加解密这一点不同的是，分发代理使用过程密钥对消息密钥加密明文后生成的密文进行再次加密，并且还需要保证二次加密后的结果能够直接被订阅者客户端所解密得到原始消息，同时还需要保证分发代理无法仅通过过程密钥推导出明文，而一般的加解密密钥及对应加解密算法不能满足上述条件，故对过程密钥的生成及加密需要有一定的限制和要求。具体地，针对过程密钥的应用，具有以下优点：
69.从上述过程密钥的应用可知，数据在传输及存储处理两方面均具有安全性，并且不需要像ssl/tls方案一样通过额外的握手流程来协商后续用于加密的对称密钥，客户端也不需要对大量的密钥进行管控。其具体可以理解为医学几点：第一，数据在传输的过程中都是加密的，并且明文和密文只能通过相关的加解密消息密钥才能进行加解密，在消息密钥未被泄露的前提下，数据传输的安全性得到了保证，也就不需要像ssl/tls方案一样增加额外的握手流程以协商密钥；第二，分发代理只能对收到的密文消息进行二次加密处理而无法独立推导出解密密文的密钥信息，也就无法解密得到原始的消息，这保证了消息在存储处理方面的安全性；第三，对于任意主题t而言，不同客户端关于该主题的加解密密钥是独立且不同的，这也就保证了即使某个客户端和分发代理同时被入侵时也无法大规模泄露篡改所有的经过该分发代理的消息，也就保证了数据的安全性；第四，每个客户端需要发布或者解密某个主题上的消息时，使用的密钥由认证中心生成并管理，这也就解决了前面所
提到的客户端管理密钥问题。最后，订阅者客户端收到二次加密的消息后能够对其进行解密得到原始消息，这也就保证了整个发布转发流程的完整性。
70.在本实施例中，在使用了过程密钥进行二次加密后，可以解决在分发代理不可信的情况下可存在的大量明文消息泄露、被篡改等问题。但是还存在两个问题：第一个为安全认证中心的消息密钥管控的问题，第二个为消息密钥的安全问题。具体地，安全认证中心需要管控的消息密钥个数与发布者客户端、订阅者客户端数量成正比。在发布者客户端和订阅者客户端的数目较多的情况下，大量消息密钥的管控会对安全认证中心带来额外的负担，进一步地，可能会导致发布者客户端、订阅者客户端及分发代理和安全认证中心的网络通信产生较大的延迟，最终导致消息的发布分发流程被滞后甚至瘫痪。消息密钥的安全问题同样不可忽略。若采用客户端请求消息密钥、安全认证中心生成并返回消息密钥的形式，那么消息密钥在传输方面的安全性就无法得到保证，攻击者在截获消息密钥之后可以跳过过程密钥，轻松地获取或篡改发布者想要发布的信息，这对于正常的发布分发流程会产生严重的影响。
71.因此，为了解决上述问题，本实施例通过使安全认证中心需要生成管控的消息密钥数目k*l*n，即与发布者无关，并且消息密钥的安全性得到了保证。在应用过程密钥的基础上，使用独占公私钥对消息密钥进行加解密。在引入独占公私钥后，处理内容也有所不同：
72.客户端拥有自己的公私钥，用于生成对加密的消息密钥进行加解密的独占公钥；
73.发布者客户端的消息密钥由自己生成并管理，而订阅者客户端的消息密钥则由安全认证中心生成；
74.安全认证中心管控以主题为粒度的公私钥，该公私钥用于生成对消息密钥进行加解密的独占私钥。
75.对于图2所示交互系统中每个终端，在工作也发生了一些变化：
76.发布者客户端不再向认证中心请求消息密钥而是自己生成。在给分发代理发送的数据分为两部分：通过消息密钥加密的消息，以及通过独占公钥加密的消息密钥；
77.分发代理在请求过程密钥时，不仅需要带上相应的客户端信息，还需要带上发布者所发送的加密消息密钥。在转发数据给订阅者客户端时，不仅需要转发二次加密的密文，还需要带上安全认证中心返回的订阅者客户端的消息密钥；
78.安全认证中心在生成过程密钥前，首先需要使用独占私钥对分发代理传输过来的加密消息密钥进行解密得到发布者的消息密钥，然后随机生成订阅者客户端的消息密钥，并按照前述要求生成过程密钥。之后，使用相关的独占私钥进行对订阅者客户端的消息密钥进行加密，以防止分发代理得到未加密的消息密钥。最后将生成的过程密钥及加密的订阅者客户端密钥返回给分发代理；
79.订阅者客户端用于对消息密文进行解密的消息密钥包含在分发代理转发而来的数据中。订阅者客户端首先使用独占公钥对消息密钥进行解密，然后再通过消息密钥解密密文得到原始消息。
80.在本实施例中，在使用独占公私钥时，对于发布者客户端，独占公钥用于对消息密钥进行加密；对于订阅者客户端，独占私钥用于对消息密钥进行解密。其中，安全认证中心使用发布者客户端的独占私钥对发布者的消息密钥进行解密，以及使用订阅者客户端的独
占公钥对订阅者客户端的消息密钥进行加密。具体地，在发布者客户端，通过使用发布者客户端的私钥privkeysrc和对应主题的公钥pubbkeyt生成一个新的独占公钥pubkeysrc-t，该独占公钥用于对发布者客户端加密消息的消息密钥进行加密。认证中心生成过程密钥时，使用发布者客户端的公钥pubkeysrc及对应主题的私钥privkeyt生成与发布者客户端的独占公钥相对应的独占私钥，从而解密得到发布者客户端的加密消息密钥。
81.下面根据各个部分的通信流程来分析优化后的本发明实施例的安全性。
82.第一、发布者客户端和分发代理之间的通信：
83.发布者客户端和分发代理之间的通信流程是单向的，即从发布者客户端到分发代理，分析在各种攻击模式下此通信流程的安全性。
84.窃听攻击：由于消息密钥由发布者客户端随机生成，故攻击者无法窃取加密密钥。传输过程中，密钥和消息都是经过加密处理的，攻击者只能获取到加密后的消息及消息密钥，无法得到消息的明文，也就无法对相应的消息进行窃听及外泄等操作。这也就保证了数据在传输时的安全性。
85.中间人攻击：在生成了对应的密文及加密后的消息密钥之后相关的报文才会被发送到分发代理，在消息密钥未被泄露的前提下，中间人若想要实施攻击，需要先对消息密钥进行解密，这需要满足两个条件：1)窃取或破解得到发布者的私钥；2)通过独占公私钥的生成算法生成对应的独占公钥。可以看到，正常情况下这两点对于攻击者来说都是难以获取到的信息，故中间人难以实施攻击。
86.分发代理不可信：假设分发代理集群中的某个节点被攻击者通过某种手段成功入侵，由于发布者传输到分发代理的消息都是经过加密的：消息体通过随机生成的消息密钥进行加密，并且该消息密钥会通过独占公钥进行加密。独占公钥加密后的数据只能由对应的独占私钥才能解密，而对应的独占私钥只有认证中心才能够计算推导而得到。故攻击者即使成功入侵了某个分发代理节点也无法获取相关消息的明文内容，这也就解决了分发代理不可信时可能出现的大量明文消息被泄露及篡改的问题，从而保证了数据在存储处理方面的安全性。
87.第二、分发代理和认证中心之间的通信：
88.分发代理和认证中心之间的通信是双向的，两者之间主要是进行过程密钥的请求和响应过程，由于分发代理和认证中心并不存在物联网环境下的客户端的硬件限制如内存及计算能力限制等问题，故两者之间的通信完全可以通过现有的方案，即ssl/tls协议方案来进行解决。由于使用了ssl/tls协议方案，相应的窃听攻击、中间人攻击等一系列攻击手段也就无法生效了。另外，即使分发代理被入侵，由于整个通信过程中传输的数据都是加密的，攻击者也只能获取认证中心所返回的过程密钥及加密后的订阅者客户端的消息密钥：对于过程密钥而言，发布者无法通过过程密钥单独推出发布者或者是订阅者客户端的加密密钥，故攻击者无法通过过程密钥来解密得到原始消息。而对于加密后的订阅者客户端的消息密钥而言，对其解密需要先得到订阅者客户端所生成的独占公钥，而该过程需要使用订阅者客户端的私钥，但订阅者客户端的私钥是其所独有的，这也就保证了数据在存储处理方面的安全性。
89.第三、分发代理和订阅者客户端之间的通信：
90.分发代理和订阅者客户端之间的通信也是单向的，分发代理将密文及加密的消息
密钥向相应订阅者客户端进行转发推送。
91.下面分析该通信过程的安全性：
92.窃听攻击：传输过程中消息密钥和对应的密文都处于加密状态，攻击者无法单独根据密文反推出对应的明文，而只能先通过破解加密密钥的方式来间接得到明文内容。而消息密钥又通过相关的独占私钥进行加密，只有订阅者客户端才能计算推导得到对应的独占公钥。故攻击者无法在获取原始的明文消息内容，这也就保证了数据在传输时的安全性。
93.中间人攻击：和发布者到分发代理的通信过程类似，在消息密钥未被泄露的情况下，中间人欲实施攻击需要满足两个条件：1)窃取或破解得到发布者的私钥；2)通过独占公钥的生成算法生成对应的独占公钥。这两点对于攻击者来说都是难以满足的，故中间人难以实施攻击。
94.分发代理不可信：和发布者类似，假设分发代理集群中的某个节点被攻击者通过某种手段成功入侵，由于分发代理准备转发到订阅者客户端的数据都处于加密状态：消息内容通过过程密钥进行了二次加密，订阅者客户端的消息密钥则通过独占私钥进行加密。该独占私钥加密后的数据只能由对应的独占公钥才能解密，而对应的独占公钥只有订阅者客户端才能够计算推导而得到。故攻击者即使成功入侵了某个分发代理节点也无法获取相关消息的明文内容，这也就解决了分发代理不可信时可能出现的大量明文消息被泄露及篡改的问题，从而保证了数据在存储处理方面的安全性。
95.综上所述，本发明实施例所提出的消息存储和安全认证分离式方案在理论上兼具安全性和有效性，并且改进了消息密钥的安全问题及管控问题。同时，所采用的mqtt协议在整体性能上要优于采用ssl/tls的方案的mqtt协议，而相对于原始的mqtt协议而言，基于该改进方案的mqtt协议在性能指标与数据安全性两者间取得了较好的折中效果。
96.本发明实施例提供了一种用于消息存储处理和安全认证的控制系统，包括：
97.安全认证中心，用于根据消息密钥生成过程密钥；
98.发布者客户端，用于采用所述消息密钥对原始消息进行加密，得到第一加密消息，将所述第一加密消息传输到分布代理；
99.分布代理，用于从所述安全认证中心获取所述过程密钥，采用所述过程密钥对所述第一加密消息进行二次加密，得到第二加密消息；
100.订阅者客户端，用于接收所述分布代理转发的所述第二加密消息，采用所述消息密钥对所述第二加密消息进行解密，得到原始消息。
101.本发明方法实施例的内容均适用于本系统实施例，本系统实施例所具体实现的功能与上述方法实施例相同，并且达到的有益效果与上述方法达到的有益效果也相同。
102.本发明实施例提供了一种存储介质，其中存储有计算机可执行的程序，所述计算机可执行的程序被处理器执行时用于实现如图3所示的用于消息存储处理和安全认证的控制方法。
103.本发明实施例还公开了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存介质中。计算机设备的处理器可以从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行图3所示的用于消息存储处理和安全认证的控制方法。
104.上面结合附图对本发明实施例作了详细说明，但是本发明不限于上述实施例，在
所属技术领域普通技术人员所具备的知识范围内，还可以在不脱离本发明宗旨的前提下作出各种变化。此外，在不冲突的情况下，本发明的实施例及实施例中的特征可以相互组合。