As many companies continue to implement “smart”, network-aware devices in industries such as manufacturing, oil & gas, energy & utilities, transportation & logistics, etc. the desire for remote monitoring and management of these devices has grown. There is immense business value in the delivering the enhanced control, awareness, and automation that Internet of Things (IoT) solutions can offer.
One of the key challenges to implementing an IoOT architecture is keeping the data connection secure between the edge devices and the centralized command and control system, which is typically deployed into a cloud-based environment. In this article, we’ll take a look at a few options for securing this connectivity.
Let’s begin by securing the network connection itself between the edge device and the central IoT system. The first, and most basic, approach used is a one-way TLS connection to encrypt the traffic during transmission. The architecture for this is similar to that of any web-based interaction, where the server provides the signed certificate to encrypt traffic and validate itself.
Termination of the TLS tunnel can be performed at either a network device (firewall, gateway) or at the cloud messaging hub/broker. Typically, the earlier the TLS is terminated the better, as it can be a drag on compute resources. However, the design for each solution will depend on the data sensitivity, network security, and level of trust in the environment.
Another common option is to use mutual TLS. In this scenario, in addition to the server presenting a certificate, the client presents its own certificate to the server for validation. This two-way handshake allows the server to use a defined certificate authority to validate that the client is an approved edge point for the solution. Management of these client certificates can be operational cumbersome but can enhance the level of security and even take the place of standard client authentication mechanisms.
The most common form of authentication between the edge devices and the central IoT system is to use standard client credentials (user id & password). This is the simplest form of authentication and can be the easiest to get up a running in a new solution. Of course, password rotation can be problematic and, as a result, most solutions do not rotate credentials on a regular basis.
Another potential mechanism for client authentication is to use OAuth with Java Web Tokens (JWTs). By provisioning these tokens onto each client, they can be used to authentication the client if the server is connected to the issuing authorization server. However, most JWTs have a short-lived life span. Therefore, the edge client will need to have the ability to use a refresh token to get issued a new access token at regular intervals (typically hourly or daily).
Securing your IoT solution also requires the appropriate authorization for each client in addition to the authentication of the client identity. If each client is limited in its ability to stream and receive data with the central IoT system, it protects the solution as a whole. The key is to contain the exposure if client credentials are compromised.
For example, in a typical industrial IoT solution that uses MQTT for communication between edge and cloud, we should lock down the topics for each client to prevent cross-over between clients. For example, client 12345 would only have permissions to publish to topic mqtt/12345/in and subscribe to topic mqtt/12345/out. Through these authorization rules, any compromise of this client’s credentials would prevent it from publishing or subscribing to data having to do with other clients. The breach is contained to that single client and the attacker is prevented from any broader impact on the whole system.
Getting Your IOT Security Design Right
Designing an IoT solution and are unsure of which approaches are right for you? Contact Anexinet for help. We’ve architected and implemented such solutions for multiple clients and can help you design the best solution for you and your company.