Security (IP)

If using NB-IoT in the IP domain, the end-node will directly contact the application server, complicating the communication protocol choices for battery powered NB-IoT devices. The aim of this section is to go examine the various Internet and

Internet-related protocols suitable for M2M communication in battery-powered end-nodes.

Using IP communication, data sent over NB-IoT can be integrity protected by using either TCP [38] or UDP [39]. Each TCP message does, however, require back-and-forth communication between the server and client [38], while UDP does not. Thus, UDP allows for more flexibility for scheduling communication over NB-IoT. Because of this, battery powered devices such as end-nodes should achieve longer battery life when using UDP rather than TCP.

If leaving the IP communication unencrypted, any end-node and server authorization information is transmitted in plain-text, and may be intercepted, modified or re-transmitted at will. This could lead to unfilterable spam in the application server and unauthorized commands being sent to end-nodes, both of which are fatal to an IoT application.

In order to authenticate the end-node at the application server, at minimum a cryptographic Message Authentication Code of the data must be sent alongside the payload for the server to verify that such a device may access the application server. If the data to be transmitted requires secrecy, the data must be encrypted.

The connection overhead and duration should be simultaneously minimized by the application developer, as there is no gateway converting between on-the-air payloads and IP such as in LoRaWAN and Sigfox.

IP communication can be confidentiality, replay and forgery protected with TLS.

Datagram Transport Layer Security (DTLS), deployed over UDP is a protocol of-fering the same protection as TLS, while preserving the datagram structure of UDP [40]. TLS and DTLS both involve negotiating a secure session between the server and the client before transmitting application data. For the duration of the session, application traffic after the handshake is encrypted by symmetric encryption. A TLS 1.2 full handshake requires two TCP round-trips to the server, and a server certificate must be presented to the client [41]. Similarly, DTLS 1.2 requires three or one and one-half UDP round-trips to initiate and resume a session, respectively, in addition to receiving the same server certificate [42]. The server certificate’s public key certificate size can be multiple kB (For example, the *.google.com certificate is 1995 bytes in the end of 2018 when encoded in DER binary form). Receiving a mostly redundant 2 kB each time the end-node communicates with the application server can be expected to significantly reduce end-node battery life.

In a study by Miranda et al. TLS and it’s effect on energy consumption in mobile

devices using both WLAN and 3G was tested. They found that for the smallest tested transaction sizes of 1 kB in a 3G network, 80 - 90 % of the energy consumed by the device was spent in the TLS handshake [43]. A transaction size of 1 kB is much larger than allowed for Sigfox and LoRaWAN, meaning that for encrypting payloads of under 1 kB, NB-IoT end-nodes using TLS encrypted IP protocols would spend a very significant amount of energy initiating secure sessions, and hardly any for transmitting application payloads.

One client authorization scheme in TLS is to use a client public key certificate [41].

The initial handshake contains a challenge in which the client can cryptographically prove it’s identity to the server. Another scheme is to rely on the eavesdropping protection of TLS and DTLS and have the end-node provide a unique secret on the application level to prove its identity. For example when using HTTPS this could be achieved by using basic access authentication [44], a simple user/password pair.

A client certificate offers the possibility to update the certificate without the server losing trust (via Certificate Authorities), but requires the certificate to be sent by the client in each initial TLS/DTLS handshake, leading to more transmitted data.

The authentication is then valid for the whole session. A user/password pair sent in every request may require less overhead for short sessions with few requests, but the pair can not be updated without server-side changes.

The TLS-PSK cipher suites are a solution within TLS to support authentication via symmetric Pre-Shared Keys (PSK), known only by the client and the server.

Originally defined by the RFC 4279 as the cipher suites beginning with TLS_PSK, benefits of the TLS-PSK cipher suites are the fact that there is no need for costly-to-compute public-key operations and key management can be simplified greatly.

The RFC document specifically mentions clients with pre-configured machine-to-machine connections as a suitable use case. The TLS handshake when using PSKs also requires much less data to be transmitted back and forth, as no certificates are transferred. [45]

PSK cipher suites are also part of the DTLS specification [40], [46], offering the same benefits of lower bandwidth use and less costly encryption and decryption operations [46]. The PSK handshake in DTLS 1.3 allows the client to send application data after just one UDP round-trip, without transferring a server or client certificate either way. [40].

2.6.5 Managing Power Consumption

Two modes of communication in cellular networks have been recently introduced by the 3GPP in order to enable optimization of power consumption in cellular networks.

PSM, introduced in 3GPP Release 12, is designed to enable IoT devices to achieve the specified design goal of 10 year battery life. Turning the radio of the end-node off conserves the most battery, and has always been an option in cellular networks. On subsequent wake up, the device would need to register again with the network, leading to increased power consumption over the lifetime of the device.

PSM configurations enable the end-node to stay attached to the network for a set amount of time without any radio transmissions. [33]

The applied PSM configuration is negotiated jointly by the UE and the network. A device may initiate PSM by providing two timers, T3412 and T3324 to the network.

If accepted by the network, the difference between these two timers defines the PSM cycle during which the UE may keep it’s radio powered off. The UE is also allowed to broadcast uplink data before the expiration of the PSM cycle, for example to send information of an alarm condition. PSM cycle time can reach up to approximately 413 days. A feature that is recommended by the GSMA is to store downlink packets received by the network during PSM, and transmit them once an uplink transmission occurs. [33]

More specifically,Active Timer T3324 controls how long the UE is reachable by the network after the data transfer period. This is shown in figure6 on page 23as the UE reachable period. The Tracking Area Update (TAU) timer T3412 controls the period between the UE signaling it’s existence on the network. [47]

According to a recent Master’s thesis, the average power consumption of the BG96 cellular modem in NB-IoT mode during the data transfer period was roughly 247 mW for 12 s for one Finnish MNO, and 218 mW for 15 s for the other [48]. The experiment fails to specify the values used for timers T3412 and T3324. The power consumption of the following network idle period were roughly 102 mW for 32 s and 66 mW for 43 s. Since the length of the idle period should be set by timer T3324, a shorter idle period duration should reduce total power consumption.

Figure 6: PSM uses the length of the TAU period and PSM cycle to set transmission frequency and downlink availablity. From [33].