A Novel Session Key Update Scheme for LoRaWAN

This paper proposes a novel Long-range Wide Area Network (LoRaWAN) session key updating scheme to enhance the security of LoRaWAN with cost-effective communication that provides a unique key for each communication session. The scheme consists of three sequential stages, i.e., initialization, keying material preparation, and key updating, on the basis of the truncated Photon-256 algorithm with updatable keying materials. These stages are structured by a set of novel communication protocols. To prove the uniqueness of the key, we validated its sequence bit randomness using the NIST 800-22 and ENT statistical test suites. The validation results show that the key passes all test parameters. Subsequently, the communication protocols were validated by using Scyther tools. We proved that these protocols ensure the security of the LoRaWAN key update scheme and guarantee that active interception does not occur. The analysis was performed by focusing on the security features of data confidentiality, integrity protection, mutual authentication, perfect forward secrecy, and replay attack resistance. Finally, a formal security analysis using GNY logic indicated that the overall security goals are achieved. The proposed scheme’s performance was evaluated in terms of computational cost, communication cost, and storage. The computational cost needed by the scheme is very small, indicating that there is no additional burden on the backend system. The communication cost requires less traffic than previous solutions, yet it offers more robust security for LoRaWAN by producing a new key in every communication session. The scheme needs insignificant additional storage that is considered negligible.


I. INTRODUCTION
The Long-range Wide Area Network (LoRaWAN) is a new standard for Low Power Wide Area (LPWA) in the Internet of Things (IoT) that was established through Recommendation ITU-T Y.4480 [1], [2], [3]. LoRaWAN has been widely adopted by the industrial IoT [4], [5], [6] as well as academic research in various fields, such as smart cities [7], [8], [9] The associate editor coordinating the review of this manuscript and approving it for publication was Giovanni Pau . and healthcare [10], [11], [12]. The operation of LoRaWAN guarantees data security by dealing with two parts of cryptographic key management, i.e., the root key [13], [14], [15], [16] and the session key [17], [18], [19], [20]. The root key is the LoRaWAN principal key used to derive all other cryptographic keys [21], and the session key is a derivation key used to secure communication and payload transmission [22].
Our previous work in [16] proposed a novel scheme for root key update management operating on the basis of CTR_AES DRBG 128-bit. This scheme regularly changes the LoRaWAN root key from static to dynamic. As our previous work addressed the first issue of root key management, this paper reports work on the second issue, i.e., session key management.
Several studies have highlighted that LoRaWAN session key management has a problem, i.e., applying the same session key to secure multiple communication sessions [17], [18], [19], [20]. Key repetition leads to data leakage when it is compromised [14], especially since the LoRaWAN session key's function is to secure its communication and data payload. Moreover, NIST recommends that the session key should be applied only once in every communication or should be unique to each session [23].
The schemes for solving this problem that were proposed in [17], [18], [19], and [20] have limitations. These limitations include the high extra communication cost incurred by the entities involved; additionally, these works do not provide a complete security validation test. Details of these limitations are discussed in Section II-B.
We propose a novel LoRaWAN session key updating scheme that provides a unique key for each communication session. The scheme works on the basis of a truncated Photon-256 algorithm with updatable keying materials. We simulate the scheme by focusing on back-end system keying material preparation and the key updating procedure, and we validate the simulation results regarding the bit sequence randomness by employing the NIST 800-22 and ENT statistical test suites. Subsequently, we validate the proposed communication protocol's security utilizing Scyther tools; carry out a series of security analyses, both formal and informal; and examine the performance analysis of the proposed scheme.
The main contribution of this research is the development of a novel LoRaWAN session key updating scheme that uses a specific method and protocols: -A method of updating the session key by applying the truncated Photon-256 algorithm with updatable keying material, which provides a unique session key for each communication session. -A set of protocols that support secure and cost-effective communication. The protocols renew keying material between the end device, join server, network server, and application server.
The remaining sections of the paper are structured as follows: Section II explains the underlying theory of the LoRaWAN session keys and related work. Section III describes the proposed novel secure session key update scheme for LoRaWAN, and Section IV presents the validation results and discussion. The last section, Section V, concludes the research.

