SRUP协议增强和改进

Posted 2021-01-21 dujinxi

SRUP协议扩展和增强

Andrew John Poulter Steven J. Johnston and Simon J. Cox

英国南安普敦大学环境和工程系

摘要：这篇论文基于此前一篇介绍安全远程升级协议（SRUP）的论文。SRUP是一种应用于物联网命令和控制应用的安全通信协议，它基于MQTT协议。这篇论文在原有论文的基础上增加了一系列新的信息类型，提升了协议的能力。我们还探讨了网络中物理设备与逻辑设备标识对应问题，并在协议中提出了解决机制。

1.引言

在我们之前的论文中介绍了SRUP协议，它是物联网设备的命令和控制协议。该协议主要解决软件升级的鲁棒性和安全性问题。

这篇论文，我们在原协议基础上增加了集中信息类型来增强协议的功能，特别是解决设备身份识别问题。

第3部分介绍了对原有协议的增强，主要是解决之前存在的身份识别问题。第4部分提出了物联网系统初始密钥交换问题，并提出了解决方案。第5部分讨论在物联网和SRUP环境下的身份证明问题。第6节讨论密钥废止问题，第7节描述了针对系统的一些潜在攻击，以及应对措施。第8节描述了一种使让人更直接地识别密码身份的技术。最后，第9节描述了协议初始实现的测试和计划的未来试验。

2.背景

近年来，随着物联网设备的规模不断扩大，这些设备逐步沦为僵尸网络的肉鸡。他们利用这些肉鸡来策划DDOS攻击。这些攻击行为暴露出许多物联网设备在设计方面的严重安全漏洞，比如硬编码的口令，设备软件缺少安全升级，不安全的网络配置等。SRUP协议的主要目的和动机就是为物联网设备远程命令和控制提供安全可信的机制，将攻击面尽可能降到最低。

SRUP协议设计中充分利用了现存的开源商业软件和开放的标准。它吸收了众多常用的互联网通信协议的优点，但把这些有点组合起来，为物联网设备、自主系统和其他相关平台提供了一套完整的用于命令和控制的协议。

物联网设备通信架构有好多种；其中最广泛应用的是发布/订阅模式。在物联网设备中用的最多的发布/订阅协议就是MQTT了。

MQTT是一个轻量级的使用代理的发布/订阅协议，起初是由Andy Stanford-Clark（IBM）和Arlen Nipper（Arcom)1999年开发的，用于油气行业的轻量级遥测传输。2013年MQTT成为OASIS标准。所有的信息都通过代理发送；代理负责追踪所有订阅者，当发布者发布一条信息后将其转发给所有的订阅者。MQTT协议是基于TCP/IP协议的，其传输层使用TCP协议。

MQTT支持所中服务质量配置。追求最小开销，可使用QoS 0，它提供无保证的交付服务。然而，对于很多物联网应用，尤其是部署在条件受限或者连接比较脆弱的设备，QoS 1（至少1次送达）提供了一种非常好的方法，确保命令和控制信息发送/接收，同时数据传输开销仅稍微增加一点。QoS 1要求MQTT应答所有收到的信息，通过使用发布应答信息（PUBACK）。MQTT也支持QoS 2（只一次送达）：尽管需要MQTT三次数据交互。对第3部分介绍的SRUP信息增强而言，这QoS 2这种有保证的服务是不需要的。

QoS 1 和QoS 2都是在MQTT层次实现的，并且由MQTT客户端自动执行：因此，不同的QoS可以在不同的情况下实现，而不需要改变SRUP协议。

MQTT默认情况是不是一个安全的协议（所有数据以明文传输）--但是，它可以是使用传输层加密（TLS）来确保安全。

有许多开源的MQTT代理应用，在我们的研究中采取用了Mosquitto代理。Mosquitto实现了MQTT协议的3.1和3.1.1.版本。

MQTT在物联网领域应用广泛。很多通用平台都支持MQTT协议（包括Arduino和mbed）；并且大多数编程语言也支持MQTT协议。并且也有很多可用的MQTT客户端，包括命令行工具和图形界面的应用。也有很多适用于移动端的客户端应用，包括ios和android。MQTT被亚马逊网页服务（AWS）应用于物联网平台。

SRUP是基于MQTT的协议，在MQTT信息的有效载荷部分提供高效的二进制结构的信息。SRUP是为物联网命令和控制信息设计的通信协议。它既提供信息源认证也确保信息内容完整。

3. 对原有协议的改进和增强

3.1重放攻击漏洞

SRUP的最初版本针对发往设备的命令和控制信息恶意篡改、欺骗提供了很好的安全性。通过对SRUP所有信息加密签名，信息的任何一部分被篡改都会导致签名校验失败。通过使用安全哈希算法（SHA-256）来验证取回文件的完整性，协议可以为软件升级提供额外的保护。

