“Ease of Access.” The idea of Home Automation has started by this idol. In other words, it is the idea of accessing, controlling and monitoring switches, sensors, and other nodes remotely. Internet of Things (IoT) devices don’t usually have the same firmware; when working with IoT devices, usually the IoT environment is multi-platform. Also, the concept behind IoT is that all devices has to be somehow, at some point, Internet-connected and accessed or logged in some Cloud infrastructure [6].
Each node has its application-specific software. That is, it is somewhat difficult to integrate nodes running different software to “robotically” notify each other. Applying a “Chat” mechanism or encapsulation of data will enable nodes of different applications to pass data within a network to each other when needed. The “Need” in this context may be defined by the end user preferences.
However, it is possible to facilitate multi-platform IoT nodes to talk with each other “unmanaged” to satisfy some application set by its user (e.g. if the user entered his home, turn on the TV and lights…etc). Notably, most IoT nodes don’t come with encryption modules that can work with other nodes, thus making this an issue of security when two IoT nodes communicate with each other automatically to resolve events.
The context of this article will include a discussion and implementation of how to secure transmitted data between nodes to ensure that a man-in-the-middle would not be able to read important packet contents. The rest of the work, Chat Node Management, Autonomy, and other aspects of this system are being studied and discussed in another part of the work [10]. Figure 1 illustrates the IoT architecture in use, in which would facilitate both node-to-node messaging and end user to node messaging (Fig.1).
Each node has its application-specific software. However, it is possible to facilitate multi-platform IoT nodes to talk with each other “unmanaged” to satisfy some application set by its user (e.g. if the user entered his home, turn on the TV and lights…etc). Notably, most IoT nodes don’t come with encryption modules that can work with other nodes, thus making this an issue of security when two IoT nodes communicate with each other automatically to resolve events.
Assumptions
For this application, an assumption is that the communication between multiple IoT nodes will be Internet-based. That is, two or more IoT nodes will “chat” through an application server that is already on the web [1]. The reason behind ultimately necessitating IoT’s access to Internet goes back to the original definition of IoT itself [6]. However, it is possible to access nodes locally in addition to/or as a backup to the online application server. It can be done using the same type of chat service. Essentially, the use of the online chat server is to grant users access to manually control their nodes or receive logs from anywhere. We are also assuming that all nodes will be connected through the Internet wirelessly using a standard Wi-Fi bridge/module (ESP8266 NodeMCU [2]). The nodes are capable of running software themselves as well as be interfacing other devices. In our implementation, we will be using these nodes as standalone devices. This will facilitate the nodes connected to the same server with the possibility of chatting insecurely with each other, since such simplified nodes are limited in capability when handling TLS v1.2 (which are enforced now by most chat servers [3]) for a secure TLS/SSL encryption between clients and servers, or specifically, nodes and a chat server. We also want the encryption be secure the chat between the nodes, that is, the web server will be unable to read the messages the each node is sending.
Implementation
We implemented Off the Record (OTR) End-to-End encryption between IoT nodes using ESP8266 NodeMCU Wi-Fi Arduino modules as our nodes, and a machine with XMPP installed on it as our server [1, 2]. AES symmetric encryption was used to encrypt any messages being sent by the individual nodes [8]. Keys are stored on the individual nodes, and more can be stored by utilizing external storage (i.e. SD cards) on the nodes, thus limiting key reuse. In order for the nodes to know which key to use, the XMPP server sends a message to all nodes containing a number. The number corresponds to the index of the list of keys each node carries.
In order to follow the OTR protocol, our implementation allows for three layers of security: Deniable Authentication, Encryption-Key Forward Secrecy, and Malleable Symmetric-Encryption.
Deniable Authentication – Each node has its own user ID and password to use for connecting to and authenticating with the chat server. Only nodes registered on the server can send messages to other nodes. That is, after these two nodes become “buddies” by simply requesting to be a member of each other’s roster list. Authenticating nodes with each other is done upon initialization of nodes by an end-user. This gives our system the ability to authenticate nodes sending messages, and prevents a third party from validating any of the nodes’ identities. An attacker at this point will not be able to recognize the data within a packet, which comprise a XMPP standard Stanza that contains an encrypted authentication and message. The message also contains the destination UID which the sender intended to send the message to. The UID should be visible for the XMPP server to rely the message. An attacker with access to the XMPP server, reading chats, will not be able to determine the contents of the message because it is encrypted end-to-end with 256 bit log key (AES). Say the attacker attempted a replay attack by replicating this packet. The only way to prevent this is from happening is by deploying SSL between the client node and the server. We discuss this in the possible future improvements section.
Encryption-Key Forward Secrecy – Handling of encryption keys is done in three steps. First upon initialization the node, which already has a hardcoded array of keys, is provided with an index of an encryption key from a chat admin, the end-user. This chat admin is a chat client that can be an operator on the server or another client of that server as shown the Figure 1. The admin chat client will initialize each node with a randomly chosen but the same key index at the time of the request. Second, the admin will send a test chat to that node, “hello” that is encrypted by the key corresponding to the index number provided. The node should decrypt and send “hello back” to the admin accordingly. Third, autonomously and based on user configuration, nodes will communicate using the current encryption key index provided by the chat admin. The admin will update this index on a set frequency by sending a new index to all nodes at once. When a new key index is received, the nodes will use it to choose a new key from the cached array of keys. This ensures that past messages cannot be decrypted with current message keys, and makes it difficult for a third party to determine the key that corresponds to the current index. In a specified TTL, the keys will be updated from the chat admin by sending a new set of keys encrypted with the previous key in use on all nodes.
Malleable encryption – For this implementation, AES encryption has been adopted to encrypt the message body. AES provides malleable encryption that plays a major role in detecting changed and altered characters in the cypher text read by a recipient node. That is, since nodes are configured to perceive the chat body as “command” or “command args,” once a node is unable to read a message after decryption, the message will be flagged and the XMPP server will be notified. This makes it possible for end-nodes to autonomously report to the server and block unwanted chats, or in other words, unfriend the attacked client for the server not to rely infected messages to the node.
Issues we addressed
We initially had some trouble finding a software encryption library that would work with our module. Thus, we implemented the AES encryption based using a library which does not constrain or allocate memory in the running firmware or hardware of the node, a byte-oriented AES encryption [5]. Advantages we gained from deploying and integrating this open-source library, to be working on an Arduino-compatible node, is that it uses 256B key-length and can resolve encrypting or decrypting strings in milliseconds.
We found when encrypting the message, the resulting cypher text would generate characters that were not supported in some native Arduino libraries. One of the libraries being used to connect to our server is the WiFiClient library. This library caused issues with sending encrypted messages out from the nodes to the chat server due its incompatibility with extended ASCII which were sometimes in the cipher text after encryption. The error causes nodes to stop processing and crash in most cases. We addressed this problem by encoding the letters in a string in its ASCII decimal representation then turning that representation into a string literal (ex: “121,245”). On the recipient side, this integer string will be decoded into unsigned integers, which are then casted into characters which returned a string containing the encrypted string. Then the node will decrypt the string using the commonly-agreed-upon key.
Communication between the devices through the XMPP chat server apparently will generate random characters after the original message that was sent. Our solution to ensure that we only read the message data was to append “…” to the end of the message then treat the “…” as a delimiter on the receiving end allowing us to only read the relevant message information. We used the three dots pattern only because it is a pattern that cannot be generated of the random characters appearing after messages.
What could be improved
A major enhancement would be upgrade the key distribution mechanism. Instead of storing keys on the individual nodes, they can be transmitted over SSL from the server which would allow the key to be randomly generated [9]. This reduces the risk of key reuse which would improve forward secrecy. Provided this, SSL, the client-server and server-client communication will be encrypted through different public-private key pairs. Our implementation guarantees that the contents of the message will not be visible even on the server itself. That is, the messages will only be readable at end-nodes.
Refs
- [1]. XMPP (http://xmpp.org/)
- [2]. ESP8266 (http://www.esp8266.com/wiki/doku.php?id=start)
- [3]. TLS in XMPP, by IETF (https://www.ietf.org/proceedings/88/slides/slides-88-xmpp-1.pdf)
- [4]. NodeMCU (http://nodemcu.com/index_en.html)
- [5]. Ilya Levin, a byte-oriented aes-256 implementation (http://www.literatecode.com/aes256)
- [6]. Towards a definition of the Internet of Things (IoT): Telecom Italia S.p.A.; Roberto Minerva, Abyi Biru, Domenico Rotondi.
- [7]. Off the Record Messaging (https://otr.cypherpunks.ca/otr-wpes.pdf)
- [8]. AES Encryption Library (https://github.com/qistoph/ArduinoAES256)
- [9]. RFC 6101 (https://tools.ietf.org/html/rfc6101)
- [10]. Alaa Badokhon. Masters Thesis.
Comments (0)