II. UNDERLYING THEORY AND RELATED WORKS A. LoRaWAN SESSION KEYS
The LoRaWAN protocol is equipped with the advanced encryption standard (AES) algorithm to protect data integrity and confidentiality during transmission [24]. The AES algorithm has two different keys, i.e., the session key and root key [18], [22], [25]. The root key is a symmetric key applied to secure data transmission between the end device and the join server. The session key is a symmetric key used to preserve the security of the communication protocol and data payload transmitted between the end device, network server, and application server [25], [26].
The LoRaWAN session keys comprise application and network session keys. The application session key guarantees data confidentiality by encrypting the payload exchanged between the end device and the application server. The network session keys ensure communication security between the end device and the network server.
LoRaWAN differentiates its network session keys into three types: the forwarding network session integrity key (FNwkSIntKey), serving network session integrity key (SNwkSIntKey), and network session encryption key (NwkSEncKey). FNwkSIntKey is a network session key that is used to calculate the message integrity code (MIC)value of the uplink data sent by the end device. The function of SNwkSIntKey is to verify theMIC value for all downlink messages and ensure data integrity. NwkSEncKey encrypts the LoRaWAN data payload throughout transmission from the end device to the server and vice versa [22], [27]. An illustration of the LoRaWAN session keys is shown in Fig. 1. LoRaWAN derives the session keys from its root key through a key derivation function (KDF) [22], [28], [29], [30], [31]. The end device and join server run the KDF with the AES_ECB algorithm and input the root key as the KDF cryptographic key parameter [22]. Although the LoRaWAN session keys are dynamic, the value rarely changes. By default, the session key of LoRaWAN only changes in the rejoin procedure when the end device loses its communication session with the server [22], [28], [29], [30], [31]. Thus, assuming that LoRaWAN maintains its communication session for a long time, an identical session key is used during this time. LoRaWAN applies the same key to secure the communication session and encrypt the payload during a specific period. In this case, the LoRaWAN session key becomes insecure, and it exceeds the crypto period standard [23], [32]. This condition also leads to data leakage and does not comply with the security standards recommended by NIST [23], [32]. The NIST recommendation specifies that the session key must be different in each communication session [23]. Therefore, some studies have attempted to resolve this issue by proposing session key update schemes [17], [18], [19], [20].

B. RELATED WORK
Researchers have conducted studies to address the LoRaWAN key management issue [17], [33]. To improve security key management, researchers have proposed a method of updating the key, as the fundamental problem of LoRaWAN's key management is that the key has a constant value for a long time. Since LoRaWAN has a root key and session key, some studies have focused on updating the root key [13], [14], [15], [16], while others have focused on the session key [17], [18], [19], [20]. The goal of the proposed solution is to improve LoRaWAN security.
Chen et al. [17] examined the entire LoRaWAN key management process. They proposed a session key update algorithm using the modified Rabbit PRNG algorithm. However, they did not provide standard validation to test the randomness of the new session key. The proposed method did not include a communication protocol to support the key updating scheme.
The research conducted by Tsai et al. [18] proposed SeLPC, a scheme for updating session keys with power optimization in the AES algorithm. SeLPC's power consumption optimization was carried out by reducing the rounds of the AES algorithm. To maintain the cryptographic keys' security level, they used a Dynamic Box instead of an S-Box, which was updated every k days. The session key was updated every k days by the network server. Every k days, devices that were clustered as one group received the new session key. This work solved this LoRaWAN problem and saved power consumption. However, this work did not provide randomness validation for the bit sequences. Since the proposed solution reduces the half-cycle and changes the S-Box of the AES algorithm, a randomness test of the output is necessary to confirm that the bit sequence output resulting from the modification satisfies the cryptographic key security requirement.
Xia et al. [19] proposed a session key update scheme to tighten the security of meter-reading systems based on LoRaWAN. It added a trusted key distribution server (KDS) that functions as a key management center. The center manages the session time and updates the session key for each smart meter-reading LoRaWAN node. The KDS controls the key with a particular expiration period. Thus, each time the session key expires during its lifecycle, the KDS communicates to the end device and the network server to update the session key. This solution dynamically provides a new session key with an unpredictable schedule. The session key is frequently updated over a certain period, but the value remains the same until it expires. In a condition in which the new session key is renewed for each data transmission, this scheme increases the communication traffic.
Research to improve the security of LoRaWAN cryptographic keys was also performed by Tsai et al. in [20].
The study proposed the low-power AES data encryption architecture (LPADA) as a session key update scheme to improve LoRaWAN's security key management with minimum power consumption. LPADA employs ultralow-power content addressable memory to design the Sbox AES algorithm for LoRaWAN. Thus, the AES algorithm is more energy efficient in updating the session key. However, the analysis of this study focuses more on energy consumption, neglecting the randomness and communication protocol tests.
Other research on session key update was conducted by Tsai et al. in [34]. This research mainly focused on generating and updating the session keys used among LoRaWAN servers. The update was not applied to the session key used for securing session communication and encrypting the payload. The proposed elliptic curve algorithm employs a 163-bit key length, yet the applied key size is less than the recommended cryptographic key length for the elliptic curve [35]. The relevant NIST recommendation states that during 2019-2030, the minimum cryptographic key size for the elliptic curve algorithm is 224 bits [23].
These previous works solved the LoRaWAN session key problem, yet they have limitations. Thus, our study proposes a solution and addresses their weaknesses. We propose a secure session key update scheme based on the Photon-256 algorithm. This research improves the methods of Chen et al. [38] by adding communication protocols to support the scheme.
Unlike Tsai et al. in [18], the new session key result of the update scheme is validated by two standardized NIST 800-22 Rev. 1a [36], [37] and ENT statistical test suites [38], [39]. This validation is an essential factor in proving the randomness value of the new session key. The new session key bit sequences that pass this validation satisfy the cryptographic key security requirement [23].
Furthermore, the research of Xia et al. [19] solved the LoRaWAN problem but demanded heavy traffic communications. We address this issue of intense communication by proposing a different solution that reduces the traffic. Instead of generating and delivering the new session key value directly, we have the server provide component of the keying material.
Regarding the protocol, this paper examines informal and formal security analysis to address the limitation that previous studies [19], [20] only examined informal analysis. We provide validation of the proposed communication protocols using Scyther tools, as was done by Tsai et al. in [34]. This validation proves the security of the protocol's design and ensures that an active attacker is unable to intercept communication so that the key's secrecy is guaranteed during transmission.

