# A Complete Key Management Scheme for LoRaWAN v1.1 +
## 7 Analysis of Solutions  
The section provides a discussion about our proposed solutions and how our contributions are made to the field. To address the LoRaWAN v1.1 security issues listed in Section 4.5. The paper has proposed a new complete Centralized key management (CKM) scheme that included four sub-schemes. First, the paper provides a Key Generation Scheme (KGS) that used a proposed new key generation algorithm, called Modified Rabbit v2 (Version 2) to generate the session keys. Our proposed key generation algorithm is much more efficient, 34.6% faster compared to the key generation algorithm AES_ECB 128 introduced in the LoRaWAN v1.1. It is 23.5% faster than the Rabbit PRNG. Also, the speed efficiency is about 14.8% faster than the key generation algorithm in the paper [6]. The experimental details about the Modified Rabbit v2 can be found in Section 6. From the theoretical point of view, our proposed algorithm is faster than the AES_ECB 128 is because that we do not use the computational heavy operation like the lookup table [32; 40] (Substitution box, named as the S-box) in the AES. Compared to the Rabbit [32] and our earlier publication [6], our proposed algorithm used two Rabbit ciphers (Each with 1 system iteration) and two Exclusive OR (XOR) operations. Although we used two Rabbit ciphers, compared to the Rabbit (4 system iterations), and the algorithm in [6] (2 system iterations), we used less system iteration (only 1 system iteration). By using the layout in Figure 5, our proposed algorithm is much efficient compared to others, but also the randomness and uniqueness of the secret keys are ensured, details can be seen in Section 6. Hence, our KGS used such proposed key generation algorithm allows a more frequent key update to increase the difficulty of cracking the session key. Unlike the static root key updating scheme proposed by [8], we allow more frequent session key  
Figure 7: Frequency Test Within A Block: Modified Rabbit v2 vs Modified Rabbit v1 vs Rabbit vs AES ECB. updates that make it the attacker much harder to crack the session key or even reverse-engineering the root key. At first, the attacker has more difficulty getting the current session key due to the high frequent key changes. Secondly, that makes it much harder for the attacker to reverse back the root key from the session key for the same reason. So, the need for updating the static root keys are reduced. Also, unlike [7; 9; 10], they used Public Key Cryptography (PKC) for the key exchanges, according to [41; 42] the PKC requires more computation resources than symmetrical cryptography, and our session key generation uses the symmetrical method that can be done on both sides independently. Hence, we have less computational requirement compared to the PKC method, which is a highly important factor for the LoRaWAN constrained end devices because most end devices are battery powered. Furthermore, we used NIST Randomness Guidelines [26] to strictly ensure our keys are randomized enough, also, we conducted the uniqueness tests to make sure no repeat keys existing in our generated keys. More details can be found in the last three paragraphs of Section 6. Second, unlike the other key management schemes described in Section 2, they are mainly focused on one aspect of the key management issues. Our paper proposed other solutions to cover the research gaps where the other papers did not cover. A table with the different gaps that the other papers and our paper have covered can be seen in Table 1. Table 1 includes the publishing year, the authors of the papers, the reference to the papers, the research gaps/questions, and the solutions to the research gaps. As seen in Table 1, our paper covered areas such as key updating mechanism (the mechanism included, when and how does the key should be updated, it has expanded the current key updating methods introduced in the LoRaWAN v1.1.