Today's Safer Internet Day was launched in 1999 in several European countries to raise users' awareness of internet safety. However, the topic of safety is highly relevant in almost all areas of the Internet. The Internet of Things (IoT) is no exception.
This article is dedicated to the topic of LoRaWAN security. Some of it can be transferred to other LPWAN technologies.
The Internet of Things phenomenon is characterized by a growing predominance of objects and instances capable of automatic data transfer and each having unique identifiers. The increased density of the IoT infrastructure is mainly due to machine-to-machine (M2M) communication, i.e. sensor systems as found in smart homes or smart cities, industrial automation processes, portable, so-called mobile computing devices, vehicle-to-vehicle communication, etc.
An analysis should not consider a single device in the field in isolation. Rather, all interfaces to gateways, applications and data storage devices, in which large amounts of data are processed and stored, must be considered systemically.
Security challenges exist in all layers of IoT architectures. The effort to reconcile data protection and the requirements of companies and societies is considerable.
An important body in this area is the association of major industry leaders, the Internet of Things Security Foundation (IoTSF). The IoTSF is a collaborative, non-commercial, international response to the complex challenges posed by an expanding and increasingly interconnected world. It achieves its goal by coordinating cooperation between companies and encouraging manufacturers to consider the security of devices and systems from the ground up. Key representatives of the IoTSF include Intel, Huawei, IBM, Thales, Secure-IC, BT, Vodafone, Imagination Technologies, Royal Holloway University of London, Glasgow Caledonian University, NMI and PenTest Partners.
The challenge
A large part of the risks is mainly due to the fact that IoT devices are always on standby after commissioning. This is independent of whether they are really always connected to the network or in standby mode. They only go through an authentication process in the system at the beginning of their life cycle. This makes them very vulnerable from a security perspective.
Safety aspects are not always taken into account during product development. This is a major problem that should be addressed to the same extent as connectivity itself. Some IoT products have outdated embedded operating systems. This is not the only reason why installing system or security updates on IoT devices is a major challenge. Network nodes are usually installed outside or at the customer's site, so it is not uncommon to have a large number of scattered network nodes that are very difficult to monitor and manage.
Making settings or configurations - including security configurations - individually for each network node does not constitute a representative technical solution. The automatic initiation of these network nodes by the manufacturer is also not a particularly reliable solution. Appropriate and proven procedures must prevent updates themselves from becoming security holes.
Some security companies offer special IoT security solutions, such as hard disk encryption or the implementation of tamper-proof components. These solutions enable both advanced digital security and lifecycle management via encryption as well as access restrictions on sensitive data.
The IoT market is largely agreed on the importance of security aspects. The full benefits of new technologies should only be exploited in secure environments.
What security functions does the LoRaWAN standard include?
The LoRaWAN protocol stack is shown in Figure 1. It consists of an application layer, a MAC layer and a PHY layer. The data from the application level is transferred to the MAC user data. The MAC level creates the MAC frame from the MAC user data. The MAC user data contains a frame header (with the source and destination addresses and a frame counter), a frame port and the frame user data (with the application data). The frame port is used to determine whether the frame contains only MAC commands (if it is set to 0) or application-specific data. Finally, the PHY layer uses the MAC frame as the PHY payload, thus creating the PHY frame after the preamble, PHY header, and CRC have been inserted.
Figure 1: LoRaWAN protocol stack
RF parameters include frequencies, power levels, modulation and the basic RF protocols. These are all included in the LoRaWAN RF or physical layer.
Since security integration is extremely important for any wireless network, the LoRaWAN uses two levels of security, as shown in Figure 2: one for the network layer and one for the application layer. The network layer security ensures the authenticity of the device on the network. The application layer security ensures that the network operator has no access to the end user's application data.
Figure 2: The double security levels of the LoRaWAN
A terminal device (network node) must be activated before it can communicate via the LoRaWAN network. Two activation methods are available in LoRaWAN networks: OTAA and ABP.
Over-the-Air Activation (OTAA)
This OTAA method is based on the cooperation between Over-the-Air Messages for Join Requests and Join Accepts. A 64-bit DevEUI, a 64-bit AppEUI, and a 128-bit AppKey are provided for each mobile device (network node). The DevEUI is a unique, global identifier for the device that is comparable to the MAC address of a TCP/IP device. The AppKey is used to cryptographically draw the join request. The AppKey is used when the network node sends a join request message, as shown in Figure 3. The network node sends a join request message consisting of its AppEUI and DevEUI. It also sends a DevNonce - a unique, randomly generated 2-byte value that is used to prevent replay attacks.
Figure 3: The OTAA method in LoRaWAN
These three values are identified via the AppKey of the device with a 4-byte MIC (Message Integrity Code). The server only accepts join requests from devices with known DevEUI and AppEUI values and checks the MIC by matching it with the AppKey.
Figure 4: The elements of a LoRaWAN message
When the server accepts the join request, it responds to the device with a Join Accept message. The application and network servers calculate the two 128-bit keys of the network node: the Application Session Key (AppSKey) and the Network Session Key (NwkSKey). These are calculated based on values sent by the network node in the Join Request message.
Additionally, the application server generates its own nonce value: AppNonce. This is another unique, randomly generated value.
The join-accept response contains the AppNonce, a NetID and an address of the terminal device (DevAddr) together with configuration data for RF delays (RxDelay) and the channels to be used (CFList). The NetID is important for LoRaWAN class B devices. It is a 3-byte value that allows the network nodes to identify that a message has been sent by an internal network gateway. It must therefore have a unique identifier for the corresponding LoRaWAN. The address of the terminal device (DevAddr) in the join-accept response is a 32-bit identifier that is unique within the network.
It is possible to differentiate between end devices that have already joined the network by means of the device address. This allows the network and application servers to use the correct encryption and interpret the data correctly.
When data is received back, it is encrypted with the AppKey. The network node then uses the AppKey to decrypt the data and derives the AppSKey and the NwkSKey from the join-accept message using the AppNonce value.
Activation by Personalization (ABP)
This ABP method differs from OTAA, because the network nodes are sent together with the DevAddr and the two session keys (NwkSKey and AppSKey), which are unique to the network node. Since the network nodes already have the required information and keys, they can begin communication with the network server without having to exchange join messages beforehand.
As soon as a network node has joined a LoRaWAN - either via OTAA or ABP - all future messages are encrypted with a combination of different keys (see also Security in LoRaWAN):
- Network Session Key (NwkSKey) - a security mechanism of the network layer. This key is unique for each end device and is shared between the end device and the network server. The Network Session Key ensures message integrity during communication and secures the communication from end devices to the network server.
- Application Session Key (AppSKey) - This key is responsible for the end-to-end (device-to-device) encryption of user data. It is also an AES 128-bit key that is unique for each device and is shared between the device and the application server. The Application Session Key encrypts and decrypts application data messages and secures application user data.
These two session keys (NwkSKey and AppSKey) are unique for each device and session. If the device is dynamically activated (OTAA), these keys are generated again each time it is activated. If the device is activated statically (ABP), these keys remain until they are changed manually.
Advanced Encryption Standard (AES)
The AES encryption with the key exchange implemented in the LoRaWAN according to the security measures for wireless networks according to IEEE 802.15.4 (shown in Figure 5)
Figure 5: Secured application data transfer in LoRaWAN
The encryption mechanism implemented in the LoRaWAN standard, which is interoperable between manufacturers and network providers, thus creates confidentiality and integrity in end-to-end data transmission.
The strengths of the security functions of the LoRaWAN standard
System security in LoRaWANs is realised through a combination of technical and operational measures. At this point it should be noted that the LoRaWAN was originally developed for devices that are limited to hardware. Furthermore, most applications in the LoRaWAN receive data from distributed sensors. For typical applications the LoRaWAN is a simple, cost-efficient and secure solution.
The strengths of the security functions in the LoRaWAN consist of some best practices:
- OTAA provisioning: When keys and certificates for each session are dynamically transferred between a device and the network and application servers. As devices rejoin networks, their session keys are periodically changed. This is important to avoid potential risks such as spoofing, tempering, etc.
- Dynamically activated devices (OTAA) use the Application Key (AppKey) during the activation process to derive the two Session Keys. In the network, their value is set to the default AppKey, which is then used to activate all devices. The implementation of an individual AppKey for each device is recommended. The decisive factor is that in the entire security process keys are never sent using the over-the-air method. Only the missing parts of a calculation are exchanged from both sides. The generation of keys by intercepting over-the-air traffic is therefore extremely complex.
- The presence of a hardware element for storing security credentials in the device can be beneficial. The extraction of keys by reverse engineering or scanning of device memories is thus considerably more difficult. In addition, secure boot usage should ensure the integrity of the device firmware.
- An additional encryption level at application level is always recommended and should be implemented if necessary.
- To prevent replay attacks, it is important to enable uplink/downlink message counter scanning on the network. The wireless network connection still leaves the possibility of malicious message capture and storage. However, the encryption of messages makes it impossible to read them without the AppSKey. The exchange of messages at the network level is also not possible without the NwkSKey, as the MIC verification would not be successful in this case. The retransmission of messages is possible. These so-called "replay attacks" can be detected and blocked by frame counters. If a device is activated, both frame counters (FCntUp and FCntDown) are set to 0. Each time the device transmits an uplink message, the FCntUp is increased. Each time the network server transmits a downlink message, the FCntDown is increased. If the device or the network receives a message whose frame count is lower than in the last recording, the message is ignored.
- Unlike TCP, the acknowledgement of LoRaWAN data frames is optional. The receiver would then acknowledge this frame with a data frame whose ACK bit was set to 1. This optional frame acknowledgement is ideal for the LoRaWAN because the transmission time of devices is limited. Therefore a certain loss of data packets could be irrelevant. A MIC is added to each frame for verification. This is basically a signature that is calculated over the frame using a Network Session Key. Even if the same user data is transmitted several times, each frame receives a unique signature because the frame counter is incremented for each transmission.
The weaknesses of the security functions of the LoRaWAN standard
Developers of LoRaWAN solutions should be aware that using the LoRaWAN is no guarantee for 100% protection in any security area. This fact can also be transferred to all other wireless technology systems. LoRaWAN solutions should instead be developed with an awareness of possible security risks.
Since LoRaWAN solutions are used in a wide range of systems - from home security solutions to resources for remote control and monitoring infrastructures - attacks and unauthorised use are quite possible.
Some of the main weaknesses of the security functions in the LoRaWAN are
- Encrypted messages have the same length as the key.
- The ABP method sets both session keys permanently, which leads to weaknesses.
- The storage of LoRaWAN keys (AppKey, NwkSKey and AppSKey) is a fundamental problem. Network security must be taken into account at every stage of development and exploitation. Several vulnerabilities exist in terms of key lifecycle management, session key generation, storage and transport, which require careful development and implementation. Giving customers access to device keys is not beneficial to sales. With known side channel attacks, keys can be recovered from the device memory. All device keys should be appropriately secured, e.g. by encryption with master keys, to reduce the risk of their disclosure. The storage of LoRaWAN network server keys is a process for which a complete system solution must be provided.
- Another weakness is the identification and connection processes. Each gateway regularly sends beacons (its individual ID) to the server. This ID can easily be retrieved by attackers. If the ID is known, the gateway can be compromised, for example with a malicious gateway that sends its ID more frequently than the real one.
Some manufacturers take a different approach: retrofitting existing safety elements. This process is not optimal if a system has many distributed components. The implementation is sensitive, complex, demanding and often cannot be carried out in a safe, timely and cost-effective manner.
Conclusion and outlook
The current LoRaWAN standard 1.0.x already includes a relatively high level of security. The risks and attack scenarios listed above are quite justified and should be evaluated individually for each use case. Solution approaches have already been discussed above.
In order to meet the increased security requirements in IoT networks, the LoRa Alliance is constantly working on improving the standard. The LoRa Alliance is a non-profit association of organisations that work together on the standardisation of LPWAN networks.
The new LoRaWAN 1.1 specification was published on 17 October 2017. As the new specification brings significant changes to the existing network protocols and the LoRaWAN communication, the first end devices according to the new specification are expected in 2018 at the earliest. Devices according to the LoRaWAN 1.1 standard are backward compatible with LoRaWAN 1.0.x devices and can also work together with 1.0.2 network servers.
The changes of the LoRaWAN 1.1 specification affect the end devices as well as the gateways and servers. The most important changes are in the communication between end device and gateways as well as in the communication between the servers.
In particular the join replay attacks and the downlink ACK attacks, which are still possible in the current specification 1.0.2.
For this purpose e.g. the Uplink Frame Counter (FCntUp) was included in encrypted form in confirmation messages (ACK Downlinks). With the help of this new feature, the terminal device can recognize which of its messages has been confirmed by the network server.
Further security improvements include the clear separation between network server, join server and application server and the introduction of additional keys such as NwkKey, NwkSEncKey, SNwkSIntKey, FNwkSIntKey and AppSKey. These new keys are especially important for the new Handover Roaming, which enables messages to be actively forwarded from end devices over foreign LoRaWAN networks to the home network of the end device.
Special attention was also paid to the "third party join servers" possible according to specification 1.1. These join servers are no longer managed by the operators of the network servers, but are now provided by a trusted third party. All security-relevant keys of the mobile devices are managed on the join servers and either the network server responsible for transporting the messages or the application server responsible for processing the messages is provided. A clear separation of these responsibilities prevents the network operator from reading the content (payload) of the LoRaWAN messages.
If you would like to be kept up to date on LPWAN security, simply subscribe to our mailing list.