III. PROPOSED SESSION KEY UPDATE SCHEME FOR LORAWAN
Based on the LoRaWAN architecture, our proposed session key update scheme involves four entities: the end device (ED), join server (JS), network server (NS), and application server (AS). We exclude the radio gateway because the scheme does not add particular tasks to the gateway. To simplify the explanation, we summarize the abbreviations of the involved entities in Table 1.

A. GENERAL ARCHITECTURE
In our proposed scheme, the session key update algorithm is executed individually on three different entities, i.e., the ED, NS, and AS. The ED updates all required session keys, while the AS updates only the application session key. We set the NS involved in this scheme as the home Network Server (hNS). Therefore, the session key related to the serving Network Server (sNS) and forwarding Network Server (fNS) is updated by the home Network Server; later in this paper, we call it simply the NS.
We set the JS serves as a key generation center that is supported by a random bit generator (RBG) module [40] that provides and shares keying materials and attributes. The session keying material generated by the RBG module is a 128-bit pseudorandom bit sequence. The 128-bit pseudorandom bit sequence is then divided into two parts. The 64 most significant bits (MSBs) are assigned as the value of the master password for the network session key. Then, the remaining 64 least significant bits (LSBs) are assigned as the value of the master password for the application session key. Other entities (the ED, NS, and AS) then use the master password value as keying material's component.
The general architecture design of the proposed session key update scheme is displayed in Fig. 2. According to the design, pairs of entities exchange communication protocols to request and deliver session keying material components. There are three protocols exchanged between the pair ED-JS, and an end-to-end symmetric encryption algorithm protects these protocols. Then, three protocols are exchanged between the JS-NS and JS-AS pairs. The asymmetric encryption algorithm protects these protocols.

1) COMMUNICATION PROTOCOL EXCHANGED BETWEEN THE ED AND JS
In our scheme, the communication protocol sent by the ED to the JS is defined as a New_Rejoin-request. To secure its communication, the New_Rejoin request is protected by the MIC, where the MIC calculation utilizes the AES-CMAC 128-bit algorithm with an updatable LoRaWAN root key [16]. The New_Rejoin request initializes the session key update process to request keying materials and other attributes. We design the ED to send New_Rejoin-request communications on a periodic basis, such as once a week or every n days as scheduled [16]. To respond to such a request, the JS replies by sending a New_Rejoin-response that contains keying material components and attributes needed by the ED to process the session key update. The New_Rejoin-response is encrypted by AES-ECB 128-bit and is also equipped with a MIC. In the last step, to confirm and acknowledge the received keying materials, the ED sends New_Rejoin-ack. These communication protocol exchanges trigger the JS to communicate with the NS and AS concurrently.

2) COMMUNICATION PROTOCOLS EXCHANGED BETWEEN THE JS AND NS AND THE JS AND AS
We distinguish the communication protocol terms that are used between the JS-NS and JS-AS pairs, although we assume the communications occur concurrently. The communication protocols used among servers, the JS, NS and AS, are encrypted using the elliptic curve cryptography (ECC) algorithm [34], [41], [42], [43]. In the scheme, we assume that the JS-NS and JS-AS pairs have exchanged their public keys, which can be used directly in the session key update scheme.
The JS sends the JN-SKeyMat protocol to the NS containing the network session keying material and attributes needed by the NS. The NS sends a confirmation to the JS by sending JN-accept. Then, the JS responds by sending back NonceNS over the JN-response, ensuring that the NS has received the network session keying materials.
At the same time, the JS sends JA-SKeyMat to the AS, which contains the attributes and application session keying material needed by the AS. The AS then replies to the JS with JA-accept. Last, the JS sends JA-response to ensure that the AS has received the information used for updating the key.

3) THE ECC ALGORITHM SETUP TO SECURE COMMUNICATION BETWEEN JS-NS AND JS-AS PAIRS
The ECC algorithm used for securing communication between JS-NS and JS-AS pairs is defined as follows: In this research, the ECC algorithm utilizes Elliptic Curve25519 with a 256-bit key length [41], [42], [43]. We select Elliptic VOLUME 10, 2022 Curve25519 because of its security performance and efficiency. The prime fields minimize ECC security problems, and the calculation of the EC points is fast [42]. Meanwhile, a 256-bit key length is chosen to comply with the minimum security key size for prolonged use beyond 2030 [35], [43]. The protocol messages are converted into points on an elliptic curve. The initial setup for ECC is as follows: -Select a base point G in Curve25519 at random, the order of which is a large positive integer n.

b: KEY GENERATION
-Each user chooses a private key n user < n and generates a public key P user = n user × G.
The user chooses a random positive integer k and calculates a pair of points as the ciphertext C m , as follows: In this paper, the recipients are the JS, NS, and AS. In addition, a digital signature used in the scheme is Curve25519 with a private key to encrypt the digest value.

