通过使用控制增强MQTT安全

通过引入使用控制改进MQTT

1 引言

近年来，物联网（IoT）设备已日益深入到我们的日常生活中。事实上，我们目前正使用着许多联网的客体，例如智能家用电器、联网汽车、远程监控摄像头、智能电表等。根据爱立信[5]的预测，到2020年，物联网设备总数将达到500亿台，而如果考虑到万物互联（IoE）范式（还包括智能手机、智能手表、平板电脑等用户设备），这一数字将更加惊人。

物联网设备可能非常不同，因为它们通常具有不同类型的硬件，具体取决于所提供的功能，以及用于管理这些设备的软件应用程序。因此，为了拥有一个能够简化同一用户所拥有的所有智能设备控制的统一应用程序，人们迫切需要能够轻松地与一组不同的物联网设备进行通信。为此，学术文献中已提出了多种应用层协议，其中MQTT是使用最广泛的协议之一[1]。

MQTT最近也由结构化信息标准促进组织进行了标准化并按照发布/订阅协议模式工作，其中由一个中心代理负责通信和数据共享，从一组发布者收集数据，并根据其指定的兴趣将数据重新分发给一组订阅者。

根据[20]，MQTT标准及现有实现，仅提供基本的认证和简单的授权策略支持，且这些策略仅在订阅者订阅时应用。由于MQTT基于HTTP功能，大多数MQTT安全解决方案似乎要么是特定于应用程序的，要么只是利用TLS/SSL协议[1]。目前，结构化信息标准促进组织（OASIS）MQTT安全小组委员会正在致力于使用MQTT网络安全框架来保障MQTT消息传递的安全[17]。

尽管针对MQTT协议安全性的努力正在增加，但仍存在两个主要障碍。第一个问题是，尽管该协议能够处理作为发布者或订阅者的各种组件，但由于它们使用不同的平台，因此难以创建和实施通用的安全策略。第二个问题是，当前的努力主要集中于消息通信安全，以防止窃听、完整性破坏和中间人攻击。然而，在代理层面支持策略执行方面尚未开展工作，也未考虑动态撤销订阅的可能性。

本文中，我们提议通过在MQTT架构和工作流中添加使用控制（UCON）来增强MQTT协议的安全性。UCON是传统访问控制的扩展，其通过基于可变属性（即随时间变化的属性[10]）评估策略，强制执行访问决策的连续性。在MQTT中引入使用控制的目标是实施动态的细粒度策略，这些策略不仅将订阅者的身份作为授予数据访问权限的参数，还考虑订阅者信誉、数据可靠性或特定应用的环境条件等动态属性。在调研了主要的物联网应用协议并阐明选择MQTT的原因后，本文将讨论MQTT-UCON集成的架构和工作流程。所提出的框架设计为通用且易于集成到代理组件中，同时对发布者和订阅者保持透明。

实际上，添加UCON并不会修改MQTT协议，而是独立于发布者和订阅者的实现来强制执行策略，从而使所提出的解决方案能够与任何现成的MQTT发布者/订阅者应用兼容。此外，我们还将通过在通用设备和性能受限设备上展示该框架的实际实现，证明该方法的可行性，并讨论在分别用作代理和订阅者的两台Raspberry Pi 3 model b上测得的性能。

本文的其余部分组织如下：在第2节中，报告了主要物联网应用协议之间的比较，并随后详细介绍了MQTT协议并阐述我们选择专注于它的原因。此外，还报告了关于使用控制的一些背景信息。第3节描述了UCON与MQTT的集成，详细说明了架构和操作流程。第4节详细介绍了性能分析的结果。第5节报告了一组关于MQTT安全性和UCON在物联网中应用的相关工作。最后，第6节总结了本初步工作的未来研究方向。

2 背景

在本节中，我们将调研物联网的主要协议，阐述选择聚焦于MQTT的原因，简要描述该协议，并回顾有关使用控制概念的一些背景知识。

2.1 物联网应用协议

