# Group Authentication Scheme for Neighbourhood Area Networks (NANs) in Smart Grids
## 2 Group Authentication
### Related Work
We also intend to use only symmetric encryption on the sensor node to minimize any processing delays at the intermediate nodes. [PERSON] _et al._, propose a generic framework for group authentication [14]. Their scenario considers password-based authentication in one go, for a user group. The focus is on reducing the time taken for authentication, like in [13], rather than authentication of a member, anonymously. The scheme is fairly close to our application scenario since the hierarchy of authentication (NOC--Gateway--Device) is quite similar (Server--group authenticator--end user). However, there is no evidence that it is applicable for low resource devices that we consider or the fact that the scheme will work (similar to the proposal in [9]) for multi-hop scenarios where an intermediate device needs to perform authenticated forwarding, as in our case. [PERSON] _et al._, present a group authentication and a group key distribution scheme for _ad hoc_ networks [15]. They argue that conventional group authentication protocols cannot serve the requirements of _ad hoc_ networks since there is no designated group leader and the fact that the number of nodes in the network are not known in advance and can change dynamically. Therefore, schemes such as those in [10,13] cannot be deployed. The scheme proposed uses an identity-based bilinear pairing. There are five distinct phases, which include join and leave phases for the individual nodes. This is quite similar to the key management architecture schemes for SCADA networks discussed in [16]. Again, there is no specific mention of a multi-hop scenario requiring authenticated forwarding,Multi-hop scenarios are necessary for functional grouping as well as to build the radio path up to the NOC. Unlike in the case of WLANs used in [12], the radio range and the transmit power of the sensor nodes that we consider, are limited. [PERSON] _et al._, address the authentication between a smart meter and the utility server termed as a Security Associate (SA). The SA is a dedicated server delegated to perform authentication by the central server at the NOC and is used for authentication by a group of SMs. They propose two separate schemes for authentication and key management, termed SGAS and SGKM, respectively. They propose a four-phase authentication approach, which has not been implemented and measured for performance [17]. They consider a mesh topology for SMs constituting the NAN, and use WiMax for interconnecting the smart meters. Their work is fairly close to the scenario we consider, from a topological perspective. Their functional requirement is similar to our requirement in that the authentication has to be done with a central entity. However, they delegate the central authentication autonomy to the SA. There are clear differences in the scenario we consider. Firstly, in our scenario such an intermediate node is merely a SM with the role of a gateway and with no autonomy. The risk of such delegation, we believe, is that the SA nodes are susceptible targets for attacks and can cause considerable impact in terms of the central server delegating the autonomy to a backup SA and the reachability of the SA from the end nodes. Secondly, they do not consider what we term as \"authenticated forwarding\". The traffic from the downstream nodes is not validated at the intermediate nodes. Thirdly, they use an asymmetric encryption method for privacy and a broadcast mechanism for key distribution. We believe, while key distribution via broadcast does reduce the communication overhead, multicast is a more secure option. Our scenario uses a single central entity for authentication and individually distributes the keys to each of the nodes. [PERSON] _et al._, proposed an Extensible Authentication Protocols (EAP) based [18] unified key management mechanism (UKMF) that can generate ciphering keys for multiple protocols of multiple communication layers from a single peer entity authentication procedure [19].