4) SESSION KEY UPDATE ALGORITHM
In the proposed scheme, we utilize the Photon-256 algorithm with 128 truncated outputs as the session key update algorithm. Photon-256 produces a hash code output that has a 224-bit length. The result is then truncated to 128 bits to adjust to the required length of the session key. We select the Photon algorithm because it is a lightweight algorithm suitable for an IoT end device [44], [45]. Since the computation of session key updates involves a LoRaWAN end device, a lightweight algorithm is necessary [44], [46]. In addition to being lightweight, the Photon algorithm has been standardized by the International Standard ISO/IEC 29192-5 [47]. Additionally, the truncated Photon-256 algorithm was chosen because it complies with the ISO/IEC 29192-1 security standard for lightweight cryptography [47], and the NIST recommendations, in which the hash value length for 2019-2030 is 224 bits [35], [43].
In our scheme, the session key is updated regularly based on a single communication session. The ED sends the payload in every scheduled period using a different session key.
To reduce the transmission costs incurred by the ED and the communication traffic among the entities, the ED only requests keying material once a week or as defined according to needs, every n days.

B. SESSION KEY UPDATE SCHEME
We describe three sequential stages to carry out the session key update scheme, as shown in Fig. 2. The first stage, INIT_Stage, is defined as an initialization process to request keying material for new sessions, which occurs in the ED. The second stage, Skey_MatPrep, is defined as a session's keying material preparation stage, which is processed on the JS. Skey_MatPrep has two substages: Skey_MatPrep stage_1 and Skey_MatPrep stage_2. The third stage is the session key update procedure, comprising NSKey_Update and ASKey_Update. NSKey_Update is executed on the ED and NS, while ASKey_Update is executed on the ED and AS. The terms, notation, and definitions used in this proposed scheme are defined in Table 2.
All three stages are interrelated, but each has a different role. Fig. 3 illustrates the functional diagram of the proposed  scheme. The figure shows that the stage starts with the ED, which sends a message to request session keying materials. Then, the JS prepares the keying material by generating and delivering it to the ED, NS, and AS. When the ED, NS, and AS execute the session key update process, the stage ends.
Next, the three stages with their respective steps are explained.

1) INIT_STAGE
The initialization stage occurs in the ED, which has been configured to update the session keys periodically. In this study, Ts must be within the predefined session key update timeframe of the associated ED. When the received New_Rejoin-request does not pass verification, the JS halts the step and sends a notification so that the associated ED repeats the process within a specific boundary time. 2. Immediately after completing the verification, the JS prepares the session keying materials to be sent to the associated ED. Two types of session keying materials are prepared, i.e., the network session keying material and application session keying material. In addition to the keying materials, the JS prepares attributes that are used for the default component of the New_Rejoin-response, for example, devaddr, DLSettings, RxDelay, and CFList. Furthermore, we define the session keying material components that are used in the proposed scheme with the following sequences: The first component of the session keying material comprises master passwords, MPNet and MPApp, which are each 8 bytes long. Both are pseudorandom bit sequences generated by the RBG module in the JS [40]. the second component of the session keying material is a 1-byte hex number code used to differentiate several session key updates defined based on the LoRaWAN specifications, 0 × 01 − 0 × 04. We assume that the involved entities have stored the code. The third component of the material is a timestamp. The entities that execute the session key update retrieve 4 bytes of their respective devices' timestamps, Te, at the scheduled time. The fourth component of the keying material is the server identities, which are directly involved in the key update execution process, namely, the NS and AS identities. In the proposed scheme, we define the AS identity as AppID with the same size as NetID, 3 bytes. The last component of the keying material is the identity of the associated ED, DevEUI , which is 8 bytes long. Thus, the total material size of each session key type is 24 bytes in the following order: MPApp||Code_0 × 02||Te| |AppID| |DevEUI The combination of the keying materials and attributes is described as a Rejoin-response-message.
Then, the JS encrypts the Rejoin-response-message and MIC JE by employing the AES_ECB 128-bit decryption algorithm, aes128decrypt [22], with the updatable JSEncKey value [16]. Furthermore, the JS concatenates the encrypted keying material with the JS message header.
-  performed by encrypting the received JoinNonce using AES_ECB 128-bit with the newest JSEncKey and then concatenating the result with the ED header MHDR ED . Last, the ED sends the message as New_Rejoin-ack to the JS. New_Rejoin-ack is an acknowledgment message used by the JS as a reference to continue the next substage. The communication protocols exchanged between the ED and JS to request new keying material and deliver the request are illustrated in Fig. 4. 5. The JS directly processes SKey_MatPrep stage_2 after receiving New_Rejoint-ack. The JS decrypts and verifies the message to ensure the ED has received the new session keying material. In SKey_MatPrep stage_2, the JS retrieves the session keying material prepared for the related NS and AS and then sets up the security requirements for sending the keying material to the NS and AS separately. The security requirements used for delivering the network session keying materials to the NS are as follows: The JS calculates the digital signature with the JS private key.
-Sign_NSKeyMat = ECC256sign(K JS , Hash (MPNet | |DevEUI )) The JS combines all the prepared data, including the digest, as NSKey-message and encrypts NSKey-message using the NS public key to produce JN-SKeyMat.
- If the nonce values are equal, then the NS updates the network session key on a regular basis concurrently with other entities, the ED and AS. The communication protocols exchanged between the JS and NS to deliver the network session keying material are illustrated in Fig. 5. 11. The procedure used for transferring application session keying materials from the JS to the AS is similar to the procedure used in JS-NS communication. It starts with steps 5 to 10. However, since the contexts used to update the application session key and network session keys are different, we distinguish the parameters. The distinct parameters are the keying material and its attributes, public-private key usage, nonce value, label, and protocol communication term used to exchange the messages.

IV. RESULTS AND DISCUSSION
This section has four subsections that present the simulation, validation results, and discussion of the proposed scheme. We use the same testing framework as in our previous work [16]. We simulate one of the session key updates and validate the result of the randomness of the new session keys. We provide informal and formal security analyses of the scheme, validate the communication protocol security, and discuss the performance of the proposed scheme. All validations are conducted on the Ubuntu 18.04.5 LTS operating system, which is installed on a virtual box with an 11th Gen Intel(R) Core (TM) i7-11370H processor @ 3.30 GHz, and an 8 GB RAM is used to run the virtualization.

A. VALIDATION OF THE RANDOMNESS OF THE NEW SESSION KEY BIT SEQUENCE
We conduct simulations to validate the randomness of the bit sequences of the new LoRaWAN session keys. The simulations consist of keying material preparation, session key update execution, and randomness validation. Since LoRaWAN has several types of session keys, we select one of the keys as a representative to simulate, i.e., an FNwkSIntKey.
The FNwkSIntKey requires NSKeyMat's keying material as an input parameter to execute its key update algorithm. Thus, we define NSKeyMat's keying material as shown in Table 3 and generate it using a bash script program. The program generates a unique value of NSKeyMat in every iteration. According to Table 3's definitions, the program regenerates MPNet in a certain period, while the timestamp varies every nanosecond.
We execute a bash script program for the Photon-256 algorithm to simulate the FNwkSIntKey update. The direct output of the Photon-256 simulation is a set of sequences of keys that each have a 224-bit length. Thus, each key sequence is truncated to 128 bits to adjust the LoRaWAN session key length. We define the outcome of the key sequence simulation as a new FNwkSIntKey. The conducted simulation uses 22,650,714 iterations to produce the new FNwkSIntKey, which satisfies the minimum number of bit sequences required for the randomness test, 1000 sequences x 1,000,000 bits [36].
Furthermore, we validate the bit sequence randomness of the new FNwkSIntKey using two standardized statistical test suites, ENT [37], [38], [39] and NIST 800-22 [36], [37]. Table 4 presents the results of the ENT test suite for the entire bit sequence of the new FNwkSIntKey.   the new FNwkSIntKey with the value α = 0.01. We use the Fast_NIST_STS_v6.0.1 tools [48], [49] to conduct the statistical test since this method is fast [50].
The validation results prove that the new FNwkSIntKey passes all five parameters determined by the ENT statistical test suite and all 15 parameters specified by NIST 800-22. These results indicate that the new session key value has a randomness level that meets the ENT and NIST standard requirements.

1) DATA CONFIDENTIALITY
The proposed scheme guarantees the confidentiality of session keying material during transmission, but confidentiality during storage on the device is beyond the scope of this research. Another study proposed a hardware security module (HSM) or secure element (SE) scenario to retain the key [51], and this can also be used for the keying material on the device.
The scheme maintains the confidentiality of the keying material data and attributes by implementing two encryption algorithms. The scheme implements an end-to-end symmetric algorithm, i.e., AES-ECB 128-bit, to encrypt data transmission from the JS to the ED. Later, the scheme also implements the ECC256 encryption algorithm to protect data transmission between servers in JS-NS and JS-AS communications. This is proven by protocol validation utilizing the Scyther tools, as displayed in Fig. 6. The validation results show that the protocol meets the secret test property.

2) INTEGRITY PROTECTION
The integrity protection of the communication protocol in the scheme is achieved by applying the MIC and digital signature. The application of the MIC and digital signature is embedded in the message with the aim of maintaining the integrity of the keying material distributed by the join server. In the scheme, the join server adds the MIC to the message sent to the end device and adds a digital signature to messages sent to other servers, networks and application servers. At a predetermined time, when the join server receives a request to update the keying material, the join server first verifies the MIC EJ of the request message. Then, the join server prepares new keying material only when the MIC verification is successful. The join server prepares the response message (New_Rejoin-response) containing the new keying material with MIC JE and then encrypts and sends the message to the end device. Meanwhile, the end device, as a receiver entity, must verify the MIC JE before utilizing the new keying material.
Additionally, the join server prepares the NSKey-message and ASKey-message; these messages contain the new keying material embedded with the join server's digital signature. Before sending the messages to the respective servers, the join server encrypts them using each destination server's public key. Thus, only the network and application servers possessing public-private key pairs can verify the signature.
The validation protocol described in Section IV-D proves the statement above. The results of the validation protocol in Fig. 6(a) and (b) show that the protocol has the noninjective synchronization (Nisynch) properties. These properties indicate that the message received by the communicating entity VOLUME 10, 2022 is precisely the same as the message sent, in both order and content.

