# A Secure and Efficient Group Key Management Scheme for Clusters of String Inverters
## 5 Performance Evaluation
### Latency for Group Key Distribution  
Latency of operations must comply with the typical timing constraints of a PV plant that are in the order of one minute (at the most). This is essentially a usability requirement engineered (particularly) when the KDS comes in the form of a mobile application. It represents the (maximum) time the operator is willing to wait in order for an operation to complete. The lower the latency the better it is. We mainly focused on the performance of join and leave operations, which use public key cryptography to establish secure channels (i.e., TLS connections) to communicate the current/new group key to group members. The refresh operation instead multicasts the new group key in its encrypted form under the current group key. This operation uses symmetric encryption, which is much faster than public key encryption [80]. We evaluated the latency to communicate with a number of group members using different cryptosystems. Specifically, we assumed the group size to range between a minimum of 10 and a maximum of 50 inverters and evaluate the scalability of the prototype as a function of the group size. The lower and the upper bound were due to Power-One Italy S.p.A. single PV plant's typical capacity, around 2 MegaWatts (MW), and Power-One Italy S.p.A. maximum and minimum inverters' nominal output power, namely 200 KW and 50 KW, respectively. Although the theoretical upper limit was 40 inverters, we considered 50 of them so as to offer a safe margin. Practically, to evaluate latency, since the cluster at our disposal consisted of ten inverters only, we executed the prototype multiple times on each cluster inverter in a concurrent fashion, but the one selected as KDC. The different processes only differentiated by the port number associated with the TCP listening socket. Specifically, each cluster inverter but the KDC executed 2, 3, 4 or 5 processes for group size respectively of 20, 30, 40 or 50 inverters. Latency was computed as the time required to distribute the group key to required group members. For each group size considered: (i) have performed 40 experiments, each under the same conditions and (ii) we then double-checked that the latency values obtained by the experiments were independent and identically distributed (i.e., IID-ness hypothesis test). This was accomplished considering a 99% confidence level; (iii) finally, we computed the mean latency and the associated confidence interval. The conditions under which experiments were carried out are summarized here below:  
1. The CRL is empty, i.e., it does not contain any revoked certificates;
2. Inverters' mutual authentication;
3. The negotiated cipher-suite(s) consists of one and only one element (because each cipher suite takes 2 bytes in the ClientHello message), namely: 1. ECDHE-RSA-AES128-GCM-SHA256 in case of RSA keys; 2. ECDHE-ECDSA-AES128-GCM-SHA256 in case of EC keys. 4. Parameters (i.e., \(p\),_g_) related to the ECDH(E) key exchange have been pregenerated by one inverter and stored on each of the other cluster inverters;
5. The verification of the inverter certificates' digital signature consists of one and only one verification. This is according to the defined PKI hierarchy chain. Signature's verification is carried out using the public key of the root CA;Session caching not enabled. Experimental results were pretty much the same, with the latency in case of a leave operation a bit higher due to the generation of the new group key (and the time to store the updated CRL). Therefore, with respect to Figure 6; Figure 7, we considered a leave operation only. For this reason, a group size equal to some value \"x\" means that the cardinality of the set of remaining inverters, i.e., the ones to which distribute the newly generated key, is equal to \"x\". Finally, it is important to remember that latency accounts for both computation and communication overheads.