The internet of things is an extension of the internet of apps. The internet of things is only starting, we’ve been used to the web and the idea of pages for the past twenty years. Now it’s the age of the app. We’re all familiar with web and mobile apps, the internet of things is about apps running anywhere one cares to put them. These are often called gateways or brokers in the internet-of-things tech-speak.
New types of apps are expected accompany an explosion in mircocontrollers. Already, mote networks (wireless sensors networks) have been introduced into industry, retail and the military. Motes are small microcontrollers with radios that run apps. Academics have responded to “maker” movements and tech educational needs with commodity microprocessors and open platforms, which in turn has led to all sorts of innovation, such as a wave of open source healthcare gadgets.
This quick sketch shows a sensor wireless network, it shows the protocols I spoke about in my previous post. Notice the sensors are in a different cloud, that’s because it’s a different network. The traditional network found in offices and the home provides a bridge to the cloud.
We can put apps (services) in the cloud to perform analytics or to offer web access or to integrate with enterprise systems. We can send messages back and forth, between a sensor and a cloud app. We offer access to the sensor network through a mobile app via a broker app running on a node.
The internet of things is exciting all by itself. Considering the IoT together with other emerging areas, it’s only possible to fore-see massive disruption when analytic engines, open networks and mobile are considered, but there are lots of open questions. For example, how we interact with the internet of things is undefined. The questions are big and the answers won’t come from the tech community alone. The role of the social sciences in identifying comfortable, non-intrusive and probable interactions between machines and society is not given enough attention.
Smart traditional networks working with smart sensor networks is around the corner.
Apps in the network
It might become tech-speak for a few paragraphs, hopefully not too much. In my previous post I spoke about MQTT messaging and I’d recommend reading it before this bit. To return to the diagram above, the broker is a gateway and is usually private to the devices whose traffic it aggregates and passes along to other services in the cloud or to a mobile app. By private, I mean the broker doesn’t carry any other traffic for security reasons.
The internet of things MQTT broker houses a control and/or communication app. We can add brokers to phones and communicate over wifi with another broker. We can put brokers in the cloud. The broker is a server, the central application, and manages sessions for many clients. It’s the gateway to the sensors and may translate messages from elsewhere in traditional network for its clients.
MQTT brokers talk to MQTT clients and give us a bridge between sensor and the rest of the internet. The client is a sensor. MQTT clients also talk to other MQTT clients. The MQTT protocol helps us to build apps for machine 2 machine communications over wired and wireless networks. Apps are also being introduced into traditional networks.
Services such as provisioning and authentication in traditional networks can be viewed as apps. Complex systems are decomposed into apps running in the network. Many of these apps can be purchased, others need to be built. Choosing a messaging protocol such as MQTT defines how one plans to proceed. Some services are proprietary while most are open source.
Software Defined Networking (SDN) will have an impact on the internet of things. SDN “is an approach to networking in which control is decoupled from hardware and given to a software application called a controller.” An SDN is an open, programmable network that runs apps. SDN is very new but already has had a big impact on datacentres. The EU is focusing research on uses of SDN and smart networks together. SDN’s require a blog post on their own, OpenFlow is the protocol, and the reason they’re exciting is “you don’t need to ask for permission to build an app, you just put it out there” Vint Cerf. Vint Cerf talks about the power of OpenFlow in the video on the first post in this series at 55mins.
The prospect of smart network and the cloud is very appealing. It’s an opening full of opportunity for those willing to learn. For example, putting apps in the network will offer opportunities to “throw a shape” on traffic and look for malicious intent. This opens up all sorts of possibilities such as the network quarantining itself.
The short secure-mote story is, security is divided between the sensor network and the traditional network. Sensor networks with a common broker gateway to the cloud, as shown in the diagram above, may use a “Security as a Service” provider. Both the client and broker constitute the attack surface, exposing vulnerabilities. Threats are mostly limited to attempts to corrupt or hijack the broker gateway or client mote. Security happens on two layers, network access and application.
I spent a couple of days looking at current security options which are changing very fast. The options available changed over those few days.
IPSec, a standard approach to securing networks, is not yet included in 6LoWPAN and and this has led to lots of discussion about lack of security for the IoT because IPSec is part of IPv6. 6LoWPAN doesn’t offer native support for IPSec although that appears to be changing. The Contiki OS has added IPSec support. The security debate about what’s appropriate in these tiny devices is linked to battery power. The added key management overhead in these tiny microcontroller adds battery resource requirements. In addition, IPSec requires key exchange between peers and security headers have to added to packets but bandwidth is extremely tight. This is the resource constrained world of sensor nodes.
IPv6 protocol stacks have the option to use IPsec to secure data exchange. It needs careful configuration to do NAT. Unlike link-layer security, IPSec provides end to end security, such that existing end points do not need to be modified to communicate securely with the 6LoWPAN network. Also, when compared to transport & application layer security IPSec secure all IPv6 communication (TCP/UDP/ICMP).
An alternative option is to use the security model supported by the IEEE for these networks. The 802.15.4 MAC layer offer security hooks, controlled by the MAC PIB (PAN – Personal Area Network – Information Base). The MAC layer maintains an Access Control List (ACL) in its MAC PIB. During the handshake, a specific security level (none, access control, data encryption, frame integrity, etc.) is chosen from security suite in the ACL for a communication peer.
According to 802.15.4-ACM, when an app doesn’t specify a security parameters then security is disabled by default. Four packet types are identified: beacon, data, ACK and control. There is no security for ACKs. The processes of authentication and key exchange was left undefined by the standard. This poses the question how do mote clients do key exchange, because without the key they cannot encrypt and decrypt messages. One cheap solution, which we’ll come to in a moment, is PUF.
Security is more complicated because projects may need to guard against both logical and physical attack, and the overhead of security in such a contained environment limit our options further. Battery is part of the attack surface, an attacker may execute a large sets of tasks in order to deplete the target motes battery, known “sleep deprivation torture” (Stajano). All this has resulted in the emergence of new approaches.
One needs to identify sensors and challenge them. Keys can be generated from abnormalities in hardware memory, that are consistent enough between power-ups to offer a unique key, after some “fuzzy extraction processing”. This is called a PUF (Physically Unclonable Function), they’ve been around since around 2007 and are commercially available. Interestingly, these PUFs have begun to appear in other use cases, for example, to tie the execution of software to a specific piece of hardware. Using a PUF fingerprint allows us to authenticate the device. It can also be used with elliptic curve cryptography.
Public key cryptography libraries for sensor networks, such as TinyECC, use elliptic curves algorithms for computational efficiency. TinyECC is easily configurable, providing execution time and resource consumption tailored for the constrained environment. When maximum efficiency of energy consumption is a requirement, mote boards with hardware encryption are used.
Using TinyECC with on-board generation of an asymmetric key pair (private and public) where the client retains the private key and sends the public key to the server through a protected channel. The protected channel would use an SSL/TLS tunnel between device and server.
One of the 2014 predictions from Symantech is the internet of things will become a magnet for hackers. There have been recent viruses found exploiting un-patched vulnerabilities in routers, Set Top Boxes and such devices. IoT viruses already exist. This IETF security analysis of 6LoWPAN is a must-read for anyone interested in the topic. Anyone considering IoT security should also have a look at patch management.
Security may not be important to every IoT project. R+D projects should turn into products so it’s better to think about security early because it impacts the choice of stack. There are lots of options and lots to read.
It’s typical for projects to secure the back haul communication between our laptops, mobiles, tablets and a network of sensors via the Broker app, by implementing TLS/SSL. Mosquitto supports TLS. I will talk about Mosquitto in a later post. Other security options are considered for communication between the broker and sensor network clients.
Usually the security setup is defined by ones choice of hardware/software vendor.
It is possible to have lots of sensors in your home. The next question is how do you interact with them. Tablets and mobile combine with voice and motion sensors to offer multimodality. Siri demonstrated voice UI is now possible. Speech recognition involves local ANR libraries and remote cloud services. Android offers a Google cloud speech-to-text service. We’ve moved from keyboards, to mice, to pinch, zoom and swipe gestures and to voice. The combination of sensor networks and artificial intelligence (read Mahout) offers the possibility for a revolution in UX. Complex UX will be required to deliver on the internet of things promise. Many user-context engines need to be built and work determining the appropriate human-computer interface in a given context has only begun.
UX is becoming more complex and practitioners need to be creative and knowledgable in technology, biology, the social and human sciences and industrial design. The difficulty introducing new interfaces is all interfaces need to be obvious to the user, supporting features using an indirect help context is a disaster.