物联网中最知名的应用层协议有CoAP、MQTT、XMPP、HTTP、AMQP和WebSocket。在[7]中，作者声称CoAP比MQTT更节省资源，但在面向消息的方法（MOA）方面，MQTT表现突出。他们还报告称，MQTT比CoAP需要更少的内存，但中央处理器负载更高。上述所有协议都使用TCP作为传输层，只有CoAP使用UDP。在安全层方面也是如此，所有协议都使用TLS/SSL，除了CoAP使用DTLS。事实上，CoAP主要面向资源极度受限的环境。

此外，根据[8]，MQTT基于TCP，但其头部大小最小，仅有两个字节。此外，它提供三个级别的服务质量（QoS），这使得该协议在QoS方面处于领先地位，尽管它在网络中需要额外的负载来进行消息重传。另一方面，XMPP需要处理和存储XML数据，这对大多数物联网设备而言需要过大的内存空间。此外，HTTP在非受限环境中表现更佳，适用于个人计算机、笔记本电脑和服务器。由于其高开销，通常不适用于物联网设备。AMQP[14]更适合服务器到服务器的通信，而非设备到设备的通信。WebSocket既不是请求/响应协议，也不是发布/订阅协议。在WebSocket中，客户端通过与服务器初始化握手来建立WebSocket会话。握手过程旨在与基于HTTP的服务器端软件兼容，以便HTTP和WebSocket客户端可以共用同一个端口[4]。根据[21]，在较低丢包率情况下，MQTT消息的延迟低于CoAP，而在较高丢包率情况下则相反。当消息尺寸较小时，丢包率相等。AllJoyn[22]是一套面向物联网的完整协议栈。尽管非常流行，但AllJoyn的主要缺点是应用协议无法与协议栈其余部分分离。正因如此，AllJoyn是一个完整的框架，而不仅仅是一个应用层协议。因此，本研究未将其纳入考虑范围。作为总结，读者还可以参考表1。

此比较详细说明了服务质量（QoS）的存在。同时也指通信模式，在MQTT的情况下即为发布/订阅。最重要的一列是第三列。在该列中，我们发现MQTT更具通用性。

协议	是请求/响应	服务质量	通信模式	目标设备
CoAP	是	发布/订阅	非常受限
MQTT	否	发布/订阅	通用
XMPP	NO	请求/响应发布/订阅	高内存消耗
HTTP	NO	是发布	请求/响应 /订阅	高性能
AMQP	否			服务器到服务器通信
WebSocket	否		客户端/服务器发布/订阅	比HTTP需要更少的功耗 仍然需要高功耗
AllJoyn	NO		客户端/服务器发布/订阅	高计算能力

2.2 MQTT协议

MQTT是一种为遥测应用中的资源受限设备设计的开放的发布/订阅协议。MQTT在客户端侧设计得非常简单，无论是订阅者还是发布者。因此，系统的所有复杂性都集中在代理上，由代理执行MQTT功能所需的所有操作。

MQTT不依赖于特定的路由或网络算法和技术。然而，它假设底层网络提供一种点对点、面向会话、自动分段且具有有序交付的数据传输服务（如TCP/IP），并利用该服务进行消息交换。

MQTT是一种基于主题的发布/订阅协议，使用字符字符串来支持分层主题。这意味着能够创建和控制主题层次结构。此外，还可以订阅多个主题。在图1中，我们可以看到该协议的拓扑结构。它由将数据发送到代理以进行发布的发布者组成。订阅者向代理认证并订阅特定主题。此外，代理将数据发送给已订阅特定消息主题的特定订阅者。代理负责正确地将消息分发给相关订阅者。发布者和订阅者可能是极度受限设备，尤其是发布者，甚至可能是一个传感器。另一方面，代理必须具备足够的计算能力，以便能够处理正在分发的数据量。

MQTT支持基本的端到端服务质量（QoS）[3]。根据消息传递到接收方的可靠性的要求，MQTT提供了三种QoS级别。QoS级别0仅提供尽力而为交付服务，其中消息被传递到目的地时要么传递一次，要么完全不传递。未定义重传或确认机制。QoS级别1会重传消息，直到接收方确认为止。因此，由于重传，QoS级别1的消息可能会多次到达目的地，但系统本身并不处理多个副本。QoS级别2不仅确保消息被接收，还确保消息仅传递一次。

