# Symmetric-Key-Based Security for Multicast Communication in Wireless Sensor Networks +
## 2 Related Work  
In general, there are three main approaches for key management in WSNs, based on symmetric-key cryptography, public key cryptography, and hybrid. Especially in a hierarchical architecture, it can make sense to use a hybrid approach, in which the most computational heavy operations are performed by a powered note. In this case, authentication and integrity are often obtained by digital signatures. However, as there is a huge performance difference between symmetric-key and public key cryptography, it is still interesting to look at symmetric-key-based solutions, due to the limited energy, communication bandwidth, and computational capacities of the sensor nodes. Several proposals for key management using a symmetric-key-based approach in WSNs have been published. Depending on the assumed topology, these proposals can be divided in two categories: a hierarchical and non-hierarchical (or distributed) architecture of the nodes [7]. Most proposals for symmetric-key-based key management protocols assume a hierarchical network, in which the nodes have a predefined position in the network. Within the domain of symmetric-key-based, authenticated key management protocols for hierarchical networks, the Localized Encryption and Authentication Protocol (LEAP) [8] is the most complete one. LEAP describes procedures to derive keys for the most prevalent communication scenarios (being between two cluster nodes (CNs)), a group key for all nodes in a cluster and a network key shared by all nodes. References [9; 10] present randomized approaches for the key management in hierarchical networks, which have no guarantee on successful key establishment but limit the impact of a compromised node. Both protocols have large storage requirements for each of the nodes in the network. Furthermore, partial solutions for authenticated symmetric-key-based protocols are described in [11; 12; 13; 14]. In [11], a method using one-way functions to derive an authenticated pairwise key between a CN and a cluster head (CH) is explained. Yet, group keys are not derived in this paper. In [12], each node receives an evaluation of a point on a predefined bivariate polynomial of the base station (BS), dependent on its position in the sensor topology. Lagrange interpolation (LI) is used for the computation of the group key. However, this still requires a lot of unicast communications for the distribution of the group key to the individual members. Moreover, this paper does not derive a method for using this group key in an authenticated way. Finally, the key management in [13; 14] is based on a generator matrix, predefined at the BS. The computation of the group key requires the involvement of the BS and cannot be performed by the CH alone. Again, these papers do not describe a mechanism to guarantee authenticated usage of the group key. In addition, the protocols from [11; 12; 13; 14] are restricted to star networks, and thus no mechanism is described to compute a shared key between two CNs of the same cluster. Key distribution solutions for hierarchical network structures are often more efficient, but less flexible as it is not possible to create custom groups, because the supported groups depend on the structure of the network. Therefore, solutions for non-hierarchical architectures are required. Key management schemes of [15; 16; 17] describe this type of network architecture. However, the schemes of [16; 17] are using asymmetric-key-based methods as the basis of their key establishment system. The scheme in [16] is based on the Merkle identity tree. With this scheme, the direct and secure communications between any subgroup can be implemented and the delay of communication is decreased, making the scheme more suitable for WSNs. In [17], a building method of a key tree is proposed to reduce computation and storage overhead on every sensor node. In [15] a robot-assisted network bootstrapping technique is proposed. It focuses on scheme efficiency and supports various multicast group semantics.