# A Secure and Efficient Group Key Management Scheme for Clusters of String Inverters
## 6 Discussion
### KDC Election: Longest Sun Exposure Strategy  
Once group members get hold of the symmetric group key, we can think of group members as (continuously) running an election algorithm so as to elect the current KDC. The general idea behind such an election algorithm is to allow the KDS to select as the current KDC the group member less prone to becoming unavailable. The goal is to increase the chance the selected KDC does not turn off before finishing the execution of an operation. In this connection, because of unpredictable future weather events (e.g., clouds moving in), the algorithm actually accounts for inverters' back-story, meaning experienced sun exposure. In general, the longer the sun exposure, the longer an inverter is running. So, as soon as all group members get hold of the group key, we can imagine them running such an election algorithm. Practically, this consists of group members periodically exchanging (e.g., every one second) multicast status messages containing the amount of time since they are running. We referred to this time as uptime. A multicast status message of inverter \(i\), \(1\leq i\leq\mathrm{N}\), has the following structure:  
\[\left\langle\mathrm{IV},\ \left\{\mathit{UID}_{i},\tau,\ \mathit{uptime}_{i} \right\}_{K_{G}},H_{K_{\mathrm{C}}}\big{(}\big{\{}\mathit{UID}_{i},\tau,\ \mathit{uptime}_{i}\big{\}}_{K_{G}}\big{)}\right\rangle \tag{3}\]  
Essentially, each group member specifies its own unique identifier \(\mathit{UID}_{i}\), its own uptime \(\mathit{uptime}_{i}\), and a timestamp \(\tau\) that is meant to mitigate replay attacks. The IV introduces randomization and takes a new value at each newly generated multicast status message. The message is encrypted and authenticated by means of the current group key \(\mathrm{K_{G}}\). Before starting to send multicast status messages, each inverter identifies itself as the current KDC. Once a multicast status message is received, each inverter updates (its own view of) the identity of the current KDC based on the content of the received message itself. Specifically, whenever the difference between the received uptime and the current KDC's uptime is greater than the threshold value, the inverter with that higher uptime is elected as the new KDC. Meanwhile, if the difference between the received uptime and the current KDC's uptime is smaller or equal to the threshold, cluster inverters rely upon a backup election policy. Indeed, in this case, inverters have faced more or less the same sun exposure over time, therefore we can adopt another metric (e.g., we can rely upon the conventional election policy based on highest/lowest UID). In general, we can refer to the just-presented KDC election strategy as the \"longest sun exposure\". It is important to note that the threshold value represents the trade-off between KDC's unavailability detection (and subsequent new election) and stability of the elected KDC. KDC's potential instability, i.e., KDC's identity changing all the time, may lead to longer times in order to redistribute the group key to group members in the case of join/leave/key refresh operations. The lower the threshold, the faster the KDC unavailability detection but also the lower the stability of the currently elected KDC. In other terms, the threshold may be so low that the real KDC's identity does not get captured during this threshold time frame. On the other hand, the higher the threshold, the higher the stability of the current elected KDC, but the lower the KDC unavailability detection. In the end, such a threshold value should be determined through experiments as a function of the period whereby status messages are multicast. Ultimately, concerning the changes to be made to the group key management scheme described in Sections 4.1-4.3 there is the need of two additional steps at the very beginning of the protocol. These are required in order to account for such a \"longest sun exposure\" policy.