我们之所以关注MQTT协议，是因为它在所述的物联网协议中最具通用性，并且为所有主要的物联网开发平台（如Arduino）以及多种编程语言（C、Java、PHP、Python、Ruby、JavaScript）和两大主流移动平台（iOS和Android）提供了相应的库[5]。对代理的认证可以通过提供以下凭据来实现[13]：订阅的主题、用户名和密码。在MQTT中增加更多安全功能的最知名努力是SMQTT[18]，但是对于信息送达订阅者后所遵循的策略并未给出解决方案。

我们的提案解决了这一问题，同时实现了对发布者/订阅者的认证和访问的持续控制。

2.3 使用控制

UCON模型扩展了传统的访问控制模型。除了授权之外，它还引入了可变属性以及新的决策因素，即义务和条件。可变属性表示主体、客体和环境的特征，这些特征可能由于系统的操作而改变其值[6]。

由于可变属性在客体使用过程中会改变其值，UCON模型允许定义在访问前以及访问过程中持续进行评估的策略。具体而言，使用控制策略包含三个组成部分：授权、条件和义务。授权是用于评估主体和客体属性以及主体请求对客体执行的操作的谓词。前置授权在主体请求访问客体时进行评估，而持续授权则在访问进行过程中持续评估。义务是定义必须在访问前满足的要求（前置义务），或在访问进行过程中必须持续满足的要求（持续义务）的谓词。条件是用于评估环境属性的要求。同样地，前置条件在主体请求访问客体时进行评估，而持续条件则在访问进行过程中持续评估。

在访问进行过程中持续评估策略，旨在当执行权限不再有效时中断访问，以降低资源滥用的风险。因此，在使用控制模型中，必须能够持续获取可变属性的更新后的值，以便持续评估策略，并通过中断那些不再被授权的正在进行的访问，及时响应属性变化。

UCON的主要模块是使用控制系统（UCS），其周围包括受控系统和属性环境，如图2所示。受控系统是指可以对其实施UCON策略的组件。每个受控系统通过执行特定操作来请求访问资源，并与UCS进行通信。这些组件即为策略执行点（PEPs）。有关UCON的更多详细信息，读者可参考[10]。

UCS拥有以下自身组件[16]：

• 策略决策点(PDP) ：该组件将访问（使用）请求和访问（使用）策略作为输入，返回以下决策之一：允许、拒绝、不确定。
• 策略信息点(PIPs) ：这些组件用于获取与收到的访问请求中的主体、客体和环境相关的属性。每个PIP充当UCS与特定属性管理器之间的接口。每个PIP针对特定的应用程序、AM以及应检索的属性类型都有定制的实现。
• 会话管理器（SM） ：该组件是一个数据库，用于存储所有活动会话以及执行策略重新评估所需的必要信息。
• 上下文处理器(CH) ：该组件是UCS的核心，负责在各个组件之间路由消息。首先，它必须将访问请求转发给各个PIPs以获取属性，然后将完整的访问请求发送给PDP，并最终将决策结果返回给PEP。最后，当PIPs通知某个属性值发生变化时，CH会接收该通知，并将新值转发给PDP以进行策略重新评估。

UCON框架包含以下操作[9]：

• TryAccess ：该函数由PEP调用，向UCS发送执行操作或访问资源的请求，以便根据策略进行评估。UCS将返回允许或拒绝的决策，并在必要时从策略信息点收集所需的属性。如果响应为允许，则该响应还包含即将开始的会话的会话ID。
• StartAccess ：此函数由PEP调用，并将SessionID作为参数。这标志着所请求服务的实际开始使用。PDP会再次进行评估，收到肯定响应后，CH将向SM确认该会话为活动状态。
• RevokeAccess ：如果可变属性更改了其值，PIP会将其发送给控制处理器进行重新评估，因为这可能会改变策略决策。如果发生此事件，则必须撤销访问。控制处理器通知PEP和SM该会话已被撤销。一方面，SM将该会话记录在案但置于非活动状态，另一方面，PEP阻止对该资源的访问。
• EndAccess ：当资源使用终止时，将调用此函数。UCS接收到该调用后，会从SM中删除会话详细信息，并通知策略信息点（PIPs）与该策略相关的属性不再需要保留，除非其他会话仍在使用这些属性。

