IoT Security Anti-Patterns

From security cameras to traffic lights, an increasing amount of appliances we interact with on a daily basis are internet connected. A device can be considered IoT-enabled when the functionality offered by its Embedded System is exposed through an internet connected API.

Internet-of-Things technologies inherit many attack vectors that appear in other internet connected devices, however the low-powered hardware-centric nature of embedded systems presents them with unique security threats. Engineers building Internet-of-Things devices must take additional precautions to ensure they do not implement security anti-patterns when addressing new problems, this blog post will investigate four such anti-patterns that have been used by real Internet-of-Things devices.

Atmel ATMEGA8 Microcontroller Wikimedia Commons - CC BY-SA 3.0

Every time your IoT-enabled alarm clock sounds, you may want it to tell your coffee machine to brew some coffee. In order to do this, your coffee machine may subscribe to messages published by your alarm clock. One such way of doing this is to implement the Publish/Subscribe Pattern within the API of the IoT devices, for this example let's assume our alarm clock and coffee machine communicate through HTTP.

In order to subscribe to messages from the alarm clock, the coffee machine sends a HTTP POST request to https://alarmclock/publish with the following body:

{  
   "on":"alarmSound",
   "to":"https:\/\/coffeemachine\/subscribe"
}

This JSON request instructs the alarm clock on every “alarmSound” event to send a HTTP request to the coffee machine. Whilst this may seem a simple and effective way of implementing the Pub/Sub pattern in HTTP, this poses a significant security risk.

By not being able to validate if the receiver of the subscribed message wants the message or not, there is effectively a DDOS vulnerability. An attacker with the ability to set subscriptions on the alarm clock can effectively send HTTP messages to any device or internet property they want. If this is done across enough devices, a DDOS vulnerability is created.

Toast popping out of a toaster or a car driving across a road traffic sensor could be the trigger of a future large scale DDOS against a web property.

For further reading, the limitation of Pub/Sub patterns in IoT within the context of the MQTT protocol are discussed in: Limitations of the Pub/Sub pattern for cloud based IoT and their implications - Happ, D. and Wolisz, A. (2016).

As the embedded systems which power IoT devices have gained additional computational resources, more and more IoT developers have chosen to implement TLS to secure communications. Additionally cryptography libraries such as wolfSSL and mbedTLS, better suited to the performance requirements for embedded systems, have removed many of the engineering and performance complexities of adding TLS support to embedded systems.

One anti-pattern in implementing TLS on IoT devices is running devices themselves as web servers and using self-signed server-side certificates to encrypt such requests. Aside from the performance overhead of running web servers on embedded systems, they also pose a severe security risk by failing to maintain trust relationships.

In place of this; IoT devices can communicate through brokers; such brokers can act as web servers with a signed TLS certificates installed server-side which can be authenticated with devices using the X.509 standard. This can be done effectively by simply using the HTTP protocol. Like other kinds of message brokers, they will receive messages, perform validation, transformation and routing before sending them on by recipients.

Protocols like CoAP are specifically designed for brokerless Machine-to-Machine communication in low power environments, in its current form CoAP uses DTLS (RFC 4347) which supports pre-shared keys, raw public keys and X.509 certificate authentication.

Far from being in a datacenter, IoT devices can be left in insecure environments - as such extra precautions need to be taken to protect the memory on such a device.

Take the example of an IoT traffic counting device, installed in a locked cabinet at a roadside. A malicious adversary can break into the cabinet and steal the device with physical force. With the device in their possession they can extract software from the embedded system chip on the device to obtain the software running on it. By reverse engineering this software they can learn secrets in the memory of the onboard microcontroller.

When IoT devices can contain sensitive data in memory, locking them away may not always be sufficient. One solution to this problem is to encrypt the bootloaders on such devices - this provides a degree of cryptographic assurance that the secrets on the device will remain secret.

Documentation from Atmel AVR231: AES Bootloader

There exists dedicated integrated Controller chips that allow for Hardware-based Key Storage at low cost; these chips can be used to prevent cloning and tampering of Embedded Systems. Examples include Atmel’s CryptoAuthentication chips and Microchip’s PIC24F GB2 microcontroller.

Other precautions should of course be taken, ensuring that keys are unique to a device and that revocation systems are in place, should keys be disclosed for whatever reason.

It is not merely enough to leave your secrets unencrypted on an embedded system in the hope no one will attempt to reverse engineer it. Taking appropriate security steps for the secrets your IoT device will store is vital.

Instead of communicating over an abstract protocol like HTTP, developers may choose to use shortcuts by simply directly connecting to a database server to push data. Aside from being making permissions control harder, this opens up performance difficulties.

Lock contention is one such issue, when running UPDATE queries on rows other devices will end up waiting for locks on the database to be released before other queries can be done. Additionally, polling databases for changes can lead to IoT brokers becoming easily overloaded.

This Anti-Pattern can be mitigated by using a message broker service, exposed by a HTTP API. REST APIs are easier to cache, easier to scale and allow you to vary your database implementation independently of your API.

No matter how closed you think the usage of your IoT API is, take pride in it and seek to make it resilient to the forces of change later on. Abstracting your database away from your devices allows you to introduce a greater degree of security and also prevents other architectural headaches later on.

As the technology that powers the internet matures, so will the attacks it faces. IoT devices are set to see a unique set of security vulnerabilities, different to the set seen by other internet connected devices. As more IoT devices start to be unveiled, new security challenges will also unfold.