然而，这仍然是实现中的一个潜在的漏洞：即重放攻击的威胁。重放攻击是指攻击者截获一条信息，并且在将来重传该信息，让接收设备重复之前的操作。在SRUP协议的最初版本中（只实现了升级消息），与此相关的风险较小：攻击者最多只能让设备下载一个合法的升级包。然而，如果足够耐心，截获初始化信息信息和第二次升级信息后，攻击者理论上可能让设备回滚到之前的版本。攻击者甚至有可能不断发送升级信息，让设备进行同一次升级来对特定设备实施拒绝服务攻击。可以清楚的看到，随着协议信息类型的不断增加，重放攻击对设备可能造成的损害不断增大。

3.1.1. 解决重放攻击的一般方法

解决重放攻击的一种常规办法是在通信中引入一次性的随机元素 （例如，HTTP中使用的“Basic”认证）--这样对一条消息的回复对其他的连接是无效的。然而，由于SRUP协议使用的最小交互模型，这种方法至少需要额外交换两种信息。例如，已有的初始化消息后（发往目的设备，含有服务器的会话令牌），设备需要发送一个初始化响应消息（包含会话令牌，和一个唯一的设备令牌），之后服务器会发送第二个消息，确认初始化（包含两个令牌）。这与SRUP的最小流量负载的设计初衷相违背，尤其是当设备网络受限时。

另一种常用的解决办法是增加一个精确的时间戳（这是Kerberos网络认证采用的办法），但是这要求所有的设备都可以连接到一个非常精确的同步时间信号。考虑到物联网设备的网络环境，这种方法很难实现。

SRUP可能采用更简单的解决方案：即要求每个设备记录收到的所有令牌,(仅局限于正确签名的消息中包含的令牌，防止暴力攻击导致存储溢出),并要求设备检测新收到的令牌与已接收到的都不同。SRUP使用UUID生成会话令牌:128位长度,保证对于给定的服务器实例标识符唯一。所以设备需要将令牌(潜在的大量的)写入永久存储中，防止列表因重启而被重置。

这种方法不太适合，因为存储开销可能非常大。每个令牌是16字节，所以即使在考虑其他存储开销之前，512个令牌将消耗8Kb的存储空间。对于没有文件系统的嵌入式设备，这就需要使用EEPROM模块(这些模块通常提供64-512kb:相当于4096 - 32768个令牌)。

3.1.2. 一种基于序列ID的方法

在SRUP中解决重放攻击的方法是使用基于序列ID的方法:在概念上类似于LoRaWAN协议[12]中使用的方法。采用这种方法需要在所有SRUP消息中增加一个额外的值(一个序列ID)。一个64位(8字节)的序列ID已经足够了(64位允许一个系统每秒使用1,000,000条消息运行超过580,000年才会溢出)。为了节省SRUP消息中的空间，最好采用更小的长度(例如，6字节的序列ID——仍然允许每秒100,000条消息，持续89年)。然而因为6-byte整数不是标准尺寸，我们需要实现自己的6-byte整数类型来处理这个值,尽管这在大多数语言中很容易实现,考虑到,即使采用6字节整数对整个消息长度的影响小于 1%，因此这样做没有价值，所以最终采用标准的64位整数(如uint64_t或无符号长整数)作为序列ID。

在实现中，服务器和设备都用相同的方式处理消息。无论什么情况下，发送方都将在本地永久存储中存储最近发送消息的序列ID，以后每发送一个消息序列ID值自动增加1。

设备必须存储从服务器接收到的最后一个消息的序列ID——协议要求此后从该服务器接收到的消息序列ID大于设备存储的序列ID，任何小于或等于先前接存储序列ID的消息都应该被丢弃。

由于在SRUP协议中，设备只能接受来自服务器的消息(协议不支持点对点消息传递)，设备需要为正在通信的每个服务器存储一个这样的值(在文件系统或EEPROM这样的永久存储中)。由于序列ID相对较小，这意味着即使是使用基于微型微控制器的硬件实现的设备，存储也没有问题。例如，对于128个64位的序列ID而言，仅1 kb的存储空间就足够了(这意味着任意时间，都有128个不同的命令和控制服务器同时运行，这大大超出任何实际应用程序的需求)。

在服务器端，可以认为没有存储问题。这种方法要求服务器保留与所有设备通信的最后一个序列ID(直到设备从系统中删除)。即使是一台拥有1亿台设备的服务器，其当前序列id的存储空间也不足800Mb:对于任何基于云的服务器实现来说，这都是微不足道的。

SRUP协议已经更新，为所有消息类型赋予了8字节(64位)序列ID值;如从发送方收到的新消息的序列ID小于存储的序列ID，则拒绝该消息。

3.1. 执行确认

在最初的协议中，没有规定服务器确认设备成功接收并执行SRUP_ACTIVATE消息的行为;因为我们假设服务器能够通过其他(非协议)途径识别执行行为。为了保证协议的完整，现在增加了这个功能。