3 在MQTT中引入UCON

在本节中，我们提出所建议的架构，首先介绍模型，然后介绍操作流程以及实现过程。

3.1 系统模型

如前所述，MQTT协议基于发布/订阅模型，因此参与该协议的实体可以作为发布者或订阅者。发布者可以是传感器或其他设备，用于收集并提供特定数据，这些数据可定期或以流的形式在可用时提供。订阅者则是向代理注册以接收特定数据或按主题分组的信息集合的实体，当数据可用时即可获取。代理充当中间件和协调者，管理订阅请求，并在产消者提供数据时将其分发给订阅者。

MQTT协议支持发布者和订阅者的基于ID和密码的身份验证。该认证机制由代理端执行，代理会记录已授权的发布者和订阅者的ID及认证密码。然而，我们认为这种认证模型过于简单且粒度较粗，无法检查随时间变化的信息访问权限。事实上，一旦订阅者被授权，其订阅将持续有效，直到该订阅者显式调用取消订阅其所注册的主题为止。发布者同样如此，只要其凭据仍然有效，就一直保有持续或按需发布的权利。在实际应用中，多种因素可能导致订阅需要失效，或出版物被拒绝。例如检测到发布者故障或损坏、订阅允许的时间跨度限制、以及订阅者信誉等，都是需要实施更复杂策略的一些方面。为了能够执行包含上述类似条件的策略，并具备撤销订阅的可能性，已在MQTT逻辑架构中引入了使用控制。

在图3中，我们展示了所提出框架的逻辑架构。如图所示，UCS在物理上集成在代理设备中，即物理运行代理软件的机器，该软件支持MQTT协议。值得注意的是，在本示例中我们考虑了三个抽象的策略信息点（PIPs），它们在概念上将读取与主体（PIPS）、资源（PIPR）和环境（PIPE）相关属性的策略信息点进行分组。PEP被（部分）嵌入到代理中，以动态控制订阅事件。具体而言，PEP将拦截订阅事件，并直接与代理的订阅管理器交互，根据UCS的决策从授权订阅者列表中删除或插入订阅者条目。通过这种方式，PEP确保没有订阅者可以在不执行使用控制策略的情况下完成注册。由于PEP嵌入在代理中，所提出的架构仍与任何MQTT订阅者的实现保持兼容。唯一的要求是订阅者必须配置用户名和密码进行访问，否则连接将被代理拒绝。

3.2 操作流程

在图4中，我们报告了设想的工作流程。为了简单起见，我们将考虑一个由代理和单个发布者及订阅者组成的简单系统。

工作流由订阅者向代理发送的订阅请求启动。该请求被PEP截获，PEP对其进行解析，以获取创建并向UCS发送评估请求所需的订阅者凭据。因此，PEP调用TryAccess，向CH发送请求和策略。请求最终被填充通过PIP检索到的属性，然后与策略一起发送给PDP进行评估，PDP应返回允许或拒绝的决策。如果决策为拒绝，则订阅请求被丢弃，并通知订阅者，就像输入了错误的用户名/密码一样。如果决策为允许，则会话管理器（SM）创建会话，并将该会话的ID发送给PEP（通过CH），PEP收到此决策后执行开始访问。假设已收到允许决策，代理会通知订阅者订阅成功，并在有数据可用时开始发送与主题相关的数据，最终唤醒处于空闲状态的发布者。

