# A Complete Key Management Scheme for LoRaWAN v1.1 +
## 5 Centralized Key Management Scheme for LoRaWAN
### Key Updating Scheme (KUS)  
As the LoRaWAN v1.1 only recommends two periodic updating methods (1. Update in a certain period. 2. Update when a counter value is reached.) which are good, but a larger number of keys updating methods can be developed to make it more completed and secured. Hence, a complete updating scheme is detailed in this section. In the KUS, there are two types of triggers to update the session keys (see Figure 3). Firstly, the event-driven triggers. This type of trigger is used when a major event is happening in the network such as a large-scale network intrusion or unusual behavior has been detected in the network that would result in a key updating procedure. Hence the CKMS would use KUS to update their keys in the CKMS servers. Hence, even the attackers might acquire the keys during the event. They would still fail to decipher the contents as the results of the key updating. In this case that the CKMS can either has their own detection libraries or outsourcing the detecting role to a security specialist firm to let them inform CKMS when the network suffers or has some unusual behavior to make CKMS update their keys. On top of that, the CKMS manager can also update the keys as they desire to do so at any time, i.e., the CKMS manager can update all the keys at one single action to result in all the keys changed by using the proposed key random generator (KGS). Secondly, the time-driven updating procedure. This procedure can be either periodic or aperiodic. For a periodic update, an end device and corresponding servers can update their paired keys at a certain period. For example, when a new pair of keys have been deployed in the field, a clock has been ticked down, a pair of new keys would be updated as the clock's time reach its end of the period. Or the key updating would occur when both end devices and corresponding servers have communicated over a certain number of times, then the updating procedure would be triggered. On the other side, an aperiodic update means the updating procedure can happen at any time. KUS would use a number-pool system; i.e., the keys would be updated once a pre-figured number is drawn from the pool. However, both methods need to be carefully monitored by the CKMS side. Due to the LPWAN devices usually battery-based that the users would not want their devices to drain out too soon as the result of key updating which would impact on the users' experience. Therefore, the CKMS must ensure the key updating is balanced without occurring too much unless there is a security concern. A balanced update means that the power consumption of key update in the devices is balanced with the security requirements. For example, a battery has a 100% lifespan, then to constraint the power usage on key updating that the KUS can set up a maximum updating number for key updating. A portion of the energy would be dedicated to key updating such as a total 10% of its lifespan. Then 10 cycles of key updating might be set with each cycle of 1% of energy dispatch. Any one key update would  
Figure 3: A tree-diagram illustrates KUS. count as one cycle no matter what types of trigger. Once it reaches its maximum number of cycles, the CKMS could decide whether to update the keys by comprising the energy. In addition to that, every end devices should be classified as their security levels, either low or high-security level. It requires a lower number of keys updating for a low-security end device. However, it requires a more frequent key updates for a high-security end device even though that might need to compromise the energy. Therefore, CKMS would decide the frequency of key updating base on their security requirements. Furthermore, the high frequent key update does not make sense if the device is not making any communication, hence counter-based key updating should have higher priority than updating with a fixed period.