这个功能可以通过增加一个消息类型来实现（比如SRUP_MESSAGE_TYPE_ACTIVATE_RESPONSE），这种消息类型与已有的SRUP_MESSAGE_TYPE_RESPONSE消息结构类似；一种更好的选择是使用现有的消息类型，只不过对之前定义的两种状态增加两中新的回复即可。改进版的协议采取了这种方法。

为与协议改进的思路保持一致，即减少消息类型。这有助于保持协议简单，便于实现,同时提供所必需功能。

3.2. 发送者ID

SRUP的最初版本 : 假定没有必要要求消息的发送方提供细节信息,因为协议是集中控制的，它意味着消息总是对应的从一个服务器到设备,或从一个设备到服务器。设备的标识将包含在承载消息的MQTT消息中; 并且假定接收消息的设备可以确认消息来自服务器。

使用MQTT主题来传递源/目的地信息的模式，意味着不需要在消息中添加发送者信息。然而，在同时使用多个C2服务器的情况下，接收消息的设备无法知道是哪个服务器发送了消息，该使用那个公钥验证签名。

这个问题有三种可能的解决方案。最简单的方法是，接收者依次尝试它拥有的每个密钥。然而，这既不是可扩展的，也不好的解决方案:因此可以放弃。

另一种选择是使用MQTT主题层次结构来表征发送方。例如，与其订阅SRUP/dev0x01—设备和服务器可以订阅SRUP/dev0x01/#(使用MQTT主题通配符#)。这将允许来自设备的消息使用更高级别的主题，来自不同服务器的消息使用子主题(例如SRUP/dev0x01/sv0x2F)来表示它们的源。然后，接收设备可以解析MQTT消息的主题字段，以提取发送方标识。