为了说明撤销工作流程，我们假设与订阅者策略相关的某个属性发生了值的变化（OnAttributeUpdate）。这会导致策略信息点（PIP）将该新属性发送给控制处理器（CH），CH再将其转发给PDP进行重新评估。假设该属性的值导致得出必须撤销此会话的结论（拒绝决策），则控制处理器（CH）将在PEP上调用RevokeAccess，同时通知订阅者其访问权限已被撤销（RevokeAccess）。访问的终止也可能发生在订阅者不再对数据感兴趣并调用取消订阅（Unsubscribe）的情况下。取消订阅将触发PEP向CH发送EndAccess。后者通知PIP获取该属性的最新值（PostAttributeUpdate）。此外，UCS还会通知代理该订阅者已不再订阅，并强制执行取消订阅操作。同时，SM也会收到通知，表明此会话已结束，相关记录应被归档或删除。最后，如果认为该订阅者是唯一对发布者感兴趣的一方，则代理会通知发布者停止数据发布，因为此时已没有任何订阅者的兴趣存在。

我们指出，将情况简化为单个发布者/订阅者并不会影响普遍性。事实上，该协议并未被修改，且多个订阅者/发布者不会引入任何额外的关键问题，因为并发在UCS和MQTT中原生支持。

3.3 实现

如前所述，UCS是一个基于Java的可配置框架，易于集成到任何具有Java运行环境的系统中。用于实现代理的软件是开源MQTT代理Moquette。尽管Moquette不像Mosquitto代理那样被广泛使用，但由于Moquette与UCS框架基于相同的编程语言，因此更容易与其集成。该代理已部分修改，以在其内部包含PEP功能。特别是，通过挂钩订阅处理方法来拦截订阅请求，从而调用TryAccess和StartAccess并在允许或拒绝订阅之前等待结果。如果收到拒绝决策，代理将向订阅者返回错误的用户名/密码消息。

图5展示了我们测试平台的架构。在一个树莓派（图5中央）上，我们运行包含PEP和UCS的代理，二者以JAR文件形式存在。订阅者和发布者的代码在不同的树莓派上未经修改地运行。此外，还通过将订阅者托管在一个名为MyMQTT的Android应用程序中进行了额外测试，该应用可通过谷歌商店获取。因此，订阅者代码几乎可以完全在与发布者相同的设备上执行。此外，发布者也可以是一个小型传感器，将数据发送给代理，如图5所示。由于该框架具有通用性，这些配置中的任何一种都不会影响其功能，也无需对框架进行任何修改。

4 结果

为了验证所提出方法的可行性，已在模拟环境和真实环境中测量了使用控制引入的开销。该框架已在两种不同环境中进行了测试：第一种是安装了Ubuntu 16.04 64位的虚拟机，配备启用了8核的Intel i7‐6700HQ处理器以及运行在2133兆赫兹的8GB‐DDR4内存；第二种是树莓派3，搭载运行频率为1.2吉赫兹的博通ARMv7四核处理器和运行频率为900兆赫兹的1GB的LPDDR2内存，使用官方Raspbian操作系统。发布者和订阅者分别安装在另外两台树莓派上。

完整的结果集见表2。所有数值均为在每种设置下对框架进行10次运行所计算出的平均时间。第一列描述了各项时间指标的名称，单位均为毫秒。第二列描述了使用树莓派时的时间，第三列描述了使用台式机时的场景。

事件时间（毫秒）	树莓派	桌面
总尝试访问时间	770	91
总开始访问时间	169	26
总订阅时间	969	121
UCON订阅部分	939	118
MQTT订阅部分	30	3
总结束访问时间	211	27
启用UCON的取消订阅时间	213	27
未使用UCON的取消订阅时间	2	0
代理中的撤销持续时间	216	27
UCON上的撤销持续时间	455	41

在表2中，报告了考虑包含单个属性的策略时的详细时间数据。图6和7展示了策略中所用属性数量增加时的性能变化。如图所示，由于需要更长时间来收集更多数量的属性以及PDP执行评估所需时间的增长，时间开销几乎与属性数量呈线性关系，这是符合预期的。然而，在实际情况下，即使考虑40个属性，时间开销对于大多数应用而言仍然是可接受的。此外，值得注意的是，包含多达40个属性的策略在实际情况中非常少见[15]。

