The Internet of Things Needs Security!

Posted by Jarren Long at 2016-07-11 21:57:04


It has been over a year since I wrote an article about the Internet of Things, and the technology around it has evolved considerably since then. In the year since my last writing on the subject, extensive trial and error testing on my part has revealed a few pitfalls with utilizing the Constrained Application Protocol (CoAP) with a Datagram Transport Layer Security (DTLS) connection:

  • DTLS and CoAP were designed to operate at Layers 2 and 3, respectively, but very few considerations were made for them to inter-operate without marshaling data between the two layers.
  • DTLS is a connection-less protocol, CoAP is connection/session-oriented, forcing the developer to either sustain DTLS connections (insecure), or use CoAP without sessions (bandwidth-intensive).
  • Because the use of two distinct protocols is required, development complexity increases. A developer would need to write software to bridge the two protocols, handle key/certificate creation and management, and device provisioning schemes, taking away for development efforts that could be put towards building the IoT device itself.

Overall, the CoAP over DTLS concept was very elegant, but exceptionally complex and cumbersome for mass use outside of applications that require a high level of security (such as electric/water/gas utility use), and CoAP alone was very insecure, but provided everything you would ever need for communicating with embedded IoT devices, specifically sensors. To be more specific, the CoAP protocol on it's own was very well designed (utilizing a RESTful design which allows it to operate much like HTTP), but highly-tailored for interacting with sensor devices for reading data. While provisions were made for writing data to devices to control their sensors, this can be a dangerous thing to do when your communications are unsecured.

For the Internet of Things to truly catch on for global use, a new protocol needs to be developed that takes all of the best parts of CoAP, and expands on them to add native support for security. Until an open standard can be developed that will all devices to be secured out-of-the-box, the Internet of Things will be nothing more than a novel concept in a niche market, where there is always the fear that your device will be compromised (an excellent example of this is a case where a web-connected baby monitor was hacked in 2012, allowing the hacker to scream obscenities at a sleeping toddler. Nice work Foscam...)

As long as a new protocol is being defined and developed, the following points should be considered. The protocol should:

  • Remain lightweight, and be inherently secure by default, with the option to disable security of needed for some reason (why? I couldn't tell you) The protocol should be secured using quality encryption, but be simple to use. "Secure by encryption, not obfuscation". To remain lightweight, the protocol must be binary. Humans do not need to be able to "read" the protocol in its raw form. Plain text protocols are dead, get over it.
  • Operate at Layers 3 and above, but should fully encompass the operations of all layers in a single protocol package ** The protocol should be flexible enough to operate over UDP, TCP, BLE, and any other layer 2 protocol without modification, and simple enough to operate over any layer 1 medium
  • Follow a RESTful architecture, supporting CRUD operations
  • Support connection-oriented and connection-less communications
  • Support commands that require responses (confirmed commands), as well as commands that do not require a response (unconfirmed commands)
  • Support both unicast and multicast communications ** The protocol should be capable of communicating over a traditional client-server network, as well as peer-to-peer networks, such as Tor
  • Be generic enough to allow transmission of any type of data, but flexible enough to be tailored for sensor/device-related operations
  • Utilize TLV structures for encapsulating all data being transmitted in the payload
  • Utilize simple and short URIs for data I/O operations
  • Be Free and Open Source, unencumbered by patents and proprietary lockdowns which would limit growth of the protocol and IoT utilizing it

If these basic considerations are taken into consideration while the protocol is being defined, the Internet of Things could greatly benefit from the work, and finally have a common and secure base from which to start to grow. Without the development of a protocol that follows these guidelines, I fear that the Internet of Things will eventually grow into a mass of millions (or billions) of unsecured devices, all running their own proprietary protocols which are built on top of an already over-layered Internet architecture.