A Survey on Secure Group Communication Schemes With Focus on IoT Communication

A key feature for Internet of Things (IoT) is to control what content is available to each user. To handle this access management, encryption schemes can be used. Due to the diverse usage of encryption schemes, there are various realizations of 1-to-1, 1-to-n, and n-to-n schemes in the literature. This multitude of encryption methods with a wide variety of properties presents developers with the challenge of selecting the optimal method for a particular use case, which is further complicated by the fact that there is no overview of existing encryption schemes. To fill this gap, we envision a cryptography encyclopedia providing such an overview of existing encryption schemes. In this survey paper, we take a first step towards such an encyclopedia by creating a sub-encyclopedia for secure group communication (SGC) schemes, which belong to the n-to-n category. We extensively surveyed the state-of-the-art and classified 47 different schemes. More precisely, we provide (i) a comprehensive overview of the relevant security features, (ii) a set of relevant performance metrics, (iii) a classification for secure group communication schemes, and (iv) workflow descriptions of the 47 schemes. Moreover, we perform a detailed performance and security evaluation of the 47 secure group communication schemes. Based on this evaluation, we create a guideline for the selection of secure group communication schemes.

have emerged in which multiple users are simultaneously 23 connected, such as video conferences, Pay-Tv, group chats 24 on social networks, or online games. Also, devices com- 25 municating in smart environments [2], [4] belong in this 26 category. Such applications require efficient distribution of 27 The associate editor coordinating the review of this manuscript and approving it for publication was Jiafeng Xie. messages between the many involved participants with dif-28 ferent requirements concerning the security level. 29 The term Internet of Things (IoT) refers to the interconnec-30 tion of objects (things) that communicate via networks using 31 various identifying and communication technologies [5]. The 32 steadily growing numbers of online services and IoT devices 33 gather and share vast amounts of data [6]. In addition, more 34 and more IoT applications involving group communication 35 permeate various important areas of our everyday lives. 36 These areas include smart factory, remote healthcare, smart 37 home, smart mobility, traffic management, and more [5]. The 38 new 5G technology immensely accelerates data transfer and 39 allows further scaling of the connectivity process [6]. The 40 introduction of 5G will result in faster broadband speeds 41 different aspects. Based on this analysis, Cheikhrouhou rec-98 ommends one of the 22 schemes using three decision criteria. 99 In this survey paper, we extend the survey of Cheikhrouhou 100 by analyzing additional 25 schemes considering 12 different 101 aspects. We use this expanded knowledge base to recommend 102 a concrete scheme that considers one additional decision 103 criterion besides Cheikhrouhou's decision criteria. Moreover, 104 when recommending a scheme, we consider not only its 105 performance but also its security features. 106 More specifically, the contributions of our survey 107 paper are:  3) Definition of selection guidelines for SGC schemes. 113 The remainder of this paper is structured as follows. 114 In Section II, we provide background information required 115 for understanding SGC schemes. In Section III, we give an 116 VOLUME 10, 2022 overview of related work and a delimitation to this work.
Next, in Section IV, we present our survey methodology. 118 In addition to the procedure of our literature review, we also 119 show the security features and performance metrics we deter-120 mined and the classification approach for SGC schemes. 121 We also present the decision criteria used to create guidelines 122 for the selection of methods. In Sections V, VI, and VII, 123 we present the schemes we found using our survey methodol-124 ogy, grouped by category, and identify their security features 125 and performance. We present the derived method selection 126 guidelines in Section VIII. Finally, we conclude the paper in 127 Section IX. This section describes different types of cryptographic tech-171 niques, such as symmetric or asymmetric cryptography. 172 These techniques are prevalent in the compared SGC schemes 173 and impact their performance and also their level of security. 174

175
In symmetric cryptography, algorithms use the same crypto-176 graphic key for both encryption of the message and decryp-177 tion of the corresponding ciphertext. They are faster than 178 asymmetric algorithms and allow the encryption of large 179 datasets. However, they require sophisticated mechanisms 180 to securely distribute the secret keys to the communicating 181 parties [18]. The only symmetric scheme used in SGC is the 182 XOR Cipher. Asymmetric cryptography, also known as public and private 185 key cryptography, uses two keys: a public key for encrypting 186 messages and a private key for decrypting ciphertexts. The 187 public key of a communicating party is publicly available, and 188 everybody can use it to encrypt a message. The idea of asym-189 metric encryption is that only the owner of the corresponding 190 private key, which is unknown to anybody else, can decrypt 191 the message [19]. Asymmetric algorithms are much slower 192 than symmetric ones. In practice, this performance disadvan-193 tage of asymmetric encryption schemes is mitigated by using 194 asymmetric encryption only to exchange a key, which is then 195 used with higher-performance symmetric encryption. In the 196 following, we present asymmetric schemes used for SGC.

