Secure data exchange via Narrowband-IoT thanks to DTLS

[suchona.kani.z]

While the first part of this blog series dealt with the Narrowband-IoT technology and in the second part I discussed the special features of communication based on MQTT-SN via NB-IoT, the third and final part of the series focuses on the aspect of security, which is important for the Internet of Things.

Encryption by DTLS
It is possible to establish a connection between the end device and the cloud infrastructure via VPN using the tariffs of the common mobile phone providers. However, there is no real end-to-end encryption in this case. The VPN connection can be encrypted using IPSec, for example, but the data transmitted via the VPN cannot. The mobile phone operator (access point) therefore theoretically has the opportunity to view and manipulate the data.

Depending on the application, for example when the integrity and confidentiality of the transmitted data must be ensured in the area of ​​smart metering, such a non-end-to-end encrypted transmission is not an option.

As already mentioned in the last blog post, it is recommended to cyprus consumer email list use UDP-based communication protocols for cloud communication via Narrowband-IoT.

While a widely used encryption protocol is available for TCP-based connections with Transport Layer Security (TLS), UDP requires the Datagram Transport Layer Security (DTLS) protocol, which is based on TCP. 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. Among other things, pre-shared key methods (PSK for short) are also supported. A secret key that is known to the sender and receiver - i.e. the cloud platform and the end device in the field - is used to establish an encrypted connection.

Authentication through DTLS
Regardless of whether MQTT-SN or CoAP is used as the communication protocol, both protocols initially do not support authentication of the connected devices.

For example, in the current implementation of the specification (v1.2), MQTT-SN does not offer any way to determine the identity of clients. Only a client ID is transmitted in the CONNECT message. If client authentication is required, this would have to be implemented in the form of a "proprietary 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. In the case of a narrowband IoT scenario that involves connecting smart electricity meters to a cloud, the meter's globally unique serial number could, for example, be used as the client ID. An attacker would then have the opportunity to determine other people's client IDs by reading (device) serial numbers or simply guessing them and to read data on behalf of other people's devices. This could allow confidential information to be intercepted or messages to be sent to the cloud, which in turn would lead to data manipulation.