ABSTRACT
This paper builds on previous work introducing the Secure Remote Update Protocol (SRUP), a secure communications protocol for Command and Control applications in the Internet of Things, built on top of MQTT. This paper builds on the original protocol and introduces a number of additional message types: adding additional capabilities to the protocol. We also discuss the difficulty of proving that a physical device has an identity corresponding to a logical device on the network and propose a mechanism to overcome this within the protocol.
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), 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). 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.
ENHANCEMENTS AND IMPROVEMENTS TO THE ORIGINAL PROTOCOL
The initially specified version of the SRUP protocol provides a good degree of security against a malicious party changing or spoofing the C2 messages that are being sent to the device. By using cryptographic signatures, applied over all of the data contained within the SRUP message, any part of the data that is altered will cause the signature to fail to validate against the content of the message. In the context of software update, further assurance is provided by including the output from a secure hashing function (SHA-256), to validate the integrity of the file to be retrieved.
KEY DISTRIBUTION
Safe and secure mechanisms for key distribution are essential to ensure the integrity of any messages protected by such keys. Asymmetric or public-key cryptography goes some way to addressing this by separating keys into a public and private portion. This simplifies the problem into one of exchanging the non-secret public keys, requiring only that the integrity (and hence, the trust-worthiness) of those keys is protected. Typically in implementation, an algorithm such as RSA is used indirectly to encrypt a symmetric key that is used to encrypt the actual data; or to sign a secure hash of the data, rather than the full data.
PROOF OF IDENTITY
This enables the operator of the server to be assured that the physical device that was observed was the device that has the identity associated with the join request. Depending on the device (and the nature of the system, as well as technical proficiency of the operator), this presentation could be done in a number of different ways. In a simple case, the device could display the decrypted value on a suitable display on the device. A sequence diagram showing the information flow during a human-moderated join operation is shown in Figure 1. Other techniques for presenting a UUID in a human-readable form are explored in Section 8.
KEY REVOCATION
Key revocation is a vital, but often overlooked aspect of any IoT system. It is however simple to implement in the context of a C2 server-based approach to an IoT system. There are two types of revocation that need to be considered.
1. The removal of a device as a subordinate to a C2 server such that it is no-longer subject to control by that server, whilst retaining the device within the wider system (this is the opposite of a join operation);
2. The permanent withdrawal of the device from the system as a whole (the opposite of initial device registration).
POTENTIAL ATTACK MECHANISMS
In the event that an attacker is able to gain physical access to the device, it can be assumed that, unless the device has been built to utilize encrypted storage and a trusted boot process, the attacker would gain access to any data stored on the device. In the context of a SRUP device, most significantly, this equates to the server’s public key and the device’s private key. Since the server’s public key is by definition publicly available (on demand via the registration process, if nowhere else), we may largely disregard this as being of use to an attacker. Having access to the device’s private key, however, means by the definition used in Section 4.2 that the attacker may take the identity of the device.
METHODS FOR EASY HUMAN COMPARISON OF UUID VALUES
Figure 5. An example four-color, 8 × 8 grid depicting a 128-bit binary value; in which the color of each cell corresponds to the the value of two-bits in the value
The value could also be presented in the form of a smaller 8 × 8 grid of cells, colored with one of four colors. With careful selection of the colors, it is possible to produce a grid with a sufficient visual difference to be easily distinguished; and avoiding combinations that were indistinct for those with various forms of color-blindness. Again, whilst a specific protocol for such encoding has not been devised as a part of this work, an example of one such method (where the content of each square in the pictograph is determined by the value of two-bits in the UUID) is shown in Figure 5, for comparison with the other approaches described.
RESULTS AND FUTURE WORK
An initial protocol test-bed was constructed, and an example showing the use of an update message was demonstrated at the 2016 3rd IEEE World Forum on the Internet of Things. This implementation consisted of an IoT C2 system: using the Mosquitto broker; a Raspberry Pi 3 as an example device, alongside an example device-side daemon; and a C2 server. Both the daemon and server were implemented using the SRUP library, C++ components and Python scripts, with the inter process communication handled using Apache Thrift.
CONCLUSIONS
In this paper, we have shown how the SRUP protocol can be extended through the introduction of additional message-types, to be used as a general-purpose protocol for authenticated IoT communications. We have also proposed some methods that could be utilized to provide a means for physical devices to prove they have an identity corresponding to a logical device within the network, using either human or a machine-in-the loop methods. Full details of all the message types within the SRUP protocol may be found in the protocol specification document. The source code for the latest version of the library and an example implementation of the device-side daemon, as well as C2 server are all released under the terms of the MIT open licence.
Source: University of Southampton
Authors: Andrew John Poulter | Steven J. Johnson | Simon J. Cox
>> 200+ IoT Led Engineering Projects for Students
>> Simple IoT Software Projects for Final Year Students