IoT Course Week 7: Platform Security Part B (#3)

Internet of Things CourseWelcome to Week 7, part B #3

Note: This is part 3 of a 3 part series about assignment 7B in the course. This particular assignment was quite information dense, and if you are unfamiliar with some of the pieces involved, things can be quite confusing.

In Part #2 we covered how the authentication and ACL mechanism works and how we integrated that with the Django web app. Now, we’ll cover how we deal with auth and ACL checking through the WebSockets support on Mosquitto.

Real-time Feedback of LAMPI in our Web App

In order to have real-time feedback in the web app, we are using the Paho MQTT JavaScript library and WebSockets to provide data to the Human User that has the web app open in their web browser. The WebSocket traffic is being supplied by Mosquitto, not our Django app. So, how do we secure this so that you can’t just go in and twiddle some data to get access to someone else’s LAMPI devices?

Well, first thing to note, since the WebSocket traffic is going through Mosquitto, is taking a look at what Mosquitto does in relation to the Auth integration with the Django app. Mosquitto expects there to be enough data in the WebSocket request to satisfy the /auth & /acl calls that we reviewed in Part #2. To recap, this is username, password and topic (for /acl you also need clientid and access type).

That seems easy enough, but we don’t want to send the user’s actual username and password through the wire (or exposed in the JavaScript) on every call. How do we solve this problem then? We use a collapsed UUID-based Auth token from Django that is unique to the current Human User session in the web app. By using the Auth token as the username and a blank password field, we can validate the request by looking up the Human User session in the Django app to be able to respond appropriately to the Mosquitto Auth Plugin call as to the authorization of that particular Pub/Sub request from WebSockets.

So, to make this easy, we wrote our Django view template to inject a snippet of JavaScript that sets up a few variables, one of which is our Auth token, that we then leverage in our JavaScript code that coordinates the WebSocket data calls with UI manipulation. That code then uses the token, via the Paho JavaScript client, as the username field so that the Django app can determine an authorization response when Mosquitto asks. This will then allow us to restrict the access to topics by user & device so that you can’t easily sniff other Human User’s data. Easy peasy lemon squeezy, right?

What more security do we need?

Well, for starters we should probably TLS encrypt the local backend HTTP traffic between the Cloud Mosquitto broker auth plugin and the Cloud Django web app. While we transfer this traffic over the local loopback device on the server (which means the IP traffic never exits the physical Ethernet device on the server), if you somehow gained access to the server, you could sniff the traffic on that interface. At that point though, we most likely have bigger security problems.

Having the Django auth token being passed around may not be the best, but it is similar to how many REST-based APIs work in that once you authenticate, you then use a token for all subsequent web requests.

Where else do you think the security of this architecture could be improved?

Next Week

Next week, we take a step back from this foray into security for something entirely new: mobile device control. We will forge a path into the unknown as we begin to implement Bluetooth Low Energy connectivity from the smartphone in your pocket directly to the LAMPI hardware.