正如预期，树莓派的计算能力较低，加上MQTT组件之间存在真实网络，导致其耗时比模拟环境更长。然而，即使考虑到上述通常情况下的有限属性数量，开销也略大于1秒。

考虑到订阅时间，我们发现UCS带来了一些开销。这并不被视为一种限制，因为代理提供了缓冲区，我们仍然可以在请求时间和订阅者实际接受时间之间发送所有已发布的消息。这不会造成数据包丢失。

发送给订阅者并提供高服务质量。此外，最重要的是撤销时间。实际上，这是策略被违反的时间，应尽可能缩短。如图所示，在实际用例中，此时间为216毫秒，在虚拟机中为27毫秒，假设策略仅包含单个属性。对于许多应用而言，该时间可以忽略不计。如图所示，从获取非有效值到访问撤销之间的时间非常短。

最后值得一提的是，在正在进行的阶段，即成功执行StartAccess之后，UCON在向订阅者传递消息时不会引入任何延迟，且该延迟与属性数量无关。

5 相关工作

物联网是一种涵盖从电子健康到工业控制等应用的范式。物联网架构是面向资源受限设备的分布式架构。这些设备的不同特性使得安全机制的引入非常困难，尤其是在需要动态策略（重新）评估的情况下。尽管UCON在网格[16]和云[2]系统中已有应用，以及另一个针对安卓移动设备的应用[11]，但目前仅有一个面向物联网的应用[15]，其中作者提出了一种标准使用控制框架的改进版本，称为UCIoT旨在将UCON引入物联网架构。该架构设计为无缝、可配置且动态的。然而，作者并未考虑任何特定的物联网协议。我们所提出的与MQTT扩展的集成以及进一步的评估，可被视为一项有价值的扩展。

在[19]中，作者提出了EventGuard以保护一般的发布/订阅覆盖服务。EventGuard是一个可靠的框架以及一组用于保障此类服务安全的防御机制。它包含一系列防护组件以增强安全性。但他们的解决方案并未针对MQTT，而是面向此类协议的通用方案，这意味着其并未针对物联网的资源受限设备和协议。

[12]的作者提出了一种保护智能维护服务的安全解决方案。他们的目标是主动预测并优化设备维护人员在客户侧部署的工业设备上执行的维护、维修和运营（MRO）流程。他们聚焦于MQTT路由信息资产，并针对客户端认证定义了两个基本安全目标。该方案基于传输层安全（TLS），而TLS已是该协议的基本功能。他们提出了如何更高效地将其作为硬件组件使用的方法。尽管他们声称性能影响并不显著，但在物联网受限环境中，增加额外的硬件组件可能是关键问题。

针对保护MQTT安全的最重要努力是其一种变体，称为SMQTT[18]。该方案在现有MQTT协议基础上增加了安全特性，基于轻量级椭圆曲线密码学的密钥/密文策略属性基加密（KP/CP‐ABE）。这种轻量级属性基加密会因时间和计算能力带来额外开销，在物联网受限环境中尤为显著。此外，我们的解决方案仅在代理上使用计算能力，而代理默认具备比发布者和订阅者更充足的计算能力。然而，他们的实现需要特定的发布者和订阅者来解密数据，而我们的解决方案对发布者和订阅者完全透明，无需其感知，且可与任意类型的发布者或订阅者协同工作。

6 结论

物联网协议的当前安全机制主要集中在确保消息机密性、完整性和认证等标准安全属性。据我们所知，迄今为止针对策略执行的研究努力仍然十分有限，而策略执行能够提供更加灵活、丰富和有效的安全特性。本文提出了一项初步研究，旨在通过实现使用控制策略的动态执行来增强MQTT协议的安全性。我们提出了一种通用方法，能够无缝集成UCON，且无需对协议进行修改。同时给出了实际实现方案，并通过性能评估验证了该方法的可行性。

作为未来的工作，我们计划在具有更多属性的更大测试平台上测试所提出的框架，以定义和实施更复杂的策略，并可能在实际应用环境中进行评估。此外，我们指出，所采用的方法可以轻松扩展到其他物联网应用协议，在这些协议中，集成的好处值得在未来的研究中进一步探讨。