197
• One-way Function: Informally described, a one-way 198 function is a function where the computation in one 199 direction is simple, while the computation in the reverse 200 direction is much more difficult.  [16], the 279 authors also consider the network model of WSNs required by 280 the schemes. Moreover, they name further security require-281 ments, such as node compromise robustness and group 282 independence.
283 Table 1 gives an overview of the factors existing surveys 284 use or mention when evaluating GKM or SGC schemes com-285 pared to our work. In contrast to existing work, our survey 286 examines these factors in detail for each scheme, presenting a 287 systematic and extensive comparison. We also consider more 288 than twice as many SGC schemes as the existing surveys.

289
Many surveys focus on one category of SGC schemes, 290 typically either the centralized [28] or contributory [32], [33] [30]. Jiang and 296 Hu [29] only survey centralized and decentralized schemes, 297 while Mapoka [17] categorize the protocols into network 298 independent and network dependent. Li and Wu [31] divide 299 key management (according to differences in the topology) 300 into five classes: centralized, broadcast, hierarchical, sub-301 groups, and distributed architectures. Xiao et al. [27] classify 302 schemes focusing on the following seven techniques of key 303 management: single network-wide key, pairwise key estab-304 lishment, trusted base station, public key schemes, key pre-305 distribution, dynamic key management, and hierarchical key 306 management. As for Klaoudatou et al. [30], they focus only 307 on cluster-based approaches. Rafaeli    47 SGC systems, (2) analyzes not only ten but twelve aspects,

329
(3) considers not only three but four decision factors, and 330 (4) considers not only performance but also security features.

332
In this section, we first describe our literature research 333 approach for collecting SGC schemes. Then, we present 334 our classification, comprising the three main categories cen-335 tralized, distributed/contributory, and decentralized/hybrid.

336
Based on this classification, we classify our collected SGC 337 scheme set. After that, in Section IV-B, we describe the 338 performance metrics and security features we use as a basis 339 for comparing different SGC schemes. In Section IV-C, 340 we subsequently present our approach for deriving guidelines 341 together with a decision tree to provide assistance for devel-   [16], [17], [25], 352 [27], [29]. We applied the forward snowballing technique on 353 these surveys to discover further schemes. This allows us to 354 find more surveys and other papers describing or proposing 355 new schemes. For data selection, we defined the following 356 inclusion and exclusion criteria. If a paper proposes an SGC 357 scheme that fully defines a GKM, we include it into our set 358 of schemes if it is not already present. On the other hand, 359 we exclude schemes from our set that do not fully define 360 a GKM or fit none of our three categories. As a result, 361 we identified and gathered a total of 47 different protocols 362 as the main schemes proposed in literature.

363
While investigating existing GKM and SGC surveys, 364 we discovered minor inconsistencies regarding the termi-365 nology used for the categories of group key management. 366 Many researchers, such as [2], [25], categorize key manage-367 ment into centralized, decentralized, and distributed proto-368 cols. Sakarindr and Ansari [16] use the categories centralized, 369 distributed, and contributory. Cheikhrouhou [10] divide key 370 management into centralized, contributory, and hybrid pro-371 tocols. These inconsistent labels mainly refer to the same 372 categories and are, therefore, interchangeable. Researchers 373 using the term distributed refer to the same type of GKM pro-374 tocols as the ones using the term contributory. Another name 375 for this category is Group Key Agreement (GKA), as each 376 member contributes to establish a common group key [2] , 377 without the presence of a trusted third party. The counter-378 part to the distributed/contributory approaches are the cen-379 tralized approaches, not requiring communication between 380 the group members to establish a group key. However, with 381 centralized approaches, a trusted third party must be present. 382 A mixture of both approaches are the hybrid approaches 383 in [10], in which on the one hand a trusted third party is 384 present, but on the other hand the group members also have 385 to communicate among each other to establish a common 386 group key. This is usually done by dividing a group into 387 subgroups managed by group members. Literature refers to 388 this approach also as decentralized, even though a third party 389 is present. This leads us to our SGC scheme classification 390 into three categories: centralized, distributed/contributory, 391  and decentralized/hybrid. In Figure 3, the classification step 392 illustrates the differences between these categories in terms of 393 group key management. We classify all 47 SGC schemes into 394 one of these three categories (see Table 2). In the following, 395 we describe these categories in more detail: In distributed SGC schemes, the group members collabo-416 rate to manage the group without a central authority [25]. 417 Thus, distributed schemes have the advantage of fault toler-418 ance [10], since no single entity is responsible for distributing 419 and generating the keys [25]. However, this comes at the 420 expense of higher computational costs on the side of the group 421 members and other drawbacks, such as increased energy 422 consumption for the devices [10].

