Securing IoT Deployments

Moritz Ulmer
Nov 25, 2019 · 4 min read

In the case of Internet-of-Things (IoT) systems, a multitude of small and simple devices capture a large cross-section of the world through their sensors. In our case, our world consists of hydroponic farms, from a single home-based cube to industrial sized sites. From a network topology, however, they have an identical structure. WiFi-enabled controllers, connected to sensors and actuators, connect to a farm’s coordinator, usually a Single Board Computer (SBC) such as a Raspberry Pi or an Nvidia Jetson, over MQTT. The SBC in turn is connected to the SmartDigitalGarden (SDG) server over a RESTful API.

The network topology of the SDG components. The controllers connect to the coordinator which relays the information to the server.

The connection to the SDG server is simple to secure with user authentication (OAuth2 or an API token) over an HTTPS connection. The tricky part is the setup of the controllers and securing their local MQTT connection.

The reasoning behind securing the MQTT connection is to ensure that it prevents unauthorized commands from being sent to the water and dosage pumps which can quickly result in the death of an entire crop. This can be achieved by drying out the hydroponic systems, overdosing nutrients or shifting the pH too far from a neutral pH value.

MQTT can be secured with user authentication over a TLS connection. One option is to directly flash the credentials and certificate onto each controller. However this means that each controller in every farm will use the same set of secrets. If this set is stolen once, each site becomes vulnerable. An alternative is to only distribute the secrets after the devices have been registered to a farm network.

A prototype setup of a sensor controller consisting of a PCB, sensor electronic and a 3D printed case.
A prototype setup of a sensor controller consisting of a PCB, sensor electronic and a 3D printed case.
The image shows an early prototype of a sensor controller. It measures several water parameters such as the pH value, its conductivity and temperature.

The secrets can be distributed in two manners, physically or via the network. The more straightforward method is to physically configure the controller with an NFC / RFID card which allows the WiFi credentials and server API token to be given to a controller. However, a network registration is cheaper and faster in most cases.

The flow for a controller to incorporate itself into a local MQTT network.

The other method, as shown in the diagram, uses the controller’s external IP address as a measure of locality. In this case the WiFi credentials (name and password) have to be flashed beforehand to match the WiFi at the deployed farm. The controller then looks up the local coordinator’s address by asking the SDG server who the local coordinator is for its external IP address. This assumes that there is a one-to-one mapping between the local network and the external IP address. The controller can periodically request an invitation to the MQTT network with an HTTPS request to the coordinator. A user has to accept the controller and subsequently, on the controller’s next registration request, it is given the secrets to connect to its local MQTT server.

A view of the smaller switch cabinet with a Raspberry Pi as the coordinator. It commands the actuator controllers and relays the data from the sensor controllers.

In order to secure the connection to the coordinator, TLS certificates have to be deployed. When issuing them, the server’s canonical name has to be specified. This can either be an IP address or a domain name. The easiest would be using the coordinator’s local IP address. However, if this were to change the certificate would be invalid. This means that even if the controllers could retrieve the coordinator’s updated internal IP address from the SDG server, the TLS certificate would also have to be renewed.

The flow for a coordinator to set itself up. It includes authentication by a user, creating a custom subdomain and acquiring a TLS certificate.

A more robust solution would be to use a subdomain for each coordinator. This means that the TLS certificate’s canonical name could be set to this subdomain. Subsequently, the coordinator would have to request the SDG server to set the A or AAAA DNS records of the subdomain to its local IP address. This allows the controllers to reach the coordinator through a simple domain name lookup instead of using an IP address.

It was previously stated that the root TLS certificate would have to be deployed to each controller. This can be circumvented through the use of a public certificate authority such as Let’s Encrypt and the use of the DNS-01 validation method. Traditionally, the HTTP-01 method is used which expects a challenge to be located at a well-known URL. The DNS-01 method expects a challenge to be located at a well known TXT DNS record. This allows TLS certificates to be signed for internal networks.

This has several advantages

  • the Let’s Encrypt root certificate can be trusted and deployed on each controller
  • regular browsers can visit the coordinator’s dashboard website over an encrypted connection without additional setup
  • no need to self-sign the TLS certificates and keep the private root certificate secret

Smart Digital Garden

A hydroponic and urban farming project by Protohaus

Moritz Ulmer

Written by

Smart Digital Garden

A hydroponic and urban farming project by Protohaus

More From Medium

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade