Article Preview
TopIntroduction
Collaborative software applications enable members of a group to communicate with each other and achieve common objectives. Enterprises use social networks as collaborative networks to brainstorm participants to improve the knowledge level within the organization (Franchi et al., 2013). Computer supported collaborative learning provides support for coordinating co-operation between teachers and students, in learning activities. Collaborative Security intends to secure the Internet by coordinating security activities of users (Meng et al., 2015). The communication between the participants in the applications mentioned above need not be at the same time; or in other words the communication can be asynchronous. On the other hand, multimedia conferencing and multi-user games are synchronous collaborative applications. Vehicles in a network could also be participants in a conference.
Conferencing applications are collaborative applications which allow geographically separate users to exchange multimedia information in real-time. Conferencing applications should provide security properties such as authentication and confidentiality. Currently, conferencing applications like Adobe Connect, BigMarker, Cisco WebEx, and Skype use SSL/TLS for providing security. SSL/TLS is a security protocol to establish a secure communication channel between two participants. SSL/TLS provides authentication by means of public key certificates, using Public-Key Infrastructure, and confidentiality by symmetric key encryption using Advanced Encryption Standard (AES). The cryptographic algorithms for symmetric encryption and authentication are negotiated during handshaking sub-protocol of SSL/TLS.
The use of SSL/TLS for setting up secure collaborative networks would need additional communication overheads because at least n(n-1)/2 handshakes are needed, for securely interconnecting n participants using SSL/TLS. Since, each handshake protocol of SSL requires four messages, at least 4n(n-1)/2 messages are needed.
GKA protocols (Manulis, 2008) enable each member of a group to compute a common secret, referred to as group key. The number of messages needed for GKA protocol to establish a secure network is less compared to SSL/TLS. For example, to interconnect n participants, Group Diffie-Hellman (GDH) protocol (Ateniese et al., 2000), Burmester and Desmedt (BD) protocol (Burmester & Desmedt, 1994) and a protocol by D. G. Steer, L. Strawczynski, W. Diffie, and M. Wiener (SLDW) (Steer et al., 1990; Kim et al., 2002) takes 2(n-1) messages, while Tree Based Group Diffie Hellman (TGDH) protocol (Kim et al., 2004b) takes 2n messages. Moreover, GKA protocols are more suited for peer-to-peer architecture than SSL/TLS (Amir et al., 2002; Liu & Koenig, 2005).
GKA protocols compute the group key as a function of contributions of participants. The contributions are secrets of the participants. The hash of the group key is further used for symmetric encryption of the messages exchanged among the group members. The contributions of each group member used in computing the group key in a GKA protocol may have a life term as much as the session, while others may be valid across sessions. Ideally, a GKA protocol must ensure that, the computed group key remains a secret when all the long-term secrets used in its computation, are compromised. Such GKA protocols are said to satisfy perfect forward secrecy. Formally, a protocol is said to have perfect forward secrecy if compromise of long-term secrets does not compromise past group keys (Menezes et al., 1996).
Every GKA protocol cannot provide perfect forward secrecy (Boyd & Nieto, 2003). Some of them can only provide partial forward secrecy which allows for the compromise of one or more of the long-term keys of the participants, without compromising the past group key. A protocol provides partial forward secrecy if compromise of long-term keys of one or more specific principals do not compromise the session keys established in previous protocol runs involving those principles (Colin & Anish, 2003).