A scalable key‐management scheme with minimizing key storage for secure group communications

Abstract

Recently, many group communication services have become the focus for future developments in the Internet and wireless network applications, such as video-conferencing, collaborative work, networking games or online videos. In particular, these applications require data delivery from one sender to a large number of authorized receivers. Therefore, secure multicast communication will become an important networking issue in the future. Using a common encryption key only known by authorized members to encrypt transmitted data is a practical approach. But, whenever a group member joins or leaves the group, the common encryption key must be updated to ensure both past and future secrecy. As a result, minimizing key update communication cost and the key storage requirement of a group controller is a critical issue in a scalable and dynamically changing large group. A new key-management scheme is proposed to reduce the key storage requirement of a group controller to a constant size, which is far better than that of the previously proposed schemes, while retaining the same key update communication cost. In addition, the correlation between the key storage requirement of each group member and key update communication cost are also presented.

A new authenticated group key agreement in a mobile environment

“…There are two categories of group key establishment protocols: group key distribution protocol [23,25,39,40] and group key agreement protocol [5,19,29,41]. In the group key distribution protocol, the group key is created by one party and securely transmitted to other parties.…”

A communication-efficient and fault-tolerant conference-key agreement protocol with forward secrecy

“…The combination of forward and backward confidentiality yields key independence. The definitions of forward confidentiality and backward confidentiality are described as follows (Iolus, 1997;Wong et al, 2000;Tseng, 2003;Rhee et al, 2004):…”

Multi-layers balanced LKH

“…This is because in LKH, each multicast session is considered separately and this causes a lot of unnecessary keys to be stored by the GC. Although there are several work on minimisation of key at the GC side, which can minimise these effects [14,15], the members still require a significant amount of storage if each multicast session is considered separately; the more services the members subscribe to, the more redundant keys the members need to store. As for MLB-LKH, the difference in key storage between the members is at most m. From Figure 7(b), we can see that in LKH, the members in the highest layer store thrice the number of keys than the members in MLB-LKH.…”