As the demand for more efficient data management and cloud integration rises, IoT devices are poised to play an even more significant role in shaping our world. They facilitate seamless data transfer to the cloud, where it can be stored, analyzed, and leveraged to make informed decisions, automate processes, and enhance our overall quality of life.
Sending data from devices to the cloud involves several protocols and technologies that enable secure and efficient communication. Here are some commonly used protocols:
- HTTP (Hypertext Transfer Protocol) and HTTPS (Hypertext Transfer Protocol Secure) are standard web protocols, commonly used for sending data to the cloud. They are simple and widely supported.
- MQTT (Message Queuing Telemetry Transport) is a lightweight and efficient protocol often used for IoT applications.
- CoAP (Constrained Application Protocol) is designed for resource-constrained devices and is often used in IoT scenarios.
- AMQP (Advanced Message Queuing Protocol) is a robust messaging protocol suitable for more complex communication needs.
In this article, we will focus on constrained devices whose journey to the cloud involves a couple of additional challenges compared to more powerful IoT devices.
What are the challenges with constrained devices?
Constrained devices are devices with:
- Battery Capacity Limitations: Typically constrained devices are limited in size and thus have design constraints on battery capacity.
- Processing Limitations: Constrained devices are characterized by limited computational power, often resulting in restricted processing capabilities.
- Memory and Storage Constraints: These devices typically have modest memory and storage capacities, which can affect their ability to handle and store data.
- Network Limitations: Constrained devices often operate with restricted network capabilities, potentially impacting their data transmission efficiency.
Hyperscale cloud providers (e.g., Amazon AWS, Microsoft Azure) offer IoT services with public endpoints and require devices to use Transport Layer Security (TLS) for end-to-end (e2e) encryption with a limited range of protocols (HTTPS, MQTTS, AMQP) that are relying on TCP protocol for data transmission.
Is that a problem?
Many constrained devices only support UDP-based protocols, primarily CoAP due to its efficient use of bandwidth, which are incompatible with protocols supported by cloud providers. Additionally, these devices may face challenges due to hardware or design limitations, preventing the implementation of e2e TLS.
Our internal research based upon a real-life customer use case indicated that implementing e2e TLS can increase device data transfer payload by up to 95% and reduce battery life by around 50% for typical constrained device use cases.
Other companies have done similar investigations, and you can find their results here.
Furthermore, considering the logistics of obtaining, deploying, and managing SDKs and certificates for each of the thousands or even millions of devices in your fleet, you can see the problem and the need for a solution to manage all this.
What can be done?
Since we need a secure and simple solution that allows us a plug-and-play customer experience, we will discuss three different approaches to tackle our problem.
- Solutions based around a private network.
- Solutions based on intermediary components that act as a proxy and do protocol conversion, amongst other things.
- Solutions that rely on the cellular connectivity provider for encryption.
Private APN/VPN connection to a private network
First, we must mention a private APN/VPN connection to a private network. With this approach, there is no need for a TLS implementation. The device traffic does not leave the network and is considered secure. Without TLS, there is also no need for certificate management. Thus, broker deployment and/or some sort of device management is needed to enable the communication and perform protocol translation - you cannot make use of the cloud IoT services (e.g. AWS IoT Core/Azure IoT Hub) as they have public endpoints.
This method works for constrained or non-constrained devices.
VPN connection setup can be time-consuming, but several companies are developing automation platforms and services.
Cloud Connector
Another potential approach for connecting devices to the public cloud is introducing an intermediary (Cloud Connector) component between the devices and the Hyperscalers. That means developing a solution that can:
- establish a secure connection between the device and the intermediary component through a VPN (IPSec) tunnel,
- simplify the device onboarding process,
- add support for otherwise unsupported (by cloud services) protocols (CoAP, Raw UDP),
- provide certificate management on behalf of the device,
- provision the device to the preferred cloud (AWS, Azure),
- and enable configuration of the device (SOTA - Software-Over-The-Air).
Handling of this complexity on the network edge means that the complexity is removed from the device, allowing it to be as simple as possible - minimizing device payload (saving on mobile data costs) and extending battery life.
This method is also suitable for both constrained and non-constrained devices.
IoT SAFE
Last but not least is IoT SAFE (IoT SIM Applet For Secure End-to-End Communication). It puts the root of trust on the device in the form of a SIM applet designed to secure IoT devices and address IoT cloud security.
This means that the software on the IoT device will not need to handle certificate management operations (storage, rotation, etc.). The applet on the SIM will do that instead, with a high level of security that is standardized by the GSMA. The TLS stack on the device will use the applet as an implementation detail for operations that require TLS, like making HTTP requests.
You can read more about it in the GSMA Whitepaper IoT SAFE - Robust IoT security at scale.
The applets are remotely and locally controllable. The remote control functionality must be integrated into a connectivity management platform (CMP).
Since this solution still relies on TLS, it is unsuitable for highly constrained devices. It also does not solve the cloud integration issue on its own. It has to be combined with additional solutions.
The time is now
In navigating the complexities of connecting constrained IoT devices to the cloud, we've identified crucial challenges and potential solutions.
As we explore diverse approaches, including private connections, Cloud Connectors, and IoT SAFE, the key lies in building adaptive solutions that simplify device deployment and management.
So, where do we go from here? Let's go and build this smooth journey together.