3) MUTUAL AUTHENTICATION
The scheme supports mutual authentication among entities to avoid fake join servers and ensure that the intended recipient receives the keying material. The join server authenticates the end device using two properties: the timestamp and MIC EJ , which are embedded through a New_Rejoin-request message sent by the end device. The join server verifies the received timestamp and ensures that the Ts verification meets the predefined timeframe of the associated ED. Next, the join server verifies the received MIC EJ using a formula that requires an end-to-end symmetric key: JSIntKey. The join server trusts the end device only when the request message passes verification.
Meanwhile, the end device authenticates the join server using the MIC JE properties embedded in the New_Rejoin-response message. The join server responds to the end device's request by sending the New_Rejoin-response message. The end device verifies the MIC JE in the received message to authenticate the join server. Then, to inform the join server when the corresponding end device has completed mutual authentication, the end device sends a New_Rejoin-ack message. Immediate exchanged messages between the join server and end device indicate that both sides have successfully authenticated mutually.
Furthermore, the scheme utilizes a digital signature and nonce to support mutual authentication among servers. The network and application servers authenticate the join server using a digital signature. The join server's digital signature embedded in JN -SKeyMat and JA-SKeyMat is sent to the network and application servers separately. The network and application servers ensure that the join server is a legitimate entity by verifying the received join server's digital signature: Hash_NSKeyMat and Hash_ASKeyMat.
In contrast, the join server authenticates the network and application servers using a nonce value. The join server only receives the replay of the JN -SKeyMat and JA-SKeyMat messages when the network and application servers successfully authenticate the join server. In their replay messages, JN -accept and JA-accept, the network and application servers send back the received NonceJS followed by their freshly generated values: NonceNS and NonceAS. Mutual authentication is achieved when the join server successfully verifies the received nonce value. The join server sends NonceNS and NonceAS back to each associated server to inform them that the join server has ensured the legitimacy of the network and application servers and confirms that the entities satisfy mutual authentication.

4) PERFECT FORWARD SECRECY
The scheme has a perfect forward secrecy feature for the session key that is achieved through the unpredictable value of its keying material. The keying material has values that are difficult to predict. The keying material consists of five components: two of the five components are a master password that changes periodically and a timestamp that varies every nanosecond. These two dynamic components mean that the keying material is always different in every updating process. The different value applied in each iteration of the truncated Photon-256 algorithm impacts the production of the unique new session keys. The simulation results explained in Section IV-A proved this statement. The perfect forward secrecy of the keying material leads to perfect forward secrecy for the new session key.
An attacker who intends to duplicate the keying material from the end device side should know all the keying material components, including the associated server identity, the timestamp, and the master password. An attacker might know the associated network and application server identities. However, obtaining the other two dynamic keying material components is difficult within the available timeframe. An attacker should know the exact value of the timestamp, which is used only once in every updating scheme. To duplicate the keying material, an attacker must obtain the exact timestamp value. This takes effort because the scheme utilizes a timestamp for up to a nanosecond, which is equivalent to a 32-bit timestamp generated by the end device. Additionally, at the particular time at which an attacker obtains the precise schedule for generating the timestamp and obtains the master password, the gathered data are valid only temporarily. The scheme guarantees perfect forward secrecy since the master password changes regularly in a certain period with an unpredictable value. An attacker who knows the current master password does not know the master password at the previous and later periods. The join server, as the entity that is responsible for updating the master password value, changes its value regularly in every period. In addition, in this scheme, the join server is designed with an RBG module to generate a master password that meets the criteria.

5) REPLAY ATTACK RESISTANCE
The scheme employs timestamps and nonces to resist replay attacks. The end device embeds a timestamp in the request message it sends to the join server. An attacker who attempts to duplicate and then relay the message to the server needs additional time. This condition is unacceptable since the join server checks the Ts of the received message. If Ts does not match, the related join server drops the message and sends a notification stating that it has detected a replay attack. If an attacker manages to modify the timestamp to comply with the Ts requirement, the scheme resists the replay attack by inspecting the MIC EJ calculation. Since the forwarded message has a different timestamp, there will be a MIC EJ mismatch because the scheme sets the timestamp as part of the MIC EJ formula.
In communication between servers, protection against replay attacks is ensured by utilizing the 128-bit nonce value. Before sending out the JN -SKeyMat or JA-SKeyMat message, the join server encrypts the message along with its digital signature by using each destination server's public key. Subsequently, because the fake join server does not have a destination server private key, it cannot decrypt and modify NonceJS. Thus, this replay attack is difficult to achieve because the effort required by the fake join server to obtain the NonceJS value is equivalent to the effort needed to obtain the asymmetric key pair of the ECC256 algorithm. In a condition in which the fake join server relays JN -SKeyMat or JA-SKeyMat messages to the network and application server, the respective server detects this attack since the relayed message has the same NonceJS as the one received in the previous message.

C. FORMAL SECURITY ANALYSIS
We perform a formal security analysis of the proposed communication protocols by leveraging Gong, Needham and Yahalom (GNY) logic [52], [53], [54]. The process of formal security analysis is divided into six steps, starting with determining the logical postulates used and ending with proving the protocol's security. To analyze the protocol, GNY provides logical notation, and the GNY logical notation used in this paper is shown in Table 6.
The analysis performed in this section concerns the security of the protocols transmitted between end devices and the join server (ED-JS) and between the join server and the network server (JS-NS). The protocols exchanged between join servers and application servers (JS-AS) have similar steps, with different components being exchanged between the JS and NS. Thus, the formal analysis of JS-AS communication refers to that of JS-NS communication. The details of the steps for proving the security of the session key updating scheme protocol with GNY logic are given below.

