As introduced in my last post, the Internet of Things is in essence a collection of Smart + Connected devices (aka “things”). Now we all know that the Internet, while enabling, is not the safest place in the world. Any person or thing needs to be equipped appropriately to safely exist there. The suite of safety products for a person on the Internet has evolved over the last 15 years from simple single-point gateway firewalls to multi-dimensional security implementing multiple layers of firewall protection, malware detection and greatly improved hardening of both application and system software. But how is a “thing” supposed to protect itself?
Connectivity is an absolute requirement; after all that is half of “Smart + Connected”. While for many “things” the connectivity may be focused within the organization’s network borders, there can be treats inside an organization and it is likely that sooner or later the device will generate data needed outside the organization or will need to be controlled externally.
Much attention has been given for hosting web services on IoT devices. This indicates that web protocols are probably the preferred network methodology to acquire data and/or perform control actions. This is advanced, outside of the IoT realm, by the proliferation of REST, JSON, and other 2nd generation integration methodologies.
That simple data telemetry alone is not the final functionality most IoT devices will end up implementing. It is inevitable that most devices will become “new and improved” by implementing as least some remotely controllable functions. These could be as simple as reset and device code downloading, but will likely include more advanced control actions that extend beyond the device into its surrounding physical environment.
If you have done some reading about this prior to today and you are open to ideas from Microsoft, you will probably will have come across discussions involving Clemens Vasters. Clemens presents a clean and grounded approach to securing IoT, one that closely aligns with the LooUQ approach and the architecture of our products. Quite frankly, it is somewhat surprising that the building blocks for this model are not more prevalent at the micro-controller device level.
The basic tenants are…
Minimize trusted network associates:
If you only trust a small number, or one other, system then the device can minimize the attack surface by ignoring network traffic from all other network nodes.
Secure the communications channel
By implementing SSL communications as a HTTPS connection (outgoing only) you further enforce the minimized trust and ensure that the communications are private and not tampered with.
Many of the micro-controller network interface chips are now embedding HTTPS and SSL and are taking over the task of the necessary cryptography. This is advancing SSL as a key standard for improving IoT networking security.
Implement a proxy agent as the trusted associate
By implementing a proxy as the trusted partner, the device is effectively removed from the enterprise or public network. All communications are subject to translation by the agent. This does require that the agent’s translation abilities be extensible, but the domain where this extensibility would be performed is now on server class hosts where the capability to implement the extensibility is much more sophisticated.
Make the device initiate the communications channel
Most private networks support a loose outgoing TCP connection policy; for the most part they block incoming traffic except what is explicitly allowed and allow all outgoing traffic. This makes the proposition of adding IoT devices following this pattern to a private network almost automatic in most cases and making private\public device placement nearly the same process.
Looking at the components of the pattern above… only implementing SSL is the difficult item from a micro-controller system’s perspective.
Other Approaches There are other approaches, in fact the first one below seems to be the focus of most discussions. But they have their own issues to solve and really their issues are more challenging.
Build a web site on the IoT device
While HTTP is not a terribly difficult protocol to implement and for the most part it is intrinsically a part of the most micro-controller networking stacks, implementing a set of secure services where abnormal behaviors are trapped is difficult
As a web server the device has now needs to be accommodated by a private network’s security policy, by provisioning firewall rules to allow incoming network traffic. In most situations this is, at minimum, more effort and for some enterprise networks would simply not be allowed.
Add VPN capabilities to the IoT device
VPNs have many of the same concerns as SSL implementation: the implementation of cryptographic algorithms, so this isn’t easier than SSL.
Most VPN implementation are specialized by vendor and although there is standardization, the effort to implement multiple different VPN protocols is a steeper hill than good old SSL. As mentioned above, implementation of SSL is becoming a network interface “chip” function, making specialized VPN cryptography more likely having to be implemented in the constrained resources of the micro-controller host.
Another issue with VPNs are the introduction of more network peers to the IoT device that are not necessarily worthy of trust. While address filtering can be implemented this is yet more unnecessary effort that can be avoided with a better core architecture.
So… At LooUQ we believe in a pattern that includes several layers, but it all starts with a SSL to a trusted host. We are quite aware that many of the devices associated with IoT struggle with the facilities necessary to provide SSL and a secure IP stack. But in the end, we believe that this is actually the simplest and lightest methodology to implement. LooUQ has built a framework allowing micro-controllers to communicate with a single cloud-based proxy agent via HTTPS please give us a look after we release in early 2016. Clemens Vasters’ presentation at the 2015 Microsoft //build/ conference is well worth the time it takes to listen. You can view it here: https://azure.microsoft.com/en-us/documentation/videos/build-2015-azure-iot-security/