424
In decentralized architectures, a central unit carries out some 425 tasks, while others require cooperation. These decentral-426 ized protocols aim at achieving both efficiency and fault 427 tolerance [10]. A very common approach in decentralized 428 schemes is to divide the group management among SGC. 429 The goal of using SGC schemes is to minimize the problem 430 of concentrating all the workloads on a single entity [25]. 431 Another approach is to assign the group key generation to 432 a group controller in a centralized manner, while having the 433 group key distribution done contributory by all group mem-434 bers [10]. We classify such hybrid schemes as decentralized, 435 since they generally have similar characteristics as traditional 436 decentralized protocols. Therefore, we named this category 437 decentralized/hybrid. 439 We have to compare these schemes in terms of security 440 features, and performance metrics to derive SGC scheme 441 VOLUME 10, 2022 selection guidelines for specific use cases. We identify 442 relevant security features and performance metrics that 443 we extracted from multiple surveys [10], [16], [17], [25] and signing the message using strong encryption keys [16]. 449 Message confidentiality means that only authorized mem-450 bers can learn meaningful information from the message.

451
In addition, data circulating within a group must stay con-     Group key renewal as part of the rekeying process either 505 occurs periodically or at membership change [10]. This time-506 or member-driven frequency significantly impacts the per-507 formance of an SGC scheme. Every key renewal implies 508 generating and distributing a new key, causing expensive 509 communication and computation overhead [29]. Thus, the 510 number of key updates should be as low as possible. 511 We use the big O notation to describe the storage, com-512 munication, and computation costs asymptotically, enabling 513 comparability between the schemes. For schemes where the 514 costs are not already explicitly stated in this form, we map 515 costs into this standardized form. The storage cost refers to 516 the number of keys stored at the GC and at group members. 517 The number of messages that must be sent for rekeying, or at 518 a join or leave event, comprises the communication cost of an 519 SGC scheme. 520 C. DECISION FACTORS SGC SCHEME SELECTION 521 We identify the main scenarios and constraints related to 522 group communication applications that serve as decision fac-523 tors to develop recommendations and construct a decision 524 tree to select SGC schemes for different application domains. 525 One decision factor that nearly all papers on key manage-526 ment or SGC mention is the group size [2], [10], [16], [17], 527 [25], [26], [27], [28], [29], [30], [31]. The group size has 528 an immense impact on the performance of an SGC scheme 529 since the number of members can be highly diverse [77]. The 530 number of members can range from less than 10 (e.g., devices 531 communicating in a smart home) to far more than 1000 532 (e.g., sensor nodes deployed in military applications) [10]. 533 We consider a group to be small if it comprises less than 534 100 members. Otherwise, the group is as large [77].

535
Another decision factor frequently appearing in the liter-536 ature is the group's dynamism [2], [10], [29], [31], which 537 refers to two group characteristics. First, group membership 538 can change in a highly dynamic way or remain rather static. 539 This can possibly require an SGC scheme to handle very 540 frequent key updates [31]. Second, the dynamism of a group 541 can also refer to its topology. For example, members are often 542 static in indoor applications or environmental monitoring. describe how a scheme performs in that specific category 598 compared to the other approaches. Table 6 summarizes the 599 security features of centralized schemes. Tables 4 and 5 illus-600 trate that different schemes achieve varying results in terms of 601 performance and apply different techniques. Some schemes 602 are significantly more efficient than others; however, they 603 may pose unbearable risks to the security of the group to 604 achieve such results.

