# Extensions and Enhancements to \"the Secure Remote Update Protocol\"
## 2 Background  
With the proliferation of IoT devices seen over the last few years, such devices have been the targets of those wishing to create networks of slave devices (so-called botnets, such as the one created by the Mirai malware [2]), with which to stage Distributed Denial of Service (DDoS) attacks. These attacks typically exploit serious security vulnerabilities in the design of many IoT devices, such as hard-coded passwords, lack of security updates to the device software and insecure network configuration (such as providing remote network terminal interfaces) [3]. The key motivation behind SRUP was to provide a secure and trustworthy mechanism for remote C2 operations on IoT devices; whilst reducing the attack surface to the minimum. The Secure Remote Update Protocol has been designed to exploit extant commodity open-source software and open standards. It takes advantage of existing and commonly-used protocols and techniques for Internet communications, but combines them in a unique and novel way to provide an integrated protocol to conduct C2 operations for IoT devices, autonomous systems and other related platforms. There are a number of communications architectures used to facilitate communications with IoT devices; one of the most commonly used is the publish/subscribe paradigm. Within IoT devices, perhaps the most commonly-used publish/subscribe protocol is Message Queuing Telemetry Transport (MQTT). MQTT is a lightweight brokered publish/subscribe protocol, originally developed by [PERSON] (IBM) and [PERSON] (Arom) in 1999 to provide lightweight telemetry for the oil and gas industry. It became an Organization for the Advancement of Structured Information Standards (OASIS) standard in 2013 [4]. All messages sent are routed via a broker; the broker is responsible for tracking all subscriptions and sending data to subscribers when a publisher issues a message. MQTT runs over Internet Protocol Suite (TCP/IP) networks, using Transmission Control Protocol (TCP) [5] as the transport layer. MQTT supports multiple Quality of Service (QoS) settings. For the minimum overhead, QoS 0 (defined by the MQTT standard [4] as \"at most once\" delivery) can be used, which provides no guarantee of delivery. However, for many IoT applications, especially those deployed in locations with austere or otherwise fragile Internet connectivity, QoS 1 (\"at least once\" delivery) provides an excellent way to ensure that C2 messages are sent/received, at the cost of a slightly higher data overhead. QoS 1 requires the MQTT to acknowledge all received messages, using a Publish Acknowledge (PUBACK) message. MQTT also supports QoS 2 (\"exactly once\" delivery), albeit at the cost of requiring a three-part message exchange within MQTT. Given the nature of the SRUP messages and the enhancements introduced in Section 3, this level of assurance is not required. Both QoS 1 and 2 are implemented at the MQTT level and carried out automatically by the MQTT client; so that different QoS may be implemented in different situations without needing to make any changes at the SRUP level. MQTT is by default an insecure protocol (all data are sent as plain text), but it can be secured with the application of Transport Layer Security (TLS) [6] to the traffic. There are a number of open-source brokers; this research has been carried out using the Mosquito broker. Mosquito implements the MQTT protocol Versions 3.1 and 3.1.1 [7]. MQTT is a very widely-supported protocol within the IoT. MQTT libraries exist for many common development platforms (including Arduino and mbed); and it is supported by the vast majority of programming languages. There is also a large number of clients available, both command-line tools and GUI applications. There are a number of clients available for mobile devices, as well, including clients for both iOS and Android. MQTT is also the protocol used by Amazon Web Services (AWS) for their IoT platform. SRUP is built on top of MQTT and provides an efficient binary message structure contained within the payload of an MQTT message.