Authentication | Protocol used | Structure | Limitations and specific characteristics of the protocol | |
---|---|---|---|---|
HKAP [25] | No | Some GKA | Users are gathered into clusters and shape a various levelled structure. The member chosen as CHs ought to be more effective devise and can transmit at higher level links | Grants the geographic revamping of members without setting off a key-revive each time a user be in motion starting with one cluster then onto the next |
GKA-CH [21] | No | BD convention [12] in each layer of a roundabout various levelled group structure | The group is prearranged in “h” hierarchical layers encompassed by one/more clusters organized in a circle | All clusters have the same size |
PB-GKA-HGM [31] | Yes | A password-based convention is implemented in every cluster | Constructs a level wise tree structure using 3 entities: the chief controller C in peak layer, different CHs Si and several members (CM) in each cluster | Each CM ought to have a password and a pair wise secret key imparted to the CH. Each CH ought to hold a password and a pair wise secret key imparted to the GC. Passwords and secret keys are preloaded into hubs |
AP-1 [33] | Yes | A variant of the BD scheme called DB [7] is used for CKs as well as GK | A CH is chosen from each of the cluster to take part in the creation of the complete GK | Communication between CHs should be one hop |
AP-2 [33] | Yes | The CK are established using DB protocol and for GKDBS [37] is used | CHs are prearranged in a tree structure, which facilitates proficient management of dynamic membership alterations | The GKA implemented in AP-2 is pairing-based, which raises the cost of computation and the entire complexity of the scheme |
ACEKA [26] | Yes | D-H and Joux’s tripartite key agreement [35] for clusters of 2 and 3 nodes respectively | Members are clustered into sub-groups of size 2 or 3. In numerous CK trees, the root node stand for the CK. A spine key merge each and every CK trees. Virtual nodes are utilized to build the tree structure | Hubs are assembled into sub gatherings of size 2 or 3. A few GK trees. The root hub speaks to the CK. A spine key consolidates all the CK trees. Virtual hubs are utilized to build the tree structure |
CDGH [30] | No | GDH.2 [36] GKA protocol is used to generate the keys | Members are clustered into identical sized perfectly balanced hierarchical structure | The members of the group don’t have to store intermediate keys to create the session key |
A-DTGKA [20] | Yes | The protocol is ID-based and employs pair wise keys for entity authentication | Hierarchical tree structure of clusters consisting of neighbour members | Member characteristics should be publicly accessible TA is required in the setup phase to produce the private keys for each node |
ACBGKA [18] | Yes | Utilizes the Joux’s [35] tripartite key assertion convention | Each of the clusters contains either two or three nodes | A KGC is essential for the creation of the private/public keys for every member |
C-AT-DH [28] | No | The BD and T-GDH protocol are used for the generation of the cluster and group key respectively | Users are gathered into clusters named cliques | Clusters must have a explicit structure i.e., each CM can commune in one-hop with all other CMs |
ECDH-SKDM [43] | No | CLIQUES key agreement | Hierarchical tree structure | The maximum amount of sub group members should be limited |
Proposed-protocol NM-CHH-GKA | YES | NM-GKA [16] is used for CKs as well as GK | Clustering-based, Hybrid, Hierarchical (CHH) structure | The maximum amount of cluster members and number of clusters should be limited (scalable) in case of ad hoc networks |