1) LOGICAL POSTULATES
The GNY logical postulates employed in this study consist of five types of rules: message interpretation rules I 1 and I 2, being-told rules T 1 and T 4, possession rules P1 and P2, recognizability rules R6, and freshness rules F1. All the rules are presented below.

2) PROTOCOL DESCRIPTION
In GNY logic, the protocol description concerns the formalized messages sent and received between entities. In this paper, we interpret the formalized messages of the protocols delivered in ED-JS and JS-NS communication. The following are formalized versions of the protocols exchanged between the ED and JS: RJCount1, Ts, MIC EJ where:

3) IDEALIZED MODEL
An idealized model (IM ) is used to idealize the formal protocol description given in the previous step. In the ideal form, the response components and all message headers are removed from the protocol. Thus, the idealized model form of the protocol in ED-JS and JS-NS communication based on the GNY logical formulas is as follows:

4) INITIAL ASSUMPTIONS
The initial assumption (IA) expresses the initial data possessed and the belief regarding the data for each entity involved. The initial assumptions stated here are only some of the assumptions applied to prove the defined security goal. Therefore, the initial assumptions stated are only the assumptions of the ED and NS, and the initial assumptions of the JS are omitted because they are not directly applied as a reference in proving the security goals. The initial assumptions used in this analysis are as follows:

5) SECURITY GOALS
In this analysis, we divide the security goals (SG) into two parts, SG1 and SG2, to simplify each pair of communication protocol goals. However, generally, the security goal of the proposed protocol is to guarantee that the fresh session's keying material is delivered by trusted entities. The following are the goal sets for the protocol: • SG1 : ED| ≡ JS| ∼ JoinNonce, NetID, MPNet, MPApp, AppID, Ts , MIC JE • SG2 : NS| ≡ JS| ∼ JoinEUI , NetID, MPNet, DevEUI , NonceJS, Sign_NSKeyMat The first security goal means that the ED believes that the JS has sent JoinNonce, NetID, MPNet, MPApp, AppID, Ts , and MIC JE . This message indicates that the JS has successfully verified the end device's request to update the new keying material and replied to it with fresh keying material. The second security goal means that the associated NS believes that the JS has updated its network session keying material by sending freshly generated JoinEUI , NetID, MPNet, DevEUI , NonceJS, Sign_NSKeyMat.

6) SECURITY PROOF
There are two different interpretation postulates applied to prove the security of the protocol as described in step 5. To prove the first goal (SG1), that the protocols manage to deliver the new sessions' keying material to the end devices, postulate I 1 is used. In the use of postulate I 1, there are specific conditions (C) that must be met, as explained below. MPApp, AppID, Ts , MIC JE Next, by applying postulate R6 to D2, we achieve C4. The last condition, C5, is achieved by applying postulate F1 to initial assumption IA3.
The security of the protocol between the end device and the join server is proved by fulfilling all the conditions from C1 to C5. Therefore, by implementing postulate I 1 for all five conditions, we obtain the GNY logic formula ED| ≡ JS| ∼ JoinNonce, NetID, MPNet, MPApp, AppID, Ts , MIC JE . This formula means that the end device believes that the join server has sent a new value of the session keying material. With this proof, it is concluded that the protocol transmitted between the ED and JS meets the logical security requirements according to the objectives set out in the SG1 formula.
To prove the second security goal, SG2, I 2 is used. The particular conditions required to apply postulate I 2 are described as follows: NonceJS, Sign_NSKeyMat Furthermore, C11 is obtained by utilizing postulate F1 on precondition D6. Last, the proof of the security of the JS-NS protocol is achieved by applying postulate I 2 to conditions C6 to C11. Applying I 2 to all conditions results in one formula, namely, NS| ≡ JS| ∼ JoinEUI , NetID, MPNet, DevEUI , NonceJS, Sign_NSKeyMat. This formula means that the network server believes that the join server has sent freshly generated network session keying material as defined in SG2. Based on the above evidence, it is concluded that the protocol transmitted between the join server and the network server meets the logical security requirements.

D. SECURITY VALIDATION OF THE COMMUNICATION PROTOCOLS
We validate the security of the proposed communication protocols using Scyther tools [55], [56], [57]. As explained at the beginning of Section IV, the protocols are validated in an Ubuntu-based environment. We model all protocols transmitted between entities in the form of an * .spdl program run on Scyther tools, and Fig. 6 displays the validation results. Fig. 6(a) is the Scyther validation result for the three steps of the protocols exchanged by the ED and JS, and Fig. 6(b) is the result of the communication protocol steps transmitted by the JS and NS in this scheme.
Based on the Scyther verification results in Fig. 6, the protocols in our scheme meet the secrecy property, indicating that the communication protocols between the ED and JS and the JS and NS are secure. Communication secrecy implies that the protocols guarantee the confidentiality of the keying material distribution.
Scyther proves that the protocols have aliveness properties. The aliveness shown in Fig. 6(a) is achieved because the ED includes the timestamp when sending a request message, and the JS only replies to a request when the Ts has been successfully verified. Additionally, as shown in Fig. 6(b), JS-NS communication meets the aliveness requirement by exchanging nonce values.
Furthermore, the Scyther results in Fig. 6 (a) and (b) show that the protocols have the noninjective synchronization (Nisynch) property. Nisynch indicates that the messages received by the ED-JS and JS-NS pairs exactly match the messages sent, both in order and in content. This implies that the protocols protect the message integrity.
The noninjective agreement (Niagree) property is also realized in this protocol verification method, which means that both the sender and receiver entities believe that they agree to exchange information.
Finally, the Scyther tools characterize our proposed protocols, and the results show that they have precisely one trace pattern. This pattern characteristic proves that when an entity sends a message, the receiver receives the message directly. This condition means that the two-way communication protocols are secure from active interception.

