An improved key distribution and updating mechanism for low power wide area
From the viewpoint of the nationwide LoRa network implementation in the Netherlands
Marcel van Leent (s1728032) Cyber Security Academy
With the introduction of the connected world the interaction between human beings and technology further intensifies. By connecting different things from the physical world like refrigerators and televisions to the internet, the Internet of Things (IoT) is created. Different solutions are introduced to support IoT. One of these solutions is LoRa, which is a low power wide area network that supports the use of a large network of nodes (things). In LoRa, cryptographic keys are being used for confidentiality, integrity and authentication purposes. Because the strength of a cryptographic algorithm lies in the secrecy of the cryptographic key, a proper implementation of key management is necessary. In this thesis, we look at the implementation of key management in LoRa. Several problems are identified which relate to key distribution and key updating on the application layer in LoRa. To resolve these problems, we propose to implement a key distribution and updating mechanism (KDUM). With KDUM it becomes possible to update all secret keys being used in LoRa remotely and perform key distribution while the authenticity of public keys used for key exchange is guaranteed.
Abstract ... II
1. Introduction ... 1
1.1. The connected world ... 1
1.2. Security challenges ... 1
1.3. Securing the connected world ... 2
1.4. Thesis outline ... 4
2. Background ... 5
2.1. What is LoRa ... 5
2.1.1. Low power wide area networks (LPWAN) ... 5
2.1.2. The LoRa architecture ... 6
2.2. Network security ... 7
2.3. Network topologies ... 7
2.4. Key management... 8
2.4.1. Symmetric vs asymmetric algorithms ... 9
2.4.2. Symmetric key management approaches... 11
2.4.3. Types of symmetric keys ... 12
2.4.4. Secret key distribution ... 13
2.4.5. Key agreement ... 14
2.4.6. AES operations ... 14
2.4.7. Message Authentication Codes ... 22
3. LoRa current situation ... 25
3.1. Key management in LoRa ... 25
3.1.1. Types of keys used in LoRa ... 25
3.1.2. Key generation ... 25
3.1.3. Key storage ... 26
3.1.5. Key distribution/agreement ... 31
3.1.6. Key updating ... 31
3.1.7. Key destruction ... 32
3.2. Problems ... 32
4. LoRa KDUM ... 34
4.1. Design requirements ... 34
4.2. Key Distribution and Updating Mechanisms ... 35
4.3. Updating static keys remotely ... 35
4.4. Key distribution ... 37
4.4.1. Diffie-Hellman ... 38
4.4.2. Elliptic Curve Diffie-Hellman ... 39
4.4.3. Protocol selection ... 42
4.5. Authenticity of the public keys ... 43
5. Conclusions and future work ... 47
Definitions, abbreviations and symbols ... 50
Definitions and abbreviations ... 50
Mathematical Symbols... 54
References ... 55
List of figures ... 58
1. Introduction 1.1. The connected world
The influence of technology on our everyday life has changed in the past decade. The
introduction of technologies like tablets, mobile phones and for instance smart televisions, result in the interaction between human beings and technology intensifying. Also, the introduction of RFID for tagging and tracking items has had impact on how humans and technology interact.
By connecting different things from the physical world like refrigerators and televisions to the internet, the Internet of Things (IoT) is created. With the introduction of the Internet of Things (IoT) and networks and technologies that are specifically designed for supporting IoT, the influence of technology on our everyday life continues to increase (Khan & Zaheer, 2012). Continuous interaction and
entanglement between the physical world and cyberspace further intensifies by implementing IoT (e.g. through smart watches, smart cities, smart lighting and factory monitoring).
Networks that support IoT are not aimed to provide high data transfer rates. They are designed to support device communications over long ranges (up to 30 kilometres), using low power (lifetime of up to 10 years on battery power) and against low costs (compared to legacy wireless communications solutions that use licensed spectrum). These characteristics make it feasible for organisations to implement a large-scale network efficiently. Wide-area IoT applications anticipate a need for many hundreds or thousands of end-node devices for each installation. In some cases, such as city-wide parking space/meter monitoring, the numbers can get into the millions. With such high volumes, unit price is a major consideration in determining the return on investment (ROI) for the application (Quinnell, 2015).
1.2. Security challenges
Several security challenges (like data security, key distribution, misuse of sensors, limitations of power and resources) exist in the connected world (Jing, Vasilakos, Wan, Lu, & Qiu, 2014). Sensors are being used to gather and analyse all kind of metrics ranging from the functioning of light posts to the average heartbeat of a person over a certain period. Because devices have a limited amount of computational power, remote servers are being used to store data and perform data analyses. The
gathering and processing of sensor data can be privacy sensitive (data is privacy sensitive if it is traceable to a natural person (European Union, 2016)), therefore it is important that data confidentiality is
One of the challenges in securing machine-to-machine communications is the protection of sensors against malicious parties. As recent events show, sensors can be used to perform largescale DDoS attacks (e.g. the recent attacks on DNS-provider DYN and security-journalist Brian Krebs using the Mirai-botneti). It is therefore important that sensors are protected against unauthorized access using identification and authentication mechanisms.
Because IoT supports machine-to-machine communications (e.g. the monitoring of street lights) it is also important that the integrity of messages is safeguarded. If a third party can alter messages, they can disrupt the functioning of the network which leads to unexpected events and potentially costs. If, for instance, IoT is used for command and control activities of a production plant, the functioning of the production process can be disrupted or even sabotaged (Sadeghi, Wachsmann, & Waidner, 2015).
Organisations may use sensors to track and trace their assets. In IoT assets are not always static in geographic-location and therefore can roam on other networks. Securing communications between a sensor and its server therefore needs to be safeguarded because untrusted networks or networks that are not controlled by the organisation which owns the sensor and server can be used.
Organisations can use sensors for their own processes, but can also use sensors on assets that can be sold to other organisations or customers (e.g. a manufacturer of of-the-shelf IoT devices that can be implemented in IoT networks by other organisations or customers). When ownership of an asset changes, the new owner must be able to connect the sensor to its own server. The old owner or supplier of the sensor should not be able to communicate with the sensor using the secret key that was present during transition.
1.3. Securing the connected world
Low-power Wide-area networks (LPWAN) are developed for coping with aforementioned security challenges. LPWAN is a type of wireless telecommunication network designed to allow long range communications at low bitrates among things (connected objects), such as sensors operated on batteriesii. LPWAN is aimed on machine-to-machine networking environments with lower power consumption, longer range and lower cost than traditional mobile networks like 3g and 4g (Quinnell, 2015). Available LPWAN technologies are for example LoRa, SigFox and NB-IoT.
Because of the introduction of the LoRa network by KPN, the first nationwide IoT supporting network has been rolled out in the Netherlandsiii. This network is aimed on the machine-to-machine market and helps companies automate monitoring of their (remote) equipment by using sensors (within LoRa these are called nodes) that are connected to the LoRa network.
wireless battery operated things in a regional, national or global networkiv. LoRa targets key requirements of IoT such as secure bi-directional communication, mobility and localization services. The goal of LoRa is the roll-out of an IoT supporting network that is secure and can be used by customers to setup their own IoT environments.
As we have seen in the past, network effectsv come into play with the introduction of new information products or information technologies. Due to network effects, organisations choose to launch a new product or technology as soon as possible to become the most valuable network and this leads to products or technologies that do not have security by design (Katz & Shapiro, 1994). With the
introduction of LoRa, the question arises whether the same phenomenon (of launch first, fix later) manifests itself, or that LoRa is secure by design.
Because LoRa relies on cryptographic keys for authentication, integrity checking and
confidentiality purposes, it is important that key management is implemented properly. Key management is the management of cryptographic keys in a cryptosystem and is important because the strength of a cryptographic algorithm rests in the key. This is supported by Kerckhoffs’ principle: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge (Mrdovic & Perunicic, 2008). If an adversary knows the key, there is no necessity to break the algorithm. Key management is the backbone of cryptography and in real-world is the hardest part of cryptography (Schneier, 1996). Key management is therefore focused on key selection, key distribution and key lifetime (Smart, 2010).
The LoRa Alliance, who is responsible for the development of the LoRaWAN specification and supporting the rollout of LoRa networks, has identified that key management is not completely and sufficiently implemented in LoRa (Le Gourrierec, 2016). The ability to update all cryptographic keys in a node or application server (key renewal), over the air (remotely) and using key distribution mechanisms is lacking. These identified problems reside on the application layer of the LoRa network. Hence the main research question of this thesis is:
1.4. Thesis outline
We start by briefly explain what LoRa is (including the LoRa architecture and what low power wide area networks are). After the brief explanation of LoRa we provide some background on network security, key management and network topologies, because these topics are used throughout the rest of this thesis. After the background is set, the current implementation of key management in LoRa is described. Based on the current implementation of key management in LoRa, problems are identified and specifically problems that relate to updating and distributing cryptographic keys within LoRa are
addressed. The current implementation of key management in LoRa is researched based on the
LoRaWAN specification, the implementation of LoRa within the Netherlands and literature review. The literature review is performed using papers, books and available information on the internet.
2. Background 2.1. What is LoRa
LoRa is a low power wide area network (LPWAN) intended for wireless battery operated things in a regional, national or global networkvi. LoRa is developed by the LoRa Alliance, which is an open non-profit organisation of members who are collaborating and sharing experience to develop the LoRaWAN specification and make this the open global standard for secure, carrier-grade LPWAN connectivityvii. LoRa is intended to send and receive low amounts of data over a range of many kilometres without high power costs. In Europe LoRa uses the 868MHz ISM band and is able to transmit over several kilometres (up to 30 kilometres) depending on the environment. Other frequencies are being used in other parts of the world (e.g. 902MHz in the USA and 915MHz in Australiaviii). LoRa is a spread spectrum solution which uses wide bandwidth to help protect against deliberate interference or environmental noise (Miller, 2016).
2.1.1.Low power wide area networks (LPWAN)
LPWAN is a low power wide area network specifically designed for supporting machine-to-machine applications. In comparison to other technologies like 3G or 4G, LPWAN is a low cost solution that uses low data transfer rates (often messages) to extend battery life (sensors using batteries need to run up to 10-15 years), has low energy consumption, is scalable and covers distances up to 15-30 kilometres (Quinnell, 2015).
LPWAN networks are networks that enable the connection and interaction of billions of nodes. These nodes can have several applications (e.g. monitoring, tracking or signalling) and support multiple vertical markets like transportation, health care, energy, factories and buildings (Nolan, Guibene, & Kelly, 2016).
2.1.2.The LoRa architecture
LoRa has a star topology network architecture (see paragraph 2.3) that consists of nodes,
gateways, network servers and application servers (see Figure 1). Nodes are the end devices that are being used by the customer for different purposes. Nodes within LoRa are active, because nodes have a power source and can initiate communications independently. Gateways relay messages between the nodes and the network servers. Gateways are connected to the network server via IP connections (KPN choose to implement IPsecix on these connections) while nodes use single-hop wireless communication to one or many gateways (e.g. for location based services). Communication with the nodes is generally bi-directionalx but mass distribution messages can be usedxi. Communication between the nodes and the gateways is spread out over different frequency bands and data rates. The data rate being used is selected by the gateway based on communication range between the node and the gateway, and the message
duration. A certain data rate is selected by the gateway to limit interference and noise (Sornin et al., 2015).
Figure 1: LoRa network architecture (https://www.lora-alliance.org/What-Is-LoRa/Technology)
Communications between the node and the application server is currently secured using several mechanisms that are explained in chapter 3.
2.2. Network security
Network security is aimed on securing computer networks against different attacks by adversaries. As is described in the book elementary information security, a computer network (also in its simplest form) consists of two parts: hosts and links. A host (or endpoint) is a computer connected to the network. A link is a component that connects the host to other hosts or to the network (Smith, 2013). Networks can have several topologies which we discuss in the next paragraph.
Wireless networks share risks with wired networks, but wireless networks also have some additional risks. Perhaps the most significant source of risks in wireless networks is that the technology’s underlying communications medium, the airwave, is open to intruders, making it the logical equivalent of an Ethernet port in the parking lot (NIST, 2002). Network security problems can be divided roughly into four closely intertwined areas: secrecy, authentication, nonrepudiation, and integrity control (Tanenbaum & Wetherall, 2008). Secrecy, also called confidentiality, has to do with keeping information out of the hands of unauthorized users. Authentication deals with determining whom you are talking to before revealing sensitive information or entering a business deal. Nonrepudiation deals with signatures, proving that someone acted. Finally, integrity control has to do with how you can be sure that a message you received was really the one sent and not something that a malicious adversary modified in transit or concocted (Tanenbaum & Wetherall, 2008). Securing networks (also wireless) means that measures are taken to mitigate the risk of a breach of confidentiality, a breach of integrity or unavailability of the network (this is also known as the CIA triad (Perrin, 2008)). Furthermore, measures should be taken to only grant access to authorized persons and devices.
The network security problem gets a lot of attention from the research community, but the network security problem is far from being solved (Cardenas et al., 2012). A race between security specialists and attackers is frequently seen. One day a solution for a threat or vulnerability is launched and the other day attackers come up with a smarter way to circumvent the countermeasure (Cardenas et al., 2012). The availability requirements of a network for authorized users and equipment makes that solving the network security problem is hard. The most important factor which makes solving the problem hard, is that networks are commonly connected to the internet and major parts of the internet are beyond the control of network administrators (Cardenas et al., 2012).
2.3. Network topologies
topologies are being used nowadays (e.g. ring topology) (Smith, 2013). The five main categories of network structures according to Smith are:
Point-to-point network connects exactly two endpoints together.
Star network connects three or more endpoints through a central node.
Bus network connects all endpoints to a single, shared communications medium.
Tree network connects endpoints through a hierarchy of nodes.
Mesh network connects endpoints through a network of arbitrarily connected nodes.
Each topology has its advantages and disadvantages in relation to growth, addressing, routing, privacy and authentication. Based on the requirements that are set for a network, a topology for a network is chosen. For instance, a star topology has the advantages that it allows growth, only one link is needed between an endpoint and the network, privacy (because traffic only flows between the source and destination) and authenticity (the network can identify an endpoint based on its physical connection) (Smith, 2013). The latter is challenging when using wireless networks because then physical connections are not present. Disadvantages are: limited growth because a central node can only address a certain amount of endpoints and broadcasting is hard (Smith, 2013).
2.4. Key management
Key management is important because of Kerckhoffs’ principle mentioned in paragraph 1.3. If an adversary has possession of the key, it is not necessary to cryptanalyze the cryptographic algorithm (Schneier, 1996). According to NIST key management is:
The activities involving the handling of cryptographic keys and other related security parameters (e.g., passwords) during the entire lifecycle of the keys, including their generation, storage, establishment, entry and output, use and destruction (Barker, 2016).
The relation between key management and the lifecycle of the keys is supported by Schneier. In his book applied cryptography, key management is described as managing cryptographic keys during the entire lifecycle of the key and it consists of: generating keys, distributing keys, storing keys, updating keys, using keys and destroying keys (Schneier, 1996). Smart defines key management as key distribution, key selection, key lifetime and secret sharing (Smart, 2010). If we look at the description of key
management that Smart describes in his book, we see that these are in line with the key management life cycle description that Schneier describes.
We give a short description of the key management life-cycle stages. The first stage of the key management life-cycle is key generation. To generate a proper random secret key, it is best to use an automated process using a reliable random source or a cryptographically secure pseudo-random-bit generator. Cryptographically secure random-bit generators make use of several unpredictable information to generate a key (Schneier, 1996).
The second stage of the key management life-cycle is key distribution. Key distribution can be performed in three different ways namely physical, using symmetric key protocols and using public key protocols. How to implement key distribution depends on the overall situation (Smart, 2010).
The third stage of the key management life-cycle is key storage. Keys should be kept secret and therefore should be stored securely (in an encrypted form). In order to do this properly, two different secret keys should be used for communicating and storing the communicating key(s) (Schneier, 1996).
The fourth stage of the key management life-cycle is key updating. There are situations where distributing new keys is harder than generating a new key from the old key. This process is called key updating. A one-way function is used to generate the new key from the old key (Schneier, 1996).
The fifth stage of the key management life-cycle is key usage. Keys are being used for different purposes (e.g. encryption and decryption) and should be kept secret while being used. Applications can often use session keys which are only valid during one session and this safeguards the confidentiality of prior and further communications (Schneier, 1996).
The sixth and final stage of the key management life-cycle is key destruction. Destruction of secret keys can be performed relatively easy by deleting the secret key from memory. To do this properly the memory should be overwritten multiple times. An adversary should not have knowledge of which secret keys are destroyed, because if an adversary knows the destroyed secret key, the adversary can read old messages (Schneier, 1996).
2.4.1.Symmetric vs asymmetric algorithms
The main difference between a symmetric and asymmetric algorithm is that a symmetric algorithm uses one secret key (K) to encrypt and decrypt messages. A disadvantage of symmetric algorithms is that it requires the prior communication of the secret key (Stinson, 2005). An asymmetric (or public key) algorithm uses a key pair which consists of a public key that is used for encryption and a private key that is used for decryption. Next, we describe how symmetric and asymmetric algorithms function.
decryption functions are public and the secrecy of the plaintext given the ciphertext completely relies on the secrecy of the secret key (Smart, 2010). In mathematical notation, the functions are written:
= ( ) for encryption and = ( ) for decryption.
From the above we can conclude that each party needs to have the secret key to be able to encrypt and decrypt messages. The secret key needs to be kept secret (the secret key may only be known to authorized parties) to guarantee confidentiality of the communication.
As mentioned asymmetric (or public key) algorithms use a key pair, which consists of a public key and a private key. The public key can be published and the private key needs to remain secret to the owner of the key (Smart, 2010). The idea is that party A encrypts the message he wants to send to party B, using the public key of party B and sends the ciphertext to party B. Party B uses its private key to decrypt the ciphertext into the original message. Thus the idea behind asymmetric algorithms is that it is
computationally infeasible to determine the plaintext given the ciphertext without knowledge of the private key (Stinson, 2005).
Asymmetric algorithms rely on one-way functions to be effective. A one-way function is a mathematical operation that is easy to do one-way, e.g. encryption, but which is hard to do the other way, e.g. decryption, without some special secret information (Smart, 2010). There are several well studied one-way functions that are being used in asymmetric algorithms, like factoring integers, computing discrete logarithms or computing square roots modulo a composite number (Smart, 2010).
We give an example of a function that is believed to be one-way and is used by RSA. Suppose N is the product of two large primes p and q ( = ). Using the two large primes, e must be a prime
number and selected so that: , ( − 1)( − 1) = 1. The public key is then (e,N). The encryption function is written as: = ( ). The private key (d,N) should be determined so that ( ) = 1 ( ). The decryption function is written as: = ( ).
Figure 2:Approaches for symmetric key usage between nodes and servers 2.4.2.Symmetric key management approaches
When using symmetric algorithms, different approaches can be used to secure communications using cryptographic keys. Four different approaches (Roman et al., 2011) can be used to secure
communications in a network consisting of nodes (or clients) and servers and using symmetric algorithms. These possible approaches are depicted in Figure 2. Each approach has its advantages and disadvantages.
The first approach is the 1-1 approach. This means that all the clients and servers communicate with each other using one secret key. Using one secret key throughout the network makes management of the key relatively easy because only one key is managed, however it comes with a cost. If the
confidentiality of the key is breached, all information in nodes and servers and communication between nodes and servers is breached. Especially when nodes reside in ‘hostile’ environmentsxiii, this approach has a high risk because adversaries can gain physical access to one node and try to extract the key from the node using e.g. a side channel attack (Sadeghi et al., 2015). Furthermore, identification of individual nodes and servers using secret keys is not possible because all the nodes and servers use the same secret key. Distribution of the secret key is performed off-band. The secret key needs to be known, upfront, for a node or server to commence communication. The secret key needs to be updated off-band in all nodes and servers before communications recommence.
secret key is performed off-band. Each node that needs to communicate with a server need to have the secret key before commencing communication. The secret key needs to be updated in the server and distributed off-band to all the nodes that connect to the server which secret key is updated before communications recommence.
The third approach is the N-1 approach. In this approach, each node has its own unique secret key. Each server needs to store all the secret keys of the nodes that connect to that server. Whenever a node’s secret key becomes known to an adversary, only that node and its communication towards the server is compromised. Other nodes are not affected by the secret key being compromised. Because of this characteristic, the use of this approach is well suited for nodes in hostile environments. However, if the server is compromised, the complete network is compromised because the server stores all secret key material for all the nodes it communicates with. Through this approach nodes can be identified by the server using the secret key, identification of the server by the node is not possible because the secret key is unique for the node. Distribution of the secret key is performed off-band. The secret key of a node needs to be known by the server before commencing communication. The secret key is updated in the node and is distributed off-band to the servers the node communicates with before communications recommence.
The fourth and final approach is the N-N approach. In this approach, each node and server has its own unique secret key. To commence communication each client and server must establish a shared secret key which is based on both their secret keys. For this purpose, a key-exchange algorithm (e.g. Diffie-Hellman or quantum key exchange) can be used (Heer et al., 2011). Using the secret keys of a node and a server and a key exchange algorithm, a shared secret key is generated that is used for
communication between the node and the server. If the shared secret key becomes known, only the communication between the specific node and server is compromised. This approach is well suited to be used in hostile environments. An identification scheme is necessary for nodes and servers to identify and authenticate each other. Using a key exchange algorithm makes distribution of the secret keys possible without the necessity to distribute the secret keys off-band. Updating the secret key is performed in the node or server and using the key exchange algorithm, a new shared secret key is generated that is used in further communications between the node and the server.
2.4.3.Types of symmetric keys
When using symmetric keys, it is necessary to understand that two types of symmetric keys exist. Smart (Smart, 2010) and Stinson (Stinson, 2005) both identify the following types of keys:
Static (or long-lived) keys;
Static keys are being used for a long period. The exact definition of long depends on the application, but this could mean from a few hours to a few years. The compromise of a static key is usually considered to be a problem, with potentially catastrophic consequences (Smart, 2010).
Furthermore, static keys can be pre-computed and should be stored securely. Static keys could be known to a pair of users, or to a user and a trusted authority (TA). Static keys are often used in protocols to transmit encrypted session keys (Stinson, 2005).
Session keys have a short life-time, their lifetime equals the lifetime of a communication session (this could mean a few seconds or hours). They are usually used to provide confidentiality for the given period. The compromise of a session key should only result in the compromise of that session’s secrecy and it should not affect the long-term security of the system (Smart, 2010).
2.4.4.Secret key distribution
Key distribution is one of the fundamental problems with cryptography (Smart, 2010). Key distribution is a mechanism whereby one party chooses a secret key or keys and transmits them to another party or parties securely (Stinson, 2005). Asymmetric algorithms (see 2.4.1) have the benefit that a public key is used which can be communicated using non-secure channels. But, asymmetric algorithms are slower than symmetric algorithms and symmetric keys are therefore usually used to encrypt long messages and streaming messages (Stinson, 2005).
Stinson identifies two types of key distribution mechanisms: key pre-distribution and session key distribution. With key pre-distribution, a trusted authority distributes keying information “ahead of time” “off band” (e.g. not using the network) to each authorized user in the network (Stinson, 1997). Later, users can use this key information to encrypt and decrypt messages which are sent over the network using symmetric or asymmetric key protocols. Pre-distribution of secret keys is commonly performed
physically but can also be performed using asymmetric key protocols (Smart, 2010). Once some key information is exchanged, symmetric or asymmetric key protocols can be used to distribute further key information like session keys (Smart, 2010).
Key agreement denotes a protocol whereby two (or more) parties jointly establish a secret key by communicating over a public channel (Stinson, 2005). In a key agreement scheme, the value of the secret key is determined as a function of inputs provided by both parties and secret information of both parties. The secret key is not transported from one party to the other as with the session key distribution scheme (Stinson, 2005).
Using key agreement two parties can generate a new secret key using e.g. Diffie-Hellman or they can generate a new secret key based on the old key in addition with an input (e.g. a nonce). An advantage is that no secret key information is sent over an unsecure channel and an adversary can only intercept the inputs. As we have seen in paragraph 2.4 the strength of an algorithm rests in the secrecy of the key. The algorithm may be known as well as some inputs, but as long as the secret key (old and new) remains secret, it is infeasible for an adversary to determine the new secret key (Maurer, 1993).
Because LPWAN networks including LoRa use AES for encryption and decryption of messages it is important to understand the operations of AES. As we have discussed in paragraph 2.4.1, AES is used because it is fast, it consumes low energy and is secure using a 128-bits key length. The key length used has a negative impact on the energy consumption. The longer the key length, the more energy is consumed (Potlapally et al., 2003). In this paragraph, we give a high-level description of the operations of AESxiv. AES (or Rijndael) is a symmetric algorithm which was selected by NIST as the successor for DES (Fips, 2001). A successor for DES (and 3DES) was needed because DES is cracked. 3DES is still deemed secure by NIST up until 2030 (Barker, 2016), however 3DES is much slower and uses more energy than AES (Potlapally et al., 2003). Therefore, AES is chosen as the algorithm to be used in LPWAN networks including LoRa.
AES uses a block length of 128-bits and supports the use of three different key lengths (128-, 192- and 256-bits) (Fips, 2001). AES is an iterated cipher, because the number of rounds depends on the key length (10 rounds for 128-bits, 12 rounds for 192-bits and 14 rounds for 256-bits) (Fips, 2001).
Figure 3: AES operations when using a secret key length of 128-bit (http://frontjang.info/entry/AES)
The plaintext is transformed into a State (see Figure 4). State is the intermediate cipher result that can be pictured as a rectangular array of bytes, having four rows and four columns (Fips, 2001). A
We now have described the high-level functioning of encryption with AES. To decrypt, it is necessary to perform all operations in the reverse order and using inverse functions (see Figure 3). At this time AES is secure against all known practical attacksxv that would allow an adversary to decrypt
correctly implemented AES encrypted data (Stinson, 2005).
Modes of operation
AES has five modes of operation: electronic codebook (ECB), cipher block chaining (CBC), cipher feedback (CFB), output feedback (OFB) and counter (CTR) (Dworkin, 2005). The three last modes of operation of AES (CFB, OFB and CTR) are stream cipher modes. These modes turns a block cipher in a stream cipher (Smart, 2010). For all of the modes of operation the plaintext must be represented as a sequence of bit strings, the requirements on the lengths of the bit strings vary per mode (Dworkin, 2001). For ECB and CBC modes the number of bits in the plaintext must be a multiple of the block size (in case of AES a multiple of 128-bits). If the plaintext number of bits is not equal to a multiple of the block size, padding of the plaintext is necessary (Dworkin, 2001). The stream cipher modes of operation generate a pseudo random stream of data that may or may not depend the plaintext. Because of the use of a generated pseudo random stream of data padding of the plaintext is not necessary.
The first block cipher mode we discuss is ECB. ECB is the simplest mode of operation. In ECB encryption, the forward cipher function is applied directly and independently to each block of the plaintext (Dworkin, 2001). For decryption, the inverse cipher function is applied directly and
independently to the ciphertext. The plaintext is divided in a series of blocks (n) with a length equal to the key length used for encryption (see Figure 5). The last block may be padded to match the key length used. ECB is defined as follows:
Encryption: = ( ) for = 1 …
Decryption: = ( ) for = 1 …
There are three problems with using AES in ECB mode. The first problem with ECB is that the same input block (plaintext) results in the same output block (ciphertext) when the same secret key is used. The second problem is that deletion of blocks cannot be detected, because each block is
blocks from other (old) messages (Smart, 2010). A replay attack is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayedxvi. Because of these problems, it is generally better to not use ECB but rather use CBC.
In the case of small messages (smaller or equal to the key length being used) ECB can be used. In order to prevent having the same ciphertext when encrypting the same plaintext, different (session) keys must be used to encrypt messages (Bruce, 2013).
Figure 5: ECB mode of operation (Dworkin, 2001)
The second block cipher mode we discuss is CBC. CBC chains the cipher and in this way, adds context to each ciphertext block. With CBC, the plaintext is divided into a series of blocks (n) with a length equal to the key length used. The last block may be padded to match the key length used. An initialization vector (IV) is used to XOR the plaintext of the first block. The IV is used to make sure that two encryptions of the same plaintext produce different ciphertexts (Smart, 2010). The CBC mode of operation is illustrated in Figure 6. CBC is defined as follows:
Encryption: = ( ⊕ )
= ( ⊕ ) for = 2 …
Decryption: = ( ) ⊕
= ( ) ⊕ for = 2 …
Figure 6: CBC mode of operation (Dworkin, 2001)
As mentioned, there are three stream cipher modes of operations (OFB, CFB and CTR). A stream cipher mode of operation generate a pseudo random stream of data that may or may not depend on the plaintext. The first stream cipher mode we discuss is the CFB mode. CFB is a mode that features the feedback of successive ciphertext segments into the input blocks of the forward cipher to generate output blocks that are XORed with the plaintext to produce the ciphertext, and vice versa. The CFB mode requires an IV as the initial input block (Dworkin, 2001).
The CFB mode also requires an integer parameter, denoted s, such that 1 . In the specification of the CFB mode, each plaintext segment ( # ) and ciphertext segment ( #) consists of s
bits (Dworkin, 2001). CFB is defined as follows: Encryption: =
= # for = 2 …
= ( ) for = 1,2 …
# = # ⊕ ( ) for = 1,2 … Decryption: =
= # for = 2 …
= ( ) for = 1,2 …
With CFB encryption, the first input block is the IV, and the forward cipher operation is applied to the IV to produce the first output block. The first ciphertext segment is produced by XORing the first plaintext segment with the s most significant bits of the first output block. (The remaining b-s bits of the first output block are discarded.) The b-s least significant bits of the IV are then concatenated with the s bits of the first ciphertext segment to form the second input block. The process is repeated with the successive input blocks until a ciphertext segment is produced from every plaintext segment (Dworkin, 2001).
With CFB decryption, the IV is the first input block, and each successive input block is formed as in CFB encryption. The forward cipher function is applied to each input block to produce the output blocks. The s most significant bits of the output blocks are XORed with the corresponding ciphertext segments to recover the plaintext segments (Dworkin, 2001). The CFB mode of operation is illustrated in Figure 7.
Figure 7: CFB mode of operation (Dworkin, 2001)
The second stream cipher mode we discuss is the OFB mode. The OFB mode is a mode that features the iteration of the forward cipher on an IV to generate a sequence of output blocks that are XORed with the plaintext to produce the ciphertext, and vice versa. The OFB mode requires that the IV is a nonce, i.e., the IV must be unique for each execution of the mode under the given key (Dworkin, 2001). OFB is defined as follows:
= ( ) for = 1,2 …
= ⊕ for = 1,2 … − 1
= ⊕ ( )
= for = 2 …
= ( ) for = 1,2 …
= ⊕ for = 1,2 … − 1
= ⊕ ( )
With OFB encryption, the IV is transformed by the forward cipher function to produce the first output block. The first output block is XORed with the first plaintext block to produce the first ciphertext block. The forward cipher function is then invoked on the first output block to produce the second output block. The successive output blocks are produced from applying the forward cipher function to the previous output blocks, and the output blocks are XORed with the corresponding plaintext blocks to produce the ciphertext blocks. For the last block, which may be a partial block of u bits, the most
significant u bits of the last output block are used for the XOR operation; the remaining b-u bits of the last output block are discarded (Dworkin, 2001).
With OFB decryption, the IV is transformed by the forward cipher function to produce the first output block. The first output block is XORed with the first ciphertext block to recover the first plaintext block. The first output block is then transformed by the forward cipher function to produce the second output block. The successive output blocks are produced from applying the forward cipher function to the previous output blocks, and the output blocks are XORed with the corresponding ciphertext blocks to recover the plaintext blocks. For the last block, which may be a partial block of u bits, the most significant u bits of the last output block are used for the XOR operation; the remaining b-u bits of the last output block are discarded (Dworkin, 2001). The OFB mode of operation is illustrated in Figure 8.
Figure 8: OFB mode of operation (Dworkin, 2001)
The last mode of operation we discuss is the CTR stream cipher mode of operation. The CTR mode is a mode that features the application of the forward cipher to a set of input blocks, called counters, to produce a sequence of output blocks that are XORed with the plaintext to produce the ciphertext, and vice versa. The sequence of counters must have the property that each block in the sequence is different from every other block (Dworkin, 2001). Given a sequence of counters, T1, T2, … , T , the CTR mode is defined as follows:
Encryption = ( ) for = 1,2 …
= ⊕ for = 1,2 … − 1
= ⊕ ( )
Decrypion: = ( ) for = 1,2 …
= ⊕ for = 1,2 … − 1
= ⊕ ( )
With CTR decryption, the forward cipher function is invoked on each counter block, and the resulting output blocks are XORed with the corresponding ciphertext blocks to recover the plaintext blocks. For the last block, which may be a partial block of u bits, the most significant u bits of the last output block are used for the XOR operation; the remaining b-u bits of the last output block are discarded (Dworkin, 2001).
In both CTR encryption and CTR decryption, the forward cipher functions can be performed in parallel; similarly, the plaintext block that corresponds to any particular ciphertext block can be recovered independently from the other plaintext blocks if the corresponding counter block can be determined (Dworkin, 2001). The CTR mode of operation is illustrated in Figure 9.
Figure 9: CTR mode of operation (Dworkin, 2001)
2.4.7.Message Authentication Codes
Figure 10: MAC-then-Encrypt (MtE)
because no secret key is being used. With a hash function a party only has to know the message and which algorithm is used to generate and validate the hash.
The purpose of a MAC is not safeguarding confidentiality, but integrity. If the message sent is not encrypted, then secrecy of the message is not guaranteed while using a MAC. There are three general approaches possible when using a MAC with authenticated encryption (Krawczyk, 2001). If the
confidentiality and integrity of the ciphertext must be guaranteed, the message must be encrypted prior to applying the MAC (also called Encrypt-then-MAC see Figure 11).
Figure 11: Encrypt-then-MAC (EtM)
When the integrity of the plaintext and not the ciphertext must be guaranteed the MAC has to be generated over the plaintext prior to encryption of the message. One can choose to include the MAC with the plaintext and then encrypt (also called MAC-then-Encrypt see Figure 10) or one can choose to encrypt the plaintext and send the MAC unencrypted (also called Encrypt-and-MAC see Figure 12).
As Krawczyk states in his paper on the order of encryption and authentication for protecting communications, separate keys should be used for encryption and MAC generation (Krawczyk, 2001). If the same secret key is used for both activities, an adversary with knowledge of the secret key is able to decrypt the ciphertext, alter the plaintext, encrypt the altered plaintext and generate a new MAC that seems valid for the receiver. The receiver in this case has no means to detect manipulations of the original plaintext. By using two separate keys, an adversary must know both secret keys to alter messages and generate a valid MAC without being detected.
One popular way to construct a MAC and which is also implemented in LoRa is by using a block cipher in CBC mode (a so called CMAC) with a fixed initialization factor (Stinson, 2005). NIST
published a special publication on the functioning of CMAC (Dworkin, 2005). With CMAC two sub keys (K1 and K2) are generated from the cipher key K. The message is broken down in different blocks equal to the used key length K. In several rounds the CMAC is generated over each block using a cipher (CIPH) and the result is XORed with the next block prior to performing the next ciphering. If the last block is equal to the key length, K1 is used to XOR the last block prior to the final encipherment. If the length of the block is smaller than the key length, the block is padded with a single bit ‘1’ and a string of ‘0’ bits so that the block length equals the key length. K2 is then used to XOR the last block prior to the final encipherment (see Figure 13).
Figure 13: Illustration of the two cases of CMAC generation (Dworkin, 2005)
As we have seen in paragraph 2.4.6 LPWAN networks including LoRa use symmetric algorithms in block cipher mode to encrypt and decrypt data messages. We also saw that this is done because
3. LoRa current situation 3.1. Key management in LoRa
Within LoRa cryptographic keys are being used for confidentiality (encryption and decryption of messages), integrity (MIC computing) and authentication purposes (a node identifies itself to the
application server using its pre-shared secret key) (Sornin et al., 2015). The management of these secret keys is important to guarantee the confidentiality and integrity of messages as well as the authentication of nodes. As mentioned in the introduction, the LoRa Alliance has identified that a complete
implementation of key management in LoRa is missing (Le Gourrierec, 2016).
LoRa has the requirement that every node has a unique static key that is pre-shared manually with the application server (Sornin et al., 2015). The use of a unique key per node results in resilience to cyber-attacks because if one key is known, only one node is vulnerable to an adversary. The symmetric key management approach that is currently used in LoRa is a N-1 approach (see paragraph 0 for a description of the approaches).
To identify problems with key management in LoRa, we use the key management life cycle (Schneier, 1996) to assess the implementation. We start by determining which types of keys are being used in LoRa and assess per type if each of the key management life cycle stages is implemented.
3.1.1.Types of keys used in LoRa
As we have seen in 2.4.3 in key management there are two types of keys, namely static (or long-lived) and session keys. Within LoRa, these types are being used on the application layer. The static key that is being used in LoRa is called the AppKey (Sornin et al., 2015). The AppKey is a pre-shared 128-bit AES key that is known by the node and application server.
LoRa uses two different session keys which are called the AppSKey (an application session key specific for the node) and the NwkSKey (a network session key specific for the node) (Sornin et al., 2015). These keys are not reused in LoRa (except for retransmission purposes) and are renewed each new
session. The session keys are 128-bit AES keys that are being generated using the AppKey and some additional random information including a nonce generated by the node and a nonce generated by the application server (Sornin et al., 2015).
be unique for the network of nodes connected to the application server. The AppKey is registered in the node by the administrator manually while having physical access to the node. It is not possible to update the AppKey remotely in LoRa. The AppKey can only be updated manually while having physical access to the node.
Session keys are generated per node per session in LoRa using the AppKey (K), some random information and the AES algorithm. Using the AppKey and four additional inputs an AppSKey or NwkSKey is generated (see Figure 14). For generating the AppSKey the following four inputs are used: The node generates a 16-bits pseudo random nonce (called the DevNonce) that is shared with the application server. The application server generates a 22-bits pseudo random nonce (called the
AppNonce) that is shared with the node. Furthermore a 22-bit manually pre-shared NetID and standard 32-bit code (for AppSKey this is 0x01) is used. The resulting message is padded to 128-bits and using the AppKey an AppSKey is generated as follows:
= _ ( , | | | | )
Figure 14: Generating session keys in LoRa
For generating the NwkSKey almost the same inputs are being used. The only difference is the standard code. The standard code used for generating a NwkSKey is 0x02. The generation of a NwkSKey is performed as follows:
= _ ( , | | | | )
other nodes. In a node, the key material is stored in the Electrically erasable programmable ROM (EEPROM). EEPROM holds application data and programs, such as the protocols that the node can execute. It also holds data that may vary with time such as session keys (Stallings, 2011). Data stored on the EEPROM is not encrypted and can be read by an adversary using a side channel attack (Sadeghi et al., 2015). By obtaining the secret keys from a node, an adversary can determine all session keys, decrypt all data messages send from and to the node as well as spoofing messages from and towards the node. There are ways to protect the EEPROM against side-channel-attacks (NIST, 2001) by using for example resin.
As discussed, the application server stores all the keys of all the nodes connected to the
application server. How to store the secret keys in the application server is not part of the LoRa solution. This is the responsibility of the customer who owns the application server. However, it is advisable to store the secret keys in the application server secure using proper encryption and a separate secret key only used for encrypting the storage (Barker, 2016).
As discussed, secret keys are being used in LoRa for confidentiality, integrity and authentication purposes. Secret keys are being used on multiple layers in the LoRa network (see Figure 15).
Figure 15: Use of encryption on the different layers in LoRa (https://www.lora-alliance.org/What-Is-LoRa/Technology)
messages sent between a node and the application server. LoRa uses an Encrypt-then-MAC approach (see Figure 11) with often two different session keys (see paragraph 126.96.36.199). Through this a verification of the integrity of the ciphertext is performed.
Within LoRa, AES is used in the ECB (for join accept messages) and CTR (for all other data messages) mode of operations (Sornin et al., 2015). ECB is used to encrypt join accept messages because a node only has the ability to encrypt messages. This implementation is chosen because nodes have limited processing and memory capabilities. Therefore, the application server performs a decryption of the message to create a ciphertext that can be decrypted by the node using its encryption function (Sornin et al., 2015). This implementation choice has a drawback, because a message that is sent and is the same as another message sent, results in an equal ciphertext. In LoRa this drawback of ECB is limited because join accept messages are smaller or equal to 128-bits and vary because it contains the random AppNonce.
CTR mode is used for all other data messages, because with the use of CTR and the use of CMAC for MAC computations, authenticated encryption is performed. By using nonces, message encryption is possible without per message randomness. Decryption and encryption can be performed in parallel and transmission errors only effect the wrong bits and nothing more.
The LoRa alliance choose to use a symmetric algorithm, because symmetrical algorithms use less energy than asymmetric algorithms and are faster in encryption and decryption (Potlapally et al., 2003). Wander shows in his research that the energy consumption of AES is several micro-joule and the energy consumption of for example RSA is tens of milli-joule (Wander et al., 2005). AES was also chosen by the LoRa Alliance because it only needs a 128-bit key size to be considered secure and other symmetrical algorithms like DES, 3DES, RC6 and Blowfish are vulnerable to cryptanalysis (Mathur, 2013) and use more energy (Potlapally et al., 2003).
A node’s static key (AppKey) is only used by the application server to encrypt join accept
Figure 16: Encryption of a message with AES
Session keys (AppSKey and NwkSKey) are used to encrypt all further message payloads between the node and the application server as long as the lifetime of the session. Encryption is performed as depicted in Figure 16 where K is the AppSKey or the NwkSKey (depending on which key is used for encryption). Whether the AppSKey or the NwkSKey is used depends on the message send. The NwkSKey is only used for messages with FPort = 0. The FPort in LoRa identifies what kind of information is being send with the payload. If the message payload consists of MAC commands only, FPort 0 is set and the message payload is encrypted with the NwkSKey. If FPort is in the range of 1..223 then the AppSKey is used to encrypt the message payload. It should be noted that FPort is not send encrypted between the node and the application server. The FPort is not encrypted, because otherwise the node or application server has no knowledge on which session key to use to decrypt the received
ciphertext (Sornin et al., 2015).
A node’s static key (AppKey) is only used by the node for decryption of join accept messages send by the application server. The AppKey is not used for any other decryption actions. For those decryption actions session keys are used (Sornin et al., 2015). Figure 17 shows the decryption of a ciphertext using K, where K in this case is the AppKey.
Figure 17: Decryption of a ciphertext in LoRa
message. If FPort is 0 then the NwkSKey is used, if FPort is in de range of 1..223 then the AppSKey is used (Sornin et al., 2015). Decrypting a received ciphertext is depicted in Figure 17 where K depicts the AppSKey or the NwkSKey and is selected based on the FPort received (if FPort = 0 then the NwkSKey is used, if FPort = 1..223 the AppSKey is used).
188.8.131.52. Message integrity code for integrity and authentication
LoRa makes use of message integrity codes (MIC) for integrity and authentication purposes. Within LoRa CMAC (also see paragraph 2.4.7) is used for generating a MIC and an Encrypt-then-MAC approach is being used, to guarantee the authenticity and integrity of the ciphertext being send.
The Encrypt-then-MAC approach is used because it is the only approach that is generally secure and ensures the receiving end only reads valid messages (Krawczyk, 2001). Furthermore, the receiving party can verify the integrity and authenticity of the received data message without the need to decrypt the message first. To prevent padding oracle attacks in ECB mode of operations and changes to the ciphertext in CTR mode of operations, the MAC is calculated over the ciphertext instead of over the plaintext. The Encrypt-and-MAC approach is not generally secure because the MAC leaks information about the plaintext. The MAC-then-Encrypt approach is malleable because it may be possible altering the message and make it appear to be valid and have a valid MAC (Krawczyk, 2001).
The MIC is computed over the ciphertext being send using a standard initialization vector (IV) which equals zero and key K. Dependent on the message send, K is the AppKey (for join requests and join accept messages) or the NwkSKey (for all data messages). In LoRa the AppSKey is not used for MIC computations but only for encryption and decryption of data messages (Sornin et al., 2015). As we saw in paragraph 184.108.40.206 the NwkSKey is also used for encryption of data messages consisting of only mac codes and having FPort = 0. For these data messages the NwkSKey is used for encryption as well as for MIC computing. The use of a single key for both encryption and MIC computing is a risk, because if an adversary has knowledge of the NwkSKey, they can decrypt, alter and encrypt the data message and also compute a valid MIC. Through this the adversary can alter mac commands in the data message which potentially leads to misconfigurations in the network.
MIC’s are computed over join request and accept messages as well as over data messages. A MIC is computed over a join request or join accept message using the AppKey. Through the MIC an
Figure 18: MIC computation in LoRa
As we saw earlier LoRa makes use of the Encrypt-then-MAC approach. This means each data message is encrypted using the AppSKey or the NwkSKey and a MIC is computed over the ciphertext using the NwkSKey. Through this the integrity of the ciphertext as well as the plaintext is guaranteed and the receiver can verify the identity of the sender of the data message. In case of a message consisting of only mac commands and having FPort = 0, the NwkSKey is used both for encryption and MIC computing.
Key distribution and key agreement mechanisms for static keys are currently not present in LoRa (Le Gourrierec, 2016). As we have identified in paragraph 3.1 LoRa uses an N-1 symmetric key
management approach. Static keys are pre-distributed manually in the node and the application server prior to installation of the node.
Session keys are distributed, through generating them in the node as well as in the application server. Because the same static key and inputs (see Figure 14) are used to generate session keys, this results in the same session key in the node and application server (Sornin et al., 2015). Because the computed session keys in the node and the application server are equal, session keys can be used for encrypting and decrypting messages as well as for MIC computations.
because they are for instance integrated in paving stones. This makes the need for remote updating of static keys in nodes important.
Session keys are being updated (or renewed) each session. New session keys are generated as described in paragraph 3.1.2. After the new session keys are generated, the old session keys are overwritten in the node and the application server.
Key destruction is not part of the LoRa specification and should be separately implemented by the administrator of the network. Static keys currently have the same lifetime as the lifetime of the node. In the application server, static keys must be deleted manually after decommissioning of the node. Static keys must be manually destroyed by the administrator in the application server whenever a node is decommissioned from the network.
Session keys in the node and application server have the lifetime of a session. After the session is ended, the session keys used in the last session are still available in the node and application server. These session keys are overwritten by new session keys after a new session has been setup (Sornin et al., 2015).
Based on the current situation described above we have identified problems which relate to key management in LoRa. We have identified problems in almost all stages of the key management life-cycle. Per stage we describe the identified problems and determine the problems that we solve in this thesis.
The first problems we identify are part of the key storage stage. As mentioned, secret keys are stored in the EEPROM of the node. The EEPROM is not protected against side-channel attacks and using such an attack, an adversary can extract all key material. Because protecting the EEPROM physically (preventative measure) raises the cost of a node, it is better to implement corrective measures which can be used to update the secret keys in the nodes whenever it becomes clear that the confidentiality of secret keys is breached.
distribution mechanisms available in LoRa makes LoRa resilient against such an incident, because an engineer does not have to visit all sides where nodes are installed.
We also found problems in the key usage stage of LoRa. In LoRa, AES is being used in ECB mode for encryption and decryption. With ECB mode of operation there are three problems (see
paragraph 2.4.6). These problems however are mitigated by using session keys, using ECB only on small join accept messages and using an Encrypt-then-MAC approach.
When data messages in LoRa only contain mac commands (message has FPort =0), the same session key (NwkSKey) is being used for encryption and MIC computing. If an adversary gains
knowledge of the session key, that party can manipulate messages which can lead to misconfigurations in the network.
Also in the key distribution stage, we identified problems. LoRa does not have any mechanisms in place to perform key distribution or key agreement of static keys. Currently it is only possible to manually pre-share the static keys in LoRa. The absence of key distribution and key agreement
mechanisms in LoRa, makes recovering from incidents were static keys become known to unauthorized parties challenging.
We identified multiple problems in the key updating stage. The first problem that we have identified is that static keys are only updateable manually while having direct physical access to the node. This immediately shows the second problem, which is that remote updating of static keys is not possible. In the event of a single node’s secret key becoming known, this problem is solvable if physical access to the node is possible. However, if the static key of multiple nodes becomes known and the nodes are scattered over a large geographical region, solving the problem becomes challenging. In this case, all the static keys of the compromised nodes must be manually updated while having physical access to the node. An engineer must visit all the sites where nodes are installed.
4. LoRa KDUM 4.1. Design requirements
As described in paragraph 2.1 LoRa is a low power wide area network that is aimed to support battery operated wireless nodes. Because of the use of battery powered nodes that must function up to 10 years, it is important that the solution is as energy efficient as possible. Furthermore, battery powered nodes have limited amounts of computational power (Wander et al., 2005) and therefore the solution should comply with low computational effort for applicable applications (e.g. encryption. decryption, key exchange, mic computations) of the solution.
As discussed in paragraph 3.2 there are several reasons why all the secret keys (static as well as session keys) should be updateable. Especially when gaining physical access to nodes is difficult because the nodes are integrated with for instance paving stones that are used in public parking lots, static keys must be updateable remotely. In certain scenarios, it is desirable to update the static keys, because the static key is, in those scenarios, known to more parties than which may have knowledge of the static key. For instance, multiple node vendors ship their nodes with pre-provisioned key material. The vendor has knowledge of the static key and therefore the confidentiality of communications between the node and the application server cannot be guaranteed. Furthermore, the application server holds all secret key material of all the nodes that connect to that application server. If the application server is hacked, an adversary can obtain all the secret keys and there is no feasible way to manually update all the secret keys in the nodes (because nodes can be scattered over a large geographical area and gaining physical access to the nodes can be hard).
The proposed solution must also make the secure key distribution or agreement of the secret keys (static and session) in LoRa possible. Currently LoRa does not have any key distribution or agreement mechanisms implemented, which makes it necessary to distribute the keys manually. As with updating keys, this becomes a problem if nodes are integrated in for instance paving stones because physical access to the nodes is not possible or hard to achieve.
4.2. Key Distribution and Updating Mechanisms
To improve the current implementation of distributing and updating secret keys in LoRa, we propose the Key Distribution and Updating Mechanism (KDUM) which makes updating all (static and session) secret keys in LoRa possible. This makes LoRa resilient against cyber-attacks, because updating the secret keys regularly makes it harder for cryptanalysts to gain knowledge of the used secret key and through that gain unauthorized access to nodes and application servers (preventive measure) and decrypt messages. Also, recovering from a breach of confidentiality of a secret key can be resolved without the necessity to physically visit each site where a node is installed. However, there is a trade-off between security and energy consumption. Every static key update has impact on the lifetime of a node because for every static key update, a key exchange must be performed between the node and the application server (Hirani, 2003), therefore updating the static key should only be performed when necessary (for instance if one has suspects the static key has become known to other parties).
The possibility of updating static keys remotely makes it easier to recover from incidents regarding static keys becoming known to other parties (for instance an adversary or a vendor of the node that installed the initial static key). Also, remote updating capabilities makes it possible to update static keys of nodes for which it is very hard to gain physical access (for instance nodes integrated in paving stones).
KDUM consists of three parts which should be implemented in LoRa. These parts are: the possibility to update all secret keys in LoRa, secret key distribution between the application server and all the nodes in the network and authenticity checking of the public keys being introduced.
4.3. Updating static keys remotely
The possibility to update all secret keys (static and session) in LoRa nodes and application servers to secure the communication between them is needed for resilience and recovery purposes. The nodes and the application server use static keys and session keys for confidentiality, authentication and integrity purposes. As we have seen in paragraph 3.1.2, LoRa is already able to generate session keys for all sessions between the node and the application server using the static key and some additional information. As described in 3.1.6 updating of static keys is currently not possible.
Using the two static keys a shared secret key is computed which is used in the same way as the current pre-shared key. This makes the requirement obsolete that the static key in the node and the application server has to be equal, because a shared secret key is computed for this purpose.
Instead of using separate static keys in the node and the application server and using KDUM for determining a shared secret key, another possible solution is the synchronized updating of the static keys using a random number generator and sharing this number N between the node and the application server. If both the node and the application server use N and static key K as input, this results in the same K’. However, this update mechanism only works if K is not known to an adversary. If K is known, the adversary is always able to generate K’ as well, because the adversary then has both N and K. This is because N is shared over the network. We therefore choose to use KDUM instead of synchronized updating of the static keys.
The administrator has direct access to the application server and is therefore able to update the secret key manually or by key updating in the application server (generate a new key from the old key (Schneier, 1996)). When updating the static key manually, the administrator needs to use a random number generator to generate a secret key that is random. This new secret key must be stored in the application server by manually administrating it.
Besides manual updating, key updating can be used in the application server. With key updating only the application server has knowledge of the new static key. The application server can use the same one way function that it uses for generating session keys, with a different input, for updating the static key. As we have seen in 3.1.4 the application server uses nonces and some additional information to generate session keys. By using a 128-bit nonce, generated by the application server, the application server can update the static key using AES (see Figure 19).
Figure 19: updating static key in the application server
Because nodes are often scattered over remote locations, manual updating of the static key can be challenging (every node must physically be visited to update the static key). Therefore, key updating should be used to update the static key. Through a command send from the application server towards the node, the node is requested to perform KDUM. This command is an addition to the current LoRaWAN specification. The node uses a one way function that updates the static key and perform key distribution steps. Key updating uses the same one way function as is used for key updating in the application server. The node also uses nonces and some additional information to generate session keys. Using a nonce, generated by the node, the node can update the static key using AES (see Figure 20).
Figure 20: updating static key in the node
K’ is a 128-bit secret key generated using the AES algorithm, the 128-bit DevNonce as input and the current static key K. This results in a new random static key that can be used by the node for key agreement between the node and the application server.
Now the first step of KDUM is completed, the node and the application server both have new static keys by which they cannot communicate with each other. Therefore, it is necessary to perform the key distribution stage of KDUM.
4.4. Key distribution
After a static key is updated in a node or application server, it is necessary to create a new shared secret key which is used by the node and the application server for communications. To create a new shared key, a key exchange protocol is used. Diffie-Hellman (DH) key exchange is chosen because LoRa uses a symmetric algorithm (AES) that needs the use of a shared secret key for encryption and decryption purposes. Furthermore, asymmetric algorithms (like RSA) are computational more demanding and therefore consume more energy than symmetric algorithms in combination with DH (Hirani,