Towards a Secure Development Environment for Collaborative Applications

Towards a Secure Development Environment for Collaborative Applications

Shyam P. Joy (MVJ College of Engineering, Bengaluru, India) and Priya Chandran (National Institute of Technology, Calicut, India)
Copyright: © 2019 |Pages: 20
DOI: 10.4018/IJeC.2019010101

Abstract

Collaborative applications use the security services offered by secure socket layer / transport layer security (SSL/TLS) to implement authentication and confidentiality. Since SSL/TLS establishes a secure communication between two participants, for a secure network of n (> 2) participants, at least n(n-1)/2 secure communication channels have to be established. Whereas, a group key agreement (GKA) protocol allows the participants to compute a common secret group key as a function of the secrets of participants, and thereby remove the n(n-1)/2 lower bound on the channel requirement. Partial forward secrecy is a property of the GKA protocol which assesses the secrecy of the group key, when the secrets are compromised. Collaborative applications have different security requirements. Hence, the Spread Toolkit offers a set of GKA protocols, so that the designers can choose the most appropriate one. In this article, given a set of GKA protocols, a method is proposed to select the best among them, with respect to partial forward secrecy.
Article Preview
Top

Introduction

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).

Complete Article List

Search this Journal:
Reset
Open Access Articles
Volume 16: 4 Issues (2020): 1 Released, 3 Forthcoming
Volume 15: 4 Issues (2019)
Volume 14: 4 Issues (2018)
Volume 13: 4 Issues (2017)
Volume 12: 4 Issues (2016)
Volume 11: 4 Issues (2015)
Volume 10: 4 Issues (2014)
Volume 9: 4 Issues (2013)
Volume 8: 4 Issues (2012)
Volume 7: 4 Issues (2011)
Volume 6: 4 Issues (2010)
Volume 5: 4 Issues (2009)
Volume 4: 4 Issues (2008)
Volume 3: 4 Issues (2007)
Volume 2: 4 Issues (2006)
Volume 1: 4 Issues (2005)
View Complete Journal Contents Listing