E. PERFORMANCE ANALYSIS
In the last part of this section, we analyze the proposed scheme's performance in terms of computational cost, communication cost, and storage [54].

1) COMPUTATIONAL COST
In this paper, computational cost (Tc) considers the time used to run a session key update process. This process consists of two sub-processes: retrieve timestamp and execute the algorithm. Thus, to get the computational cost, we calculate the time used to retrieve a new timestamp (Te) and process the key update (Tu).
The calculation of computational cost is done on the server side. We experiment to retrieve 32-bit timestamps and calculate the time it needed. The experiment of timestamp retrieval is conducted with a bash script program with 100,000 iterations. The experiment shows that the average time needed is 2.45 milliseconds. We use this average time as reference data in evaluating the computational cost of timestamp retrieval. Then, to get the Tu data, we count the time required for updating a session key by running one iteration of the Photon-256 algorithm. The test shows that the time needed to execute the session key update algorithm is 0.001 seconds (1 millisecond). Therefore, to calculate the computational cost, we sum up those two experiments' time data. The total time of session key update (Tc) is the sum of the time needed to retrieve a new timestamp (Te) and to execute the updating algorithm (Tu), Tc = Te+Tu. According to the experiment, the computational cost requires 3.45 milliseconds, which is a very short time that is required to perform such processing; hence, the computational cost is considered to add no burden to the backend system side.

2) COMMUNICATION COST
In this study, the communication cost refers to the protocol steps sent and received by a pair of entities. These communication costs represent the amount of data traffic transmitted between parties. It should be noted that in wireless data transmission, the heavier the traffic is, the greater the potential for data collision. In the event of a collision, the party needs to process data retransmission. Consequently, if retransmission occurs on the end device, this communication cost incurs burdens for the end device. Therefore, in this section, we analyze the communication cost between the end device and server.
Previous studies assigned the server to update the session key value; Xia et al. assigned the KDS [19], and Tsai et al. assigned the network server [18], [20]. Thus, when every communication session implements a different key, the previous solutions lead to heavy communication traffic between the assigned server and end device entities because the server has to distribute new key values. This situation does not occur in our scheme because the server sends the keying material component, which is part of the input parameter in updating the session key, instead of directly sending the new key value. In our proposed scheme, traffic is minimized because the keying material component transmission occurs only at a particular periodic time. In situations where a session key is created for each data transmission, our solution incurs less communication cost for the end device than the existing solutions.
Furthermore, assuming that every protocol step costs time T , each pair of an end device and join server needs 3T to update the keying material values. This 3T cost equals the cost required to update the session keys in previous works [19], [18], and [20] between their end devices and assigned servers. Assuming that the end device always uses a new session key to send the data each day, in a week, it needs seven new session keys. When our scheme is set up to update the keying material once a week, the communication cost incurred is 3T. If this scenario is applied to the methods of the previous studies, then the communication cost for each of their solutions is 21T. Thus, our scheme communication cost requires less traffic than the previous solutions, yet it offers more robust security for LoRaWAN by producing a new key in every communication session. A comparison of the communication costs among the solutions for the above scenario is displayed in Table 7.

3) STORAGE
Additional storage is a concern for end devices since they tend to have a small memory capacity. Thus, we calculate the extra keying material components and ignore the default components owned by the end device. The total amount of extra storage required by the scheme is only 19 bytes, specifically, 8 bytes for MPNet, 8 bytes for MPApp, and 3 bytes for AppID. Subsequently, to optimize memory management, the end device automatically deletes the previous keying material components once it confirms that it has received legitimate new keying material components. Then, compared to all storage on the end device [58], the additional storage for the keying material components is considered negligible. Thus, there is an insignificant additional storage impact of this solution to significantly enhance LoRaWAN security with a more secure communication session.
A summary of our proposed scheme and comparison to previous studies are displayed in Table 8.

V. CONCLUSION
This study proposed a novel session key update scheme to enhance LoRaWAN security by providing different keys in every communication session. The scheme consists of three stages, and these stages use a truncated Photon-256 algorithm as well as a set of secure and cost-effective communication protocols. The bit sequences of the keys produced by the algorithm pass the NIST 800-22 and ENT statistical test suites. Additionally, the communication protocols ensure the confidentiality and integrity of the data, mutual authentication, and perfect forward secrecy, and they resist replay attacks. The security of the protocols is formally verified by GNY logic and validated by the Scyther tools. The performance analysis shows that the scheme is more cost effective than those of previous studies. A limitation of this study is that the proposed scheme was not fully implemented in the LoRaWAN architecture. Consequently, future research will investigate this limitation.