Exchanging data securely via narrowband IoT thanks to DTLS (part 3)

While the first part of this blog series dealt with the technology of narrowband-IoT and in the second part I went into the specifics of communication based on MQTT-SN via NB-IoT, the third and final part of the series will focus on the aspect of security, which is critical for the Internet of Things.

Encryption using DTLS

It is possible to establish a connection between the end device and the cloud infrastructure via VPN using the tariffs offered by standard mobile phone providers. However, there is no real end-to-end encryption in this case. Although the VPN connection can be encrypted via IPSec, for example, the data transmitted via the VPN is not. In theory, this means that the mobile network operator (access point) can view and manipulate the data.

This type of non-end-to-end encrypted transmission is not an option for some applications, such as in smart metering, where the integrity and confidentiality of the transmitted data must be ensured, for example.

As I already mentioned in my previous blog post, we recommend using UDP-based communication protocols for cloud communication via narrowband IoT.

While transport layer security (TLS), a widely used encryption protocol, is available for TCP-based connections, the datagram transport layer security (DTLS) protocol, which is based on TCP, must be used for UDP. However, the number of DTLS implementations, especially on the server side, is manageable compared to TLS implementations.

Nevertheless, DTLS offers a variety of algorithms that can be used for encryption. Those supported include pre-shared key procedures (or PSK for short). A secret key known to the sender and receiver – the cloud platform and the end device in the field in this case – is used to establish an encrypted connection.

Authentication through DTLS

However, neither MQTT-SN or CoAP supports authentication for the connected devices at the moment, regardless of which one is used.

For example, MQTT-SN does not offer the possibility to determine the identity of clients in the current implementation of the specification (v1.2). The CONNECT message transmitted only contains a ClientID. This means that if the clients need to be authenticated, this would have to be implemented in the form of a ‘separate protocol’ based on MQTT-SN.

The lack of authentication may seem sufficient in a closed system, but it requires a high level of trust in the other party. For example, in the case of a narrowband IoT scenario involving the connection of smart meters to a cloud, the globally unique serial number of the meter could be used as ClientID. This means that an attacker would be able to determine external ClientIDs by reading (device) serial numbers or even by simply guessing and reading the data while posing as external devices. This would allow confidential information to be intercepted or messages to be sent to the cloud, which in turn would lead to data being manipulated.

DTLS-PSK can also be used here to compensate for the lack of authentication with MQTT-SN (or CoAP). To establish the secure connection, correct credentials known to the server must be transmitted in the form of a client identifier and a pre-shared key. Incoming MQTT-SN messages can then be assigned to the respective device on the cloud side based on the client identifier used.

DTLS implementations

The number of DTLS implementations that are currently available is manageable, especially on the server side. The existing ones are at best in an experimental stage or are no longer being actively developed. However, the Eclipse project Scandium, developed using the Java programming language, should be highlighted as a positive example of a DTLS implementation that supports a variety of cipher suites and is actively being further developed. This implementation forms the basis for the CoAP implementation Californium, meaning it is used more widely.

Using encryption algorithms implemented in the hardware is vital when using battery-operated devices in particular. This is not only because of the higher processing speed, but above all because of the lower energy requirements.

Algorithms implemented on the software side should definitely be avoided if having a long-lasting power supply is a relevant factor.

Conclusion

Connecting devices via narrowband IoT makes sense in various use cases, but is often also simply necessary due to the operating environment of the devices. Although the technology has been available in Germany for at least a year, the uptake has been slow. The available resources are therefore limited. The biggest hurdle lies in the implementation of security, that is, end-to-end encryption and device authentication.

Nevertheless, nothing stands in the way of using it once the software used has been adapted to the specific use case on both the device and cloud side and the necessary architecture has been created.

If this blog series has piqued your interest or you have an exciting use case for LPWAN technologies, get in touch – we would be happy to advise you.

Do you want to optimise production using data but not have to hunt for it in different software systems and databases? Do you not want to have to ask a specialist about every data query? Then check out our website and learn how Industrial Internet of Things platforms – IIoT platforms for short – can help.

You will find more exciting topics from the adesso world in our latest blog posts.

Also interessing:

• Narrowband IoT – connectivity for special requirements (part 1)
• A protocol stack for narrowband IoT (part 2)