IoT Course Week 7: Platform Security (Part A)

Anytime you are making a product, platform security is something that needs to be addressed. In this post, we look at platform security and the steps you can take protect your users.

Platform Security internet of things collage IoT
By now we’ve created a page that controls LAMPI and are serving it out of Django. We have a user authentication scheme, although we’re not putting it to great use just yet. Before we get there, we have a huge problem — there is really no security to speak of anywhere in this system. Our MQTT bridging is “secured” with a username and password, but those are sent unencrypted over the network. It would be trivial to sniff this communication and discover these credentials.

We have two paths into our EC2 server we need to secure — the path from the lamp to the cloud, and the path from the user’s browser back to the cloud.

TLS Certificate

Rather than use username and password, we are going to use Transport Layer Security (TLS) to encrypt our communications. Using this channel of public key cryptography will ensure that messages being sent between the lamp and the cloud are impossible to decrypt or interfere with, without first compromising the private key of the Certificate Authority.

We will create our own local certificate authority which we will use to issue and sign certificates for both the lamp and web client. A CA functions via the following steps:

  1. Someone decides to be a CA
  2. Generate a Public and Private Key Pair
  3. Generate a CA Certificate, including the Public Key, and Sign it with the Private Key
  4. Distribute your CA Certificate to the World

Note: For a real CA, Private Key should be stored securely, probably on a non-networked computer. Compromise of the Private Key compromises all derived certificates!
If you want to read more about how TLS (and it’s predecessor SSL) work, here is an excellent Stack Overflow post.

For the purposes of this discussion, the Common Name of the TLS certificate has to be unique to the LAMPI instance. This is because the Common Name will be used as part of the authentication process later.

Add to Bridging

As was set up in Lecture 4, MQTT bridging between cloud and LAMPi is handled using the tool Mosquitto. Mosquitto supports TLS security natively, and turning it on is as simple as ensuring each device has the appropriate CA and generated keys to communicate with each other. On the LAMPi, the configuration is:


connection b827eb74663e_broker
bridge_cafile /etc/mosquitto/ca_certificates/lampi_ca.crt
 bridge_certfile /etc/mosquitto/certs/b827eb74663e_broker.crt
 bridge_keyfile /etc/mosquitto/certs/b827eb74663e_broker.key
 bridge_tls_version tlsv1.2
topic lamp/set_config in 1 "" devices/b827eb74663e/
 topic lamp/changed out 1 "" devices/b827eb74663e/
 topic lamp/connection/+/state out 2 "" devices/b827eb74663e/
 cleansession true

and on the cloud, the configuration is set to:

 listener 52122
 cafile /etc/mosquitto/ca_certificates/lampi_ca.crt
 certfile /etc/mosquitto/certs/lampi_server.crt
 keyfile /etc/mosquitto/certs/lampi_server.key
 tls_version tlsv1.2
 require_certificate true
 use_identity_as_username true

Next, we need to allow that “user” access, so we configure Mosquitto’s passwords file and add the Common Name of the LAMPI instance. Once these are set, and Mosquitto is restarted, each Mosquitto instance is reset and the bridging will now be TLS secured!

Serving Django pages from NGINX

Next we’ll need to secure our web client. The current Django web server does not support TLS, and we are hoping to use TLS to communicate between the cloud and a user’s web browser. Since we already have nginx installed and it is a TLS capable web server, we will use that. nginx does not natively know how to serve a Django app, so we’ll use uWSGI as a WSGI adapter between nginx and Django. uWSGI provides detailed instructions on making this web server change in their docs.


# configuration of the server
 server {
# the port your site will be served on
 listen 443 ssl;
 ssl_certificate /home/ubuntu/ssl_keys/lampi_server.crt;
 ssl_certificate_key /home/ubuntu/ssl_keys/lampi_server.key;
 ssl_protocols TLSv1.2;
# the domain name it will serve for
 server_name; # substitute your machine's IP address or FQDN
 charset utf-8;

Restarting uWSGI and nginx at this point will apply the changes. Now traffic when navigating to https://{django_web_address} will be secured via the CA that we created!

Securing Websockets

Since we’re getting some of the real-time information over websockets, and MQTT is serving that data using the websockets protocol, we want to also encrypt the transport of that data from MQTT to the Client’s web browser. Also, since this websocket data is in a web page that is already coming from a now encrypted NGINX server, we need MQTT to encrypt that websocket data with the same TLS certificate that we use for our NGINX configuration.


listener 8081
 protocol websockets
 cafile /home/ubuntu/ssl_keys/lampi_ca.crt
 certfile /home/ubuntu/ssl_keys/lampi_server.crt
 keyfile /home/ubuntu/ssl_keys/lampi_server.key

Here is an example of what this would look like:

Platform Security Diagram for IoT Class



  • no services listening on anything but localhost
  • MQTT bridge using TLS with unique certificate


  • Require TLS on MQTT (MQTT and Websockets)
  • Require TLS on NGINX HTTP (HTTPS)

Next Week

This week laid down the groundwork that makes up our platform’s security. Next week, we will continue this robust buildout, specifically focusing on the MQTT layer. User accounts will be limited through Django to lock down communication to specific LAMPi devices. The MQTT web sockets interface will also undergo some lockdown.

In case you missed it, here’s a link to last week’s post: IoT Week 6: Setting Up User Accounts or, if you’re hankering to snack on some Cucumber, check out How to Run Cucumber Tests with Docker.

Platform Security (Part A): IoT Course Week 7:
Article Name
Platform Security (Part A): IoT Course Week 7:
Anytime you are making a product, platform security is something that needs to be addressed. In this post, we look at platform security and the steps you can take protect your users.
Publisher Name
Publisher Logo