605
GKMP provides remarkable performance in terms of 606 storage, communication, and computation costs, but this is 607 achieved at the expense of compromising the forward secrecy. 608 ELK, SGCSH, SGR, and HSHKD use a timed rekey to decou-609 ple the refreshing of the group key from any membership 610 changes. The downside of this periodic rekey is that it could 611 either violate forward and backward secrecy for a short time 612 until the next update happens, or impose small delays in 613 the joining or leaving process, such as in ELK. Among the 614 centralized approaches, the ones using a key tree hierarchy 615 seem to be preferable. The first scheme of that kind is LKH 616 together with its improved extensions and variants, such as 617 LKH+, OFT, OFCT, S2RP, LARK, and TKH. These schemes 618 reduce the communication cost to O(log(n)), but this could 619 still be high for devices with limited resources, such as sensor 620 nodes in WSNs.

621
The schemes SGCSH, SGR, and HSHKD try to solve the 622 problem of not receiving a key update due to unreliable chan-623 nels or other similar problems. In these so-called self-healing 624 protocols, members can recover lost keys based on previ-625 ously received ones. This avoids repetitive retransmission of 626 key update messages. These advantages come at the cost of 627 imposing a limited group lifetime, after which a new group 628 has to be reestablished. SKDC, XKFS, SBSA, KMGC, and 629 CL-EKM rekey the group by sending an encrypted message 630 for each member, limiting the scalability of these schemes. 631 SeGCom and LEAP require synchronization between mem-632 bers since they use µTesla. According to [

641
In this section, we compare distributed/contributory SGC 642 schemes in terms of security and performance. A more 643

682
In this section, we discuss the performance and security of 683 decentralized/hybrid SGC schemes. A more detailed descrip-684 tion of the functionality of the considered schemes can be 685 found in the supplemental material. Table 10 and Table 11 686 summarize the performance of the distributed schemes. 687 Table 3 explains the notation. Table 12 compares the schemes 688 according to their security features.

689
SMKD achieves good performance results, but just like 690 centralized GKMP, it uses a KEK known to all members to 691 encrypt the next group key, compromising forward secrecy. 692 MARKS and Kronos do not provide key independence. 693 Kronos generates the new keys based on previous ones. If an 694 attacker compromises any of the old keys, the attacker will 695 have access to all future keys. This is also true for MARKS 696 with a compromised seed. MARKS, Kronos, and DEP use 697 a timed rekey that leads to delays of the group key after a 698 member has joined or left the group. That member may then 699 have unauthorized access to group communication until the 700 next rekey happens.

701
Some schemes limit the key update to the subgroup where 702 the change has occurred to solve the problem of making all 703 members change their keys on a membership change. This is 704 achieved by each subgroup using its own key for communica-705 tion within the group. However, this has the consequence that 706 when messages are exchanged between groups, the messages 707 for the other group must be encrypted with the other group's 708 key. Therefore, in this solution of different keys for each 709 subgroup, direct interference with the data path is required. 710 VOLUME 10, 2022   An example scheme for this is Iolus. Moreover, some decen-     groups, these schemes lead to high bandwidth usage and 790 energy consumption. Hence, these approaches should only be 791 used in applications with few members or unlimited energy 792 supply. Additionally, in distributed schemes, the group mem-793 bers generate the group key collaboratively, requiring a con-794 nection between the members. Thus, distributed approaches 795 are more appropriate for static groups with reliable commu-796 nication channels.

797
DH-LKH, D-OFT, BD, and G-DH require no group leader 798 in the group key generation process. These schemes rather 799 distribute the computation costs among all members. In con-800 trast to the other three approaches, G-DH does not distribute 801 the costs equally since the number of exponential operations 802 increases with each member in the sequence of the key gen-803 eration. D-LKH, DH-LKH, and D-OFT exhibit the lowest 804 communication costs of all distributed schemes. The latter 805 two also have a decent overall performance. DH-LKH and 806 D-OFT require no GC and are suitable for small groups and 807 devices with limited energy supply. 808 SGRS imposes very low computational costs for the mem-809 bers, especially since they only execute hash and XOR opera-810 tions. Thus, this scheme is very suitable for small devices with 811 a low-power CPU applications. SHM, CRGR, and BKM, 812 as well as Octopus and CKA, require large computations by a 813 member who takes the role of a group leader or a separate GC. 814 Thus, they are not appropriate for applications with a weak 815 GC or none. EGKMST is a scalable and efficient scheme 816 regarding storage and computation, making it suitable for 817 large static groups without a powerful GC. PCGR integrates 818 security against member compromise attacks, but requires 819 synchronization between members. Moreover, PCGR does 820 not support joining and leaving after the group setup due to 821 the pre-distribution of keys.

823
Decentralized SGC schemes generally provide good scal-824 ability by dividing the group into subgroups managed by 825 SGCs. Thus, they are more suitable for applications with large 826 groups. Additionally, by distributing the workload, more 827 entities can fail before affecting the group. This increases 828 the applicability of decentralized schemes for more dynamic 829 groups.

830
SMKD is a scheme that achieves excellent results in terms 831 of performance. Thus, it is very suitable for weak GCs and 832 devices with a limited energy supply. However, just like 833 centralized GKMP, it compromises forward secrecy, which 834 makes it inappropriate for applications with high security 835 requirements. The approaches Iolus and CS are only suit-836 able for special applications that use one-to-many instead of 837 many-to-many communication. Iolus offers the advantage of 838 treating membership changes locally within the subgroup. 839 This makes it especially suitable for weak GCs and dynamic 840 groups, but its communication costs could drain the limited 841 energy of devices. whereas no category was excluded for a powerful GC. The  In the following, we now consider the cases where more 939 than one scheme enables the respective combination of secu-940 rity features. We start with the set of schemes consisting 941 of S2RP and LARK. For this set, our guidelines call for 942 the selection of S2RP. The reason is that S2RP and LARK 943 are both centralized schemes and exhibit the same perfor-944 mance except for communication costs. Regarding communi-945 cation costs, S2RP is in O(log(n)) regardless of the topology, 946 whereas LARK may also be in O(n) in rare cases depending 947 on the topology. Thus, our guidelines recommend the selec-948 tion of S2RP.

949
Next, we consider the combination of security features 950 provided by the centralized schemes ELK and LEAP. Our 951 guidelines recommend choosing LEAP because its perfor-952 mance costs are always in the low range, whereas ELK's costs 953 are in the medium to high range (see Table 4).

954
The schemes PCGR and SGCSH provide the same unique 955 combination of security features that no other scheme 956 provides. Although the two schemes offer the same combi-957 nation of security features, they differ in their basic func-958 tionality. SGCSH is a centralized scheme, while PCGR is a 959 distributed scheme. Accordingly, our guidelines recommend 960 that if a trusted, powerful, central authority is available, 961 SGCSH should be selected; otherwise, PCGR should be 962 selected.

963
The two decentralized schemes Kronos and DEP both 964 provide the same unique combination of security features. 965 Since both are decentralized and the performance costs of 966 99958 VOLUME 10, 2022

1003
Applications with groups of communicating devices are 1004 rapidly growing in importance as electronic communica-1005 tion becomes more sophisticated. The emergence of the 1006 Internet-of-Things and fast network technologies such as 1007 5G are increasing the level and speed of connectivity, 1008 leading to even more group communication applications. 1009 Researchers proposed several schemes for secure group com-1010 munication (SGC). These SGC schemes securely manage 1011 cryptographic keys in groups that use many-to-many commu-1012 nication encrypted with a shared symmetric group key. The 1013 security and efficiency of SGC schemes vary significantly 1014 depending on the application and its group characteristics [3]. 1015 Developers who need to integrate security into group com-1016 munication must choose one of the overwhelming number 1017 of SGC schemes. Additionally, they have to ensure that it is 1018 efficient and secure enough for their specific application. Our 1019 survey approached this problem by comparing and evaluating 1020 a total of 47 different SGC schemes in terms of security 1021 and efficiency. We covered the three main categories of SGC 1022 schemes: centralized, distributed, and decentralized. We used 1023 the metrics storage costs, communication costs, computa-1024 tion costs, key update frequency, and types of cryptogra-1025 phy used. We analyzed if each of the 47 schemes achieves 1026 the requirements of forward and backward secrecy, instant 1027 rekeying, message integrity, message confidentiality, member 1028 authentication, compromise robustness, and group indepen-1029 dence. Moreover, we identified the most suitable and best-1030 performing schemes for different scenarios of applications 1031 with communicating groups. These scenarios cover differ-1032 ences in group size, group dynamism, the performance of the 1033 group controller, and the provided energy supply. Based on 1034 these results, we proposed guidelines to assist developers in 1035 choosing an appropriate scheme for their specific application 1036 requirements. We also illustrate our recommendations with 1037 decision trees that further facilitate the process of selecting 1038 VOLUME 10, 2022 a scheme for a given application scenario.