第三个方法是在SRUP消息中包含一个额外的字段(即常见的一部分——组成的所有消息头,序列ID、签名和令牌)即发件人ID。使用这种方法接收者可能很轻易的找到发送者，但它的消息流量开销也是最大的。假设每个设备ID是一个128位的UUID，那么消息长度将由282字节(2字节的头,16字节的令牌,8个字节序列ID, & 256字节的签名,假设PKCS # 1 &a2048-bitkey)变为 298字节，增加大约6%。与使用MQTT主题层次结构表征发送方的方法相比，这种方法更好。因此SRUP协议选择了这种方法。

3.3. 目的寻址

鉴于MQTT发布/订阅模式的性质,所有发送的消息在一个指定的主题传递给所有用户。在有多个C2服务器订阅同一个特定频道的系统中，也存在目的寻址问题。在很大程度上，这不是协议需要解决的问题，而是管理复杂的C2关系的系统实现问题。有很多方法可以解决多C2服务器问题:军事领域内就有很好的例子(例如消息类型隔离,积极转移命令,上级和下级的分层方法):或者控制权简单的从一个服务器转移到另一个，从而避免设备同时连接多个C2服务器问题(即：确保在任何时候只有一台C2服务器订阅了特定的设备主题)。在这种情况下，使用发送方ID的方法就足够了。

使用MQTTs发布/订阅模型的优点之一是，消息可以轻松地同时发送到多个接收方。例如，C2服务器可以组建一个设备组:事先确定，或者在将来使用SRUP_MESSAGE_TYPE_GROUP_ADD消息类型动态构建。在组中，通过一条C2消息可以向该组中的所有设备传递指令。这都可以在不需要使用其他目的寻址方式的情况下实现。

在未来的SRUP协议版本中，发件人ID将被新增的目的ID值所取代，这与底层的TCP网络协议保持一致。但与低层协议不同的是，它不需要解决路由问题。这是因为集中的MQTT代理和发布/订阅模型为我们解决了这两个问题。此外，SRUP是一种集中C2模式，它不允许设备到设备直接消息传递，因此不需要路由。

但是，应该注意，在某种程度上，SRUP确实使用了目标ID的概念:因为Update Initiate message有一个目标ID字段。但是，这是一个例外:因为它强制在设备和Update Initiate message是之间一对一对应。有一项要求是确保设备特定的有效载荷传输有保证(这一要求是与协议的潜在用户，即军事和安全关键应用程序领域用户，对话时提出的)。

3.4. 使用SRUP传输应用程序数据

在许多情况下，物联网设备可能希望以安全且经过身份验证的方式向用户发送特定应用程序的数据。对于这种情况，可以使用SRUP协议将签名的应用程序数据消息从设备传递到C2服务器，以便分发给用户。

解决这个问题的方法是创建一个新的SRUP消息类型(SRUP_MESSAGE_TYPE_DATA)，专门传递应用程序数据。此消息类型将包括以下字段(除了基本消息字段之外):

?DATA_ID是一个可变长度的字符串，用于指示在消息中发送的数据。

?DATA是一个可变长度的字节流。可以假设使用SRUP的应用程序(即设备和服务器软件)能够根据DATA_ID的值确定映射这个字节流的正确数据类型。应用程序还将被认为能够正确地处理数据的字节顺序问题。

?由于每个字段都是可变长度字段，所以SRUP消息还需要指定这些字段的长度。

DATA的特定含义和DATA_ID是取决于系统和应用程序，因此应用程序或系统开发人员可以将其用于任何目的。

鉴于该消息类型是传递数据的，它增加重放攻击的潜在威胁,为了防止重放攻击,这类消息也采用了本章其他地方所描述的安全措施。

3.5. 使用SRUP启动应用程序特定动作

除了SRUP数据消息(第3.5部分)之外，SRUP还可以用于启动应用程序特定操作。一个简单的例子可能是使用动作消息来开关连接的外设。

这可以通过添加一个新的消息类型(SRUP_MESSAGE_TYPE_ACTION)来轻松完成，该消息类型由“基本”消息和ACTION_ID字段组成:该字段需要一个特定于应用程序的值来描述要执行的操作。每个操作都是一个简单的原子操作，例如打开或关闭设备。因为这样两个不同的操作id需要覆盖二进制操作(例如打开和关闭)的两个部分。

ACTION_ID作为字节流发送，因此它可以由字符串或使用数值组成。接收方可以选择发送SRUP_MESSAGE_TYPE_RESPONSE消息来表示操作的结果。收件人不知道的操作ID值的消息应该被忽略;尽管收件人可以选择发送状态值反映未知动作的响应消息。

对于需要额外参数数据的更复杂的操作，可以使用SRUP数据消息(第3.5节)在开始操作之前发送适当的数据。

使用这种方法可以简化操作消息，并有助于减少发送的数据量。通过这种方式，只在需要的地方发送额外数据，而不是将数据指定为动作消息的参数的模型。

虽然这个消息类型可能被认为模糊了系统的“管理”信息和“操作”消息，不难想象那样的场景，通过这种信息C2服务器安全的远程操作设备非常重要: 例如激活紧急设备上的紧急按钮。在这种情况下，与其扩展核心协议，或在协议规范中指定大量此类消息，不如提供一种客户自定义消息。这种方法意味着任何人都使用SRUP实现一个系统都能够轻松地调用这些类型的消息。如果协议使用的语言不是c++，那么这一点尤为重要。尽管到目前为止实现的示例都是直接使用c++的，但最终还是希望提供通用库，以便从Python中直接调用。

3.6. 追加的HTTP错误处理

最初版本的SRUP协议仅提供了一个信号,用于表示在获取更新文件过程中HTTP服务器发生了错误。改进协议可以进一步提供错误的具体信息:对于特定的系统或实例，这是可选部分。不仅是SRUP_MESSAGE_TYPE_RESPONSE消息提供的错误状态，而是添加了进一步的响应类型(SRUP_UPATE_FAIL_HTTP_ERROR），将表示HTTP错误的信息将封装为两个单独的SRUP数据消息，包含HTTP状态代码和服务器响应的内容。

3.7. MQTT加密

如本文所述，TLS加密的MQTT可以替代MQTT的纯文本实现。为了获得最大的安全性，可以使用MQTT / TLS实现，使用ITU X.509证书认证方法[13]。虽然这可能会增加额外的处理开销(这可能不太适合围绕低功耗微控制器设计的非常简单的设备)，但这是一种方法，可以为需要的应用程序和系统提供设备和服务器之间连接的完全端到端安全性。随着像Espressif ESP32[14]这样的现代微控制器现在完全支持TLS，甚至在不久的将来低功耗的设备将能够充分利用这种方法。

4. 密钥分发

4.1. 背景

密钥分发的安全和安全机制对于确保由这些密钥保护的任何消息的完整性至关重要。非对称或公开密钥加密通过将密钥分为公共和私有部分来解决这个问题。这将问题简化为一个交换非秘密公钥的问题，只需要保护这些密钥的完整性(从而保证其可靠性)。在实现中，通常使用RSA等算法间接加密用于加密实际数据的对称密钥;或者签名数据的安全哈希，而不是完整的数据本身。

这是在SRUP新协议中采用的方法，通过对消息的SAH-256哈希值进行签名来保护消息，以确保消息在传输过程中没有被篡改。如果设备有服务器的公共密钥的副本，它就可以验证它接收到的任何来自该服务器的消息。类似地，来自设备的任何消息都可以通过服务器持有的设备公钥的副本进行身份验证。

而非对称RSA密码算法通常被认为是安全的[18]，并通过使用安全套接字层(SSL)(现在由于安全漏洞[19]很大程度上被废弃)或最近的安全传输层安全(TLS)[6]来保护大量的互联网流量;在设计不佳的密钥分发过程中，仍然存在向中间人攻击的风险。

如果恶意的第三方能够拦截密钥交换消息，则该方可以提供自己的证书来替代真正的证书，以便将服务器模拟为设备，并将设备模拟为服务器。

尽管这样一个第三方无法接触私钥，但仍然可以成功地欺骗设备，让设备认为其与真正的服务器通信:因为没有其他措施，比如密钥签名,设备不知道取回的公钥是否属于真正的服务器。

4.2. 身份和物联网

设想一个使用SRUP的物联网系统:由互联网上的C2服务器和服务器控制下的一个或多个设备组成。为了执行设备的初始注册，系统需要在服务器和设备之间交换4条信息。

1. 设备需要知道用于传递消息的MQTT代理的地址

2. 设备还需要知道服务器的公钥，以便验证来自服务器的消息

3. 服务器需要知道设备的标识

4. 服务器需要知道与设备标识相对应的公钥

这个设备标识对应于使用Boost[20]生成的统一唯一标识符(UUID)。Boost uuids具有128位长度，足以在任何可能的系统避免冲突。由于SRUP使用加密密钥来确保消息的真实性，所以我们可以将具有给定标识定义为意味着所涉及的设备拥有与该标识的UUID相关联的公钥对应的私钥。

根据要使用的具体实现，设备标识可以由服务器分配(确保给定系统的唯一性)，也可以由设备本身生成——尽管这必须由服务器验证，以确保系统中的唯一性。一个随机生成的128- bit的uuid是不太可能导致冲突的(因此，这样的值被用作一个通用唯一标识符)，但是需要进行检查以防止对系统的蓄意冲突攻击。

4.3. 通过HTTPS安全Web服务进行密钥交换

协议提出的初始化注册过机制是为设备提供一个安全的超文本传输协议(HTTPS) URL，该URL地址指向用于安全交换数据的网站。通过使用TLS保护连接到web服务器，我们保护传输中的数据;由于TLS还提供了web服务器身份的证明，我们可以信任交换过程。通过使用这种机制，我们不需要解决SRUP中的密钥交换问题。TLS通过使用基于web的标准密钥签名:ITU X.509[13]解决了HTTPS连接的密钥交换问题。

密钥签名的概念在本质上非常简单。web服务器不是简单地生成自己的(“自签名”)密钥对，而是由受信任的第三方证书颁发机构(CA)签名其密钥;使用自己的可信密钥在密钥上签名。CAs密钥本身也由高级的中间CA签名，以此来创建信任链。最终，所有这些链的源代码中都有一个根CA证书;这些根证书授予所有从属的中间CA证书的信任。与这些根CAs相关联的公钥(通常)作为操作系统或web浏览器应用程序软件的一部分分发:因此可以认为它们已经存在于目标设备上。

由于HTTPS / SSL / TLS为我们提供了这个功能，所以不需要在SRUP中重新实现这个过程。

将这种方法用于服务器密钥分发，我们只需要添加一个合适的证书和RESTful [21] HTTPS web服务到C2服务器或更广泛的系统:通过这种方法提供设备需要的数据,例如使用javascript对象表示法(JSON)格式。

4.4. 注册工作流程

注册过程可以在没有任何人员交互的情况下进行。设备连接到注册URL，在建立通信之后，它发送一个POST请求，以发送其身份、公开密钥以及特定系统需要了解设备的任何其他信息。服务器将包含将包含MQTT代理的URL和服务器的公钥的响应信息发送给注册设备。存储服务器密钥和URL的机制与具体设备有关(例如，文件系统，闪存，电可擦可编程只读存储器);但是在服务器端，这些信息应该存储在一个适当保护的私有数据库中。

在没有预处理措施的情况下，任何设备都可以收到注册请求。在系统上注册一个设备并不会在该设备和服务器之间建立任何特定的关系;它也不赋予设备任何信任。因此，向C2服务器注册一个或多个设备的攻击者对系统的操作影响很小。考虑过滤设备注册请求的唯一原因可能是攻击者试图通过发送大量虚假的设备请求来干扰web注册服务器，以实现拒绝服务(DoS)攻击。

防御这种攻击的方法是采用一种成熟的机制即:服务器端负载平衡(即包括web服务层，也包括存储标识的底层数据库)。对于设计良好的系统(例如基于微服务的体系结构的系统)，即使对web注册服务进行有效的DoS攻击也不会对C2服务器持续运行产生任何影响。

4.5. 传递注册URL

如果我们与设备有物理连接，那么将注册URL传递给设备就非常简单。它可以硬编码到设备中，或者我们可以手动输入完整的URL，或者使用公共或私有URL缩短服务(当然，假设我们信任这样的服务)。我们还可以使用非文本编码的URL——例如在广告行业中使用的URL。例如，可以采用二维码或其他二维条码;或者可以通过近场通信(NFC)标签[23]或蓝牙低能量(BLE)[24]信标协议(如Eddystone[25])使用射频通信。

对于在注册时不可能(或不需要)对设备进行物理连接的系统，我们需要回到硬编码的方法，即在设备的软件或固件中写入初始注册URL。作为一个整体解决方案，这显然不太可取，因为它限定设备只能在一个特定系统的环境中使用，但对于很多系统来说，这可能是很好的特性，因为它将设备锁死在系统中。

无论提供URL的方式是什么，在大多数情况下，注册过程将在设备部署之前进行。这意味着，即使设备部署后网络受限，但在注册操作时没有带宽限制，因此HTTP连接的额外开销不是问题。

这个过程完全发生在SRUP协议之外。

5.身份证明

5.1.加入一个系统

注册操作不同于设备随后的加入请求，因为它意味着成为特定服务器的从属，并受该服务器的控制。要执行这样的连接操作，设备将发送包含其标识的消息和证明设备拥有该标识的签名来启动流程。然后，服务器可以接受请求或者它可以要求设备通过第三方证明自己身份。一旦服务器接受请求，它就必须将对所属的设备进行编目，将设备标识存储在适当的数据结构中。

因为身份是通过拥有与该身份相关联的密钥对的私钥而授予的;设备可以通过这样一个事实来证明它们的身份:它们可以证明自己拥有这个私钥:例如，通过解密一个用公钥加密的验证令牌。

观察者可以验证设备，以证明它拥有声称的身份。方法是：C2服务器(分别)向设备和观察者提供加密的值，并请求观察者确认设备呈现的值与通过协议接收到的值相同。

具体机制将取决于系统和观察者的特征:它可以显示一个人类可读的值的表示(对于人类观察者);或使用其他通信信道将值传输给观察者。这种多通道的方法可以用在一个由自主移动平台设备构成的系统中，在这个系统中使用本地通道来确定移动设备出现在特定区域。

5.2.在SRUP中的实现

5.1节中描述的机制将在SRUP协议的未来版本中实现。假设注册过程已经发生(在SRUP的外部)，希望受服务器控制的设备将向服务器发出SRUP_MESSAGE_TYPE_JOIN_REQ消息，该消息由设备的标识和签名组成，以证明源的真实性。根据系统的不同，服务器可以直接将其控制组的成员资格授予设备，或者要求设备通过观察者提供额外的验证。注意，由于设备在连接操作时不属于现有的SRUP网络，所以SRUP消息需要通过与服务器ID相对应的MQTT主题发送:专门为连接请求保留。

是否需要这个额外的观察步骤，取决于系统实现的细节。但是，两个特定的用例可以代表SRUP协议的在真实应用中可能遇到的情况。

5.2.1.人在回路系统

第一个是有人工操作员的系统。这种情况下，当设备加入系统时，需要有可信的人工操作员在场——很有可能是传感器或者设备安装时。

在这类系统中，加入操作将与部署或安装的特定(预先知道的)设备同步操作。设备通过发送SRUP_MESSAGE_TYPE_HM_JOIN_REQ消息启动进程。

为此，服务器将发送SRUP_MESSAGE_TYPE_HM_JOIN_RESP消息:该消息将包含一个加密值(一个适当的随机选择的128位nonce值，使用设备的公钥加密)。在接收到此消息后，设备将显示解密后的数据，供人类观察者观察。通过这种方式，可信的人工观察者在与服务器(协议之外)的通信中:或谁自己在操作服务器，将能够比较服务器转发的标识与被观察和部署的设备呈现的标识。这使观察者能够确信所观察到的物理设备是请求连接的设备。根据设备(以及系统的性质和操作员的技术水平)的不同，这个过程可以用多种不同的方式实现。简单情况下，设备可以在显示器上显示解密后的值。

图1显示了人为加入连接操作期间信息流序列图。

以人类可读的形式呈现UUID的其他技术在第8节中进行了探讨。

图1.人在回路加入模式的序列

5.2.2.自治系统

第二个用例是请求连接的设备是一个独立的实体，因此在没有直接人工干预的情况下运行。例如，在这种类型的系统中，连接请求可以作为加入特定控制区域的自治设备的过程的一部分。

在这个更复杂的示例中，操作的一般模式是服务器以与以前相同的方式生成加密数据，然后请求另一个(已连接且受信任的)设备通过协议之外的点对点连接进行观察。例如,如果自主平台发出连接请求,说明它已进入受C2控制的区域，并与可信信标设备建立了点对点的连接。设备可将信标设备的身份纳入请求加入消息。然后，服务器向信标发送一条消息:包含它希望从设备接收到的值。连接设备一旦收到服务器的确认请求，它就会通过点对点链接将解密后的数据传到到信标设备，由信标设备检查两个值是否匹配，并将检查情况反馈至服务器。

在SRUP协议中，这可以通过让设备发送SRUP_MESSAGE_TYPE_OBS_JOIN_REQ消息来完成，该消息包含它自己的标识和观察节点的标识，并使用设备的密钥签名。

然后，服务器将生成一个128位的UUID值，以及一条SRUP_MESSAGE_TYPE_OBSERVE_REQ消息，该消息将包含该值的加密版本(使用观察节点的公钥加密)和一个签名。

服务器还会使用相同的方案将SRUP_MESSAGE_TYPE_OBS_JOIN_RESP消息发送回请求设备，包含确认值的密文，不过是采用该设备的公钥加密的。加入设备将被要求通过SRUP协议之外的方式，向观察节点证明其身份:例如通过短距离点对点的链接,然后观测节点会定期向SRUP服务器发送响应消息，包含一个状态值信号身份表明加入设备是否通过身份验证。

图2显示了一个序列图，描述了有外部观察者加入的消息流，同时还有一设备初始化、服务器初始化和退出操作。

 

6.密钥的撤销

密钥撤销是任何物联网系统中一个重要但经常被忽略的方面。然而，在基于C2服务器的方法中实现物联网系统是很简单的。需要考虑两种类型的撤销。

1.将C2服务器的所属设备移除，使其不再受该服务器的控制:同时将设备保留在更大的系统中;(这与加入操作相反);

2.设备从整个系统中永久性地移除;(与初始设备注册相反)

要从SRUP中的特定C2网络中删除设备:设备可能选择主动退出(通过发送SRUP_MESSAGE_TYPE_RESIGN_REQ消息):或者它可能被服务器终止(使用SRUP_MESSAGE_TYPE_TERMINATE_COM消息)。

如果退出设备被服务器断开连接，服务器将简单地从设备列表中删除与设备相关的记录。如果设备正在请求退出，那么服务器应该发送一个状态的响应消息，以表明是否接受退出;而且密钥也会一样被移除。

对于永久性(系统范围)取消设备注册，SRUP也可以使用——尽管初始注册发生在协议之外。数据交换基本上与退出/终止用例相同;但是对于SRUP_MESSAGE_TYPE_DEREGISTER_REG或SRUP_MESSAGE_TYPE_DEREGISTER_COM的消息类型:其结果将是设备的密钥被永久地从系统的密钥存储库中删除。

7. 潜在的攻击机制

在攻击者能够获得对设备的物理访问的情况下，可以假设，除非该设备被构建为使用加密存储和可信引导进程[27]，否则攻击者将获得对设备上存储的任何数据的访问权。在SRUP设备的上下文中，最重要的是，这等同于服务器的公共密匙和设备的私有密匙。因为根据定义，服务器的公钥是公开可用的(根据注册过程的要求，如果没有其他地方的话)，我们可能会在很大程度上忽略这一点，认为它对攻击者有用。但是，通过第4.2节中使用的定义，可以访问设备的私钥，这意味着攻击者可以获得设备的身份。因此，系统将允许设备发送的任何消息都可能被欺骗，并由攻击者可能设计的任何其他设备发送(并将原始设备的身份分配给它)。

虽然基于SRUP的系统没有试图提供一种机制来监控或检测这样的身份盗用,C2服务器模式的集中性质(没有点对点消息传递)意味着潜在的损害,可以引起的,身份盗用可能包含到服务器身份盗用。SRUP网络上的其他设备不受直接影响。根据定义，设备从属于服务器，因此通过欺骗设备消息造成的破坏很有限，除了直接干扰设备传感器的情况。如果检测到这样的攻击，可以取消设备的注册以取消其在系统上的通信能力。

虽然这种装置可以重新登记并取得新的身份;在人控制的系统中，如果没有人(系统信任的人)的帮助，它就不能加入服务器。即使在一个自动化的或无人控制的系统中，能够加入(或保留)一个控制组的成员资格，在前面的讨论中，对攻击者来说价值是非常有限的。

对任何C2系统的最大威胁是服务器的漏洞; 然而，SRUP采用的非对称加密方法意味着所属节点的泄露对服务器的安全性没有影响。

对系统最大的威胁是攻击者破坏信标节点;在这种情况下，攻击者将能够利用信标进行任何观察检查。尽管防止物理篡改的超出了SRUP的范围，但是应该注意的是，保护观察者节点不受物理损害对任何使用这种设备的系统的总体安全性至关重要。

8. 简单的人工比较UUID值的方法

对于一个依赖于人类比较的系统，有很多方法可以提供128位的数字。按照惯例，这些数字表示为32位十六进制值的字符串表示形式。当这些值以真正的uuid生成时，它们通常使用[28]中描述的8-4-4-4-12格式表示。考虑到这种格式的视觉清晰度，我们希望采用相同的方法来表示any128位值的16字节。在图3中可以看到协议使用的128位UUID的示例，以这种方式进行格式化。

这样的选择是最简单的方法来实现:一个小16×2字符,文本模式液晶显示器(LCD)适合显示这样一个值(没有断字)可能只添加3 - 4美元左右为设备材料清单成本;这种方法在适应于最基本的微控制器。

但是，需要仔细比较两个32个字符的十六进制值，这并不是一个特别用户友好的界面:它只非常适合有专业用户的环境。相反，可以采用其他选项来表示比较的值。关键的是，观察者能够识别出呈现给他们的潜在价值并不重要;而是要识别两个例子是否匹配或不同。

8.1. 图形化的表示

一种方法可能是现在的128位值的形式组成的人类可读的图形，包括12×12 144单色单元的网格。因为对于一个128位的值来说，这多出16个单元，所以我们需要使用额外的16个固定的“位”——例如在每个角落都放置一个2x2块。这样的图形的外观类似于二维码:虽然它是为人类识别而设计的，而不是机器的可读性。而尚未提出将这种UUID编码为单色图形的具体方案; 图4显示了这样一个图形的示例，与前面讨论的其他表示方法形成对比。

 

 

 

 

 

 

 

 

 

图4.一个黑的例子，12x12网格描绘了一个128位二进制值。

UUID值也可以是在8×8网格中表示。使用四种仔细挑选的颜色，保证产生足够视觉差异的网格，便于区分。避免那些对色盲患者来说不明显的组合。同样，虽然这种编码的尚未被纳入协议。图5显示了这样一种方法的一个示例(其中图中的每个正方形的内容由UUID中的两个位的值决定)，以便与所描述的其他方法进行比较。

 

 

 

 

 

 

 

 

 

 

图5.一个四色的例子，8x8网格描绘了一个128位二进制值

设备拥有屏幕并可以在其上显示这两种图形,同时显示在服务器的用户界面(如网页)后,注册过程就被启动了。

对于没有合适屏幕的设备，该设备可以与智能手机或平板电脑的连接，用来显示验证码图形。虽然这可能是更不安全,因为它增加了通道，同时增大了攻击面，这可能成为攻击者的目标。但由于BLE通信的距离有限和加入过程高度敏感,这意味着实际应用中风险并不大。

8.2. 单词表表示法

另一种方法是用从标准单词表中提取的单词生成的“短语”的形式表示该值;将128位值的多个部分映射到列表中的单个单词。

这种方法以前已经提出过，用于向用户显示加密密钥;但也可以很容易地应用于身份的表示。

例如，我们可以将128位的值划分为10,12位的片段，每个12位的碎片都被映射到一份4096不同的英语单词的列表中，从一个非常独特的单词列表中提取出来。一个合适的world-list(例如http://bit.ly/2d5S9AA)将被设计用来为用户提供产生高熵密码的机制。原始128位值的其余8位可以用256个额外单词中的一个来表示;或者使用同一个列表中的单词(并使用前面描述的用四个额外的“固定”位填充值的技术)。因此，用户将看到一个“短语”用于比较，以确保连接操作期间的身份。

  图6 显示了使用从这样一个单词列表中选择的单词来生成标识短语的示例。

这个短语呈现给用户的选项与同时呈现象形文字和文本字符串的选项类似——但屏幕更适合于显示简单的文本信息非常简单。

9. 成果和未来的工作

9.1. 成果

在2016年第三届IEEE世界物联网论坛上演示了一个初始协议试验台，并演示了更新消息的使用。这个实现由一个IoT C2系统组成:使用Mosquitto代理;一个树莓派 3作为示例设备，旁边是一个示例设备端守护程序和C2服务器。守护程序和服务器都是使用SRUP库、c++组件和Python脚本实现的:进程间通信使用Apache Thrift处理。虽然没有正式测试，但这个系统的性能已经足够了。演示更新消息的一个简短视频，可以在https://youtu.be/aKTODVEpI1w看到。

包捕获显示，最复杂的消息类型(更新初始消息)由SRUP数据的424-byes组成(包含一个33字节的URL);64字节的SHA-256摘要;和一个8字节目标ID;加上消息签名、消息令牌和其他协议开销)-以493字节的MQTT流量发送。即使是这种消息类型(最复杂的:比任何其他消息类型都包含更多的字段)传输也很容易，即使internet连接不可靠或缓慢。MQTT QoS 1的Thead选项(提供消息保证传递)添加了一个额外的MQTT PUBACK消息(使用IPv4时，长度为60字节)。

用于支持SRUP协议的加密函数在性能方面也非常高效，即使在相对低功耗的硬件上也是如此。到目前为止，该实现在Raspberry Pi 3上进行了测试，并使用OpenSSL提供了SHA-256摘要和RSA签名，执行得非常充分。在测试用例中，使用Raspberry Pi 3对代表性的SRUP初始消息进行签名和验证，平均运行5次;签名的平均时间为56.68毫秒;验证签名只花了9.91毫秒。

下步将继续以c++库的形式提供SRUP协议的完整实现。

9.2. 未来工作计划

一旦SRUP协议的所有特性的实现完成，计划进行一系列的实验，在实际运行中测试协议，测量其性能和可伸缩性，这是具有代表性的真实C2应用程序。

10. 结论

在本文中，我们已经展示了如何通过引入额外的消息类型来扩展SRUP协议，将其用作用于经过身份验证的物联网通信的通用协议。我们还提出了一些方法，可以用来为物理设备提供一种方法来证明它们具有与网络中的逻辑设备相对应的标识——使用人工或机器方法。

在doi://10.5258/SOTON/D0232中可以获得SRUP协议的完整描述和规范

库的最新版本的源代码以及设备端守护程序和C2服务器的示例实现都是根据MIT开放许可证的条款发布的。lates tversion可以在https://github.com/dstl/SRUP/找到。

致谢

这项工作由英国国防科学技术实验室(Dstl)资助。Dstl是英国国防部的一部分。