\documentclass[11pt,twoside]{article}\makeatletter

\IfFileExists{xcolor.sty}%
  {\RequirePackage{xcolor}}%
  {\RequirePackage{color}}
\usepackage{colortbl}
\usepackage{wrapfig}
\usepackage{ifxetex}
\ifxetex
  \usepackage{fontspec}
  \usepackage{xunicode}
  \catcode`⃥=\active \def⃥{\textbackslash}
  \catcode`❴=\active \def❴{\{}
  \catcode`❵=\active \def❵{\}}
  \def\textJapanese{\fontspec{Noto Sans CJK JP}}
  \def\textChinese{\fontspec{Noto Sans CJK SC}}
  \def\textKorean{\fontspec{Noto Sans CJK KR}}
  \setmonofont{DejaVu Sans Mono}
  
\else
  \IfFileExists{utf8x.def}%
   {\usepackage[utf8x]{inputenc}
      \PrerenderUnicode{–}
    }%
   {\usepackage[utf8]{inputenc}}
  \usepackage[english]{babel}
  \usepackage[T1]{fontenc}
  \usepackage{float}
  \usepackage[]{ucs}
  \uc@dclc{8421}{default}{\textbackslash }
  \uc@dclc{10100}{default}{\{}
  \uc@dclc{10101}{default}{\}}
  \uc@dclc{8491}{default}{\AA{}}
  \uc@dclc{8239}{default}{\,}
  \uc@dclc{20154}{default}{ }
  \uc@dclc{10148}{default}{>}
  \def\textschwa{\rotatebox{-90}{e}}
  \def\textJapanese{}
  \def\textChinese{}
  \IfFileExists{tipa.sty}{\usepackage{tipa}}{}
\fi
\def\exampleFont{\ttfamily\small}
\DeclareTextSymbol{\textpi}{OML}{25}
\usepackage{relsize}
\RequirePackage{array}
\def\@testpach{\@chclass
 \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else
  \ifnum \@lastchclass=7 5 \else
   \ifnum \@lastchclass=8 \tw@ \else
    \ifnum \@lastchclass=9 \thr@@
   \else \z@
   \ifnum \@lastchclass = 10 \else
   \edef\@nextchar{\expandafter\string\@nextchar}%
   \@chnum
   \if \@nextchar c\z@ \else
    \if \@nextchar l\@ne \else
     \if \@nextchar r\tw@ \else
   \z@ \@chclass
   \if\@nextchar |\@ne \else
    \if \@nextchar !6 \else
     \if \@nextchar @7 \else
      \if \@nextchar (8 \else
       \if \@nextchar )9 \else
  10
  \@chnum
  \if \@nextchar m\thr@@\else
   \if \@nextchar p4 \else
    \if \@nextchar b5 \else
   \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi
   \fi \fi  \fi  \fi  \fi  \fi  \fi \fi \fi \fi \fi \fi}
\gdef\arraybackslash{\let\\=\@arraycr}
\def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}}
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\def\abbr{}
\def\corr{}
\def\expan{}
\def\gap{}
\def\orig{}
\def\reg{}
\def\ref{}
\def\sic{}
\def\persName{}\def\name{}
\def\placeName{}
\def\orgName{}
\def\textcal#1{{\fontspec{Lucida Calligraphy}#1}}
\def\textgothic#1{{\fontspec{Lucida Blackletter}#1}}
\def\textlarge#1{{\large #1}}
\def\textoverbar#1{\ensuremath{\overline{#1}}}
\def\textquoted#1{‘#1’}
\def\textsmall#1{{\small #1}}
\def\textsubscript#1{\@textsubscript{\selectfont#1}}
\def\textxi{\ensuremath{\xi}}
\def\titlem{\itshape}
\newenvironment{biblfree}{}{\ifvmode\par\fi }
\newenvironment{bibl}{}{}
\newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par }
\newenvironment{citbibl}{}{\ifvmode\par\fi }
\newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi }
\newenvironment{docDate}{}{\ifvmode\par\fi }
\newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi }
\newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par }
\newenvironment{msHead}{\vskip 6pt}{\par}
\newenvironment{msItem}{\vskip 6pt}{\par}
\newenvironment{rubric}{}{}
\newenvironment{titlePart}{}{\par }

\newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}}
\newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}}
\newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}}
\newcolumntype{P}[1]{){\arraybackslash}p{#1}}
\newcolumntype{B}[1]{){\arraybackslash}b{#1}}
\newcolumntype{M}[1]{){\arraybackslash}m{#1}}
\definecolor{label}{gray}{0.75}
\def\unusedattribute#1{\sout{\textcolor{label}{#1}}}
\DeclareRobustCommand*{\xref}{\hyper@normalise\xref@}
\def\xref@#1#2{\hyper@linkurl{#2}{#1}}
\begingroup
\catcode`\_=\active
\gdef_#1{\ensuremath{\sb{\mathrm{#1}}}}
\endgroup
\mathcode`\_=\string"8000
\catcode`\_=12\relax

\usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry}
\usepackage{framed}

\definecolor{shadecolor}{gray}{0.95}
\usepackage{longtable}
\usepackage[normalem]{ulem}
\usepackage{fancyvrb}
\usepackage{fancyhdr}
\usepackage{graphicx}
\usepackage{marginnote}

\renewcommand{\@cite}[1]{#1}


\renewcommand*{\marginfont}{\itshape\footnotesize}

\def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif}

  \pagestyle{fancy}

\usepackage[pdftitle={Group Key Management Techniques},
 pdfauthor={}]{hyperref}
\hyperbaseurl{}

	 \paperwidth210mm
	 \paperheight297mm
              
\def\@pnumwidth{1.55em}
\def\@tocrmarg {2.55em}
\def\@dotsep{4.5}
\setcounter{tocdepth}{3}
\clubpenalty=8000
\emergencystretch 3em
\hbadness=4000
\hyphenpenalty=400
\pretolerance=750
\tolerance=2000
\vbadness=4000
\widowpenalty=10000

\renewcommand\section{\@startsection {section}{1}{\z@}%
     {-1.75ex \@plus -0.5ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large\bfseries}}
\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
     {-1.75ex\@plus -0.5ex \@minus- .2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large}}
\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
     {-1.5ex\@plus -0.35ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\large}}
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
     {-1ex \@plus-0.35ex \@minus -0.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\normalsize}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}%
     {1.5ex \@plus1ex \@minus .2ex}%
     {-1em}%
     {\reset@font\normalsize\bfseries}}


\def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt}
 \@tempdima 1.5em \begingroup
 \parindent \z@ \rightskip \@pnumwidth 
 \parfillskip -\@pnumwidth 
 \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par
 \endgroup}
\def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}}
\def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}}
\def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}}
\def\l@subparagraph{\@dottedtocline{5}{10em}{5em}}
\@ifundefined{c@section}{\newcounter{section}}{}
\@ifundefined{c@chapter}{\newcounter{chapter}}{}
\newif\if@mainmatter 
\@mainmattertrue
\def\chaptername{Chapter}
\def\frontmatter{%
  \pagenumbering{roman}
  \def\thechapter{\@roman\c@chapter}
  \def\theHchapter{\roman{chapter}}
  \def\thesection{\@roman\c@section}
  \def\theHsection{\roman{section}}
  \def\@chapapp{}%
}
\def\mainmatter{%
  \cleardoublepage
  \def\thechapter{\@arabic\c@chapter}
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \pagenumbering{arabic}
  \setcounter{secnumdepth}{6}
  \def\@chapapp{\chaptername}%
  \def\theHchapter{\arabic{chapter}}
  \def\thesection{\@arabic\c@section}
  \def\theHsection{\arabic{section}}
}
\def\backmatter{%
  \cleardoublepage
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \setcounter{secnumdepth}{2}
  \def\@chapapp{\appendixname}%
  \def\thechapter{\@Alph\c@chapter}
  \def\theHchapter{\Alph{chapter}}
  \appendix
}
\newenvironment{bibitemlist}[1]{%
   \list{\@biblabel{\@arabic\c@enumiv}}%
       {\settowidth\labelwidth{\@biblabel{#1}}%
        \leftmargin\labelwidth
        \advance\leftmargin\labelsep
        \@openbib@code
        \usecounter{enumiv}%
        \let\p@enumiv\@empty
        \renewcommand\theenumiv{\@arabic\c@enumiv}%
	}%
  \sloppy
  \clubpenalty4000
  \@clubpenalty \clubpenalty
  \widowpenalty4000%
  \sfcode`\.\@m}%
  {\def\@noitemerr
    {\@latex@warning{Empty `bibitemlist' environment}}%
    \endlist}

\def\tableofcontents{\section*{\contentsname}\@starttoc{toc}}
\parskip0pt
\parindent1em
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\newenvironment{reflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemsep}{0pt}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\itshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{sansreflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\itemsep}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\upshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{specHead}[2]%
 {\vspace{20pt}\hrule\vspace{10pt}%
  \phantomsection\label{#1}\markright{#2}%

  \pdfbookmark[2]{#2}{#1}%
  \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}%
  }{}
      \def\TheFullDate{2013-01-15 (revised: 15 January 2013)}
\def\TheID{\makeatother }
\def\TheDate{2013-01-15}
\title{Group Key Management Techniques}
\author{}\makeatletter 
\makeatletter
\newcommand*{\cleartoleftpage}{%
  \clearpage
    \if@twoside
    \ifodd\c@page
      \hbox{}\newpage
      \if@twocolumn
        \hbox{}\newpage
      \fi
    \fi
  \fi
}
\makeatother
\makeatletter
\thispagestyle{empty}
\markright{\@title}\markboth{\@title}{\@author}
\renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@
\belowdisplayskip \abovedisplayskip
\abovedisplayshortskip \z@ plus2\p@
\belowdisplayshortskip 4\p@ plus2\p@ minus2\p@
\def\@listi{\leftmargin\leftmargini
               \topsep 2\p@ plus1\p@ minus1\p@
               \parsep 2\p@ plus\p@ minus\p@
               \itemsep 1pt}
}
\makeatother
\fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm}
\fancyhf{} 
\setlength{\headheight}{14pt}
\fancyhead[LE]{\bfseries\leftmark} 
\fancyhead[RO]{\bfseries\rightmark} 
\fancyfoot[RO]{}
\fancyfoot[CO]{\thepage}
\fancyfoot[LO]{\TheID}
\fancyfoot[LE]{}
\fancyfoot[CE]{\thepage}
\fancyfoot[RE]{\TheID}
\hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true}
\fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}}

\date{}
\usepackage{authblk}

\providecommand{\keywords}[1]
{
\footnotesize
  \textbf{\textit{Index terms---}} #1
}

\usepackage{graphicx,xcolor}
\definecolor{GJBlue}{HTML}{273B81}
\definecolor{GJLightBlue}{HTML}{0A9DD9}
\definecolor{GJMediumGrey}{HTML}{6D6E70}
\definecolor{GJLightGrey}{HTML}{929497} 

\renewenvironment{abstract}{%
   \setlength{\parindent}{0pt}\raggedright
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
   \textcolor{GJBlue}{\large\bfseries\abstractname\space}
}{%   
   \vskip8pt
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
}

\usepackage[absolute,overlay]{textpos}

\makeatother 
      \usepackage{lineno}
      \linenumbers
      
\begin{document}

             \author[1]{Sreeja  Rajesh}

             \author[2]{Mridula R  D}

             \affil[1]{  }

\renewcommand\Authands{ and }

\date{\small \em Received: 6 December 2012 Accepted: 4 January 2013 Published: 15 January 2013}

\maketitle


\begin{abstract}
        


The most widely used technique in a network is Group communication. This helps in the reduction of the bandwidth usage. The major concern in group communication is its security of messages. Group key provides security of messages and hence proper group key management is very important in a group communication. There are various classifications of group key management techniques. A survey of these key management techniques is done in this paper.

\end{abstract}


\keywords{group communication, group key management.}

\begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) 
\textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark}
\end{textblock*}

\begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) 
\textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}}
\end{textblock*}


\let\tabcellsep& 	 	 		 
\section[{Introduction}]{Introduction}\par
he most widely used technique in a network is group communication. Group communication is used in group chat, video /audio conferencing, sending software updates, dividing /sharing work among a group in a corporate environment, multi-party gaming, teleconferencing, telemedicine etc. Security, bandwidth management, speed etc are the various concerns on group communication. If the communication is properly designed and managed, then it will help in the effective usage of band width. The most critical problem that has to be addressed in any group communication is the security of its messages. Group key management is the most important among all its security problems.\par
Multicast is an efficient technology that supports group communication. It helps in better utilization of network resources. Group key needs to be shared among all the members, to ensure security in group communication and also it needs to be maintained secure and fresh. This helps to ensure that only authorized users have group key. Every messages has to be encrypted with group key before transmitting. Thus outsiders or intruders are unable to interpret the messages even though they receive the encrypted message.\par
In any practical application, the network has to be scalable and dynamic. Frequent membership changes might be there in such networks. With every membership change, key management operation has to be performed to ensure that it follows the four main rules in key management backward security (a new member joins the group should not have access to any of its past messages), forward security (a member who have left the group should not have access to its future information packets), collusion freedom (deleted members should not be able to deduce the group keys) and group confidentiality (users that were not part of the group ever in the past should not have access to any key in the multicast group).\par
Proper group key management is critical for secure group communication. Various classifications on group key management techniques are discussed in next section. 
\section[{II.}]{II.} 
\section[{Classifications of Group Key Management Protocols}]{Classifications of Group Key Management Protocols}\par
Based on 'how' the key management operations are performed, the protocols are classified into centralized, de-centralized, and distributed/ contributory. In centralized group key management protocols there is a central group key server, which will be completely responsible for updating and distributing the group keys. Though this method is simple, the existence of single key server generates a bottleneck in the system. In de-centralized group key management systems, the entire group is divided into distinct subgroups and each group has a sub group controller. This sub group controller is responsible for key management operations in sub group. Also at the time of message transmission, this performs message relaying operations and so introduces delays in message transmission. In contributory/ distributed group key management each group member has an equal share to contribute to the group key. This avoids the problem with centralized trust and single point of failure.\par
Depending on 'when' the group key is updated, key management techniques are divided into three: time driven, message driven and membership driven. Group key is updated at regular time intervals, for time driven techniques. This helps to reduce the number of rekeying operations in highly versatile group and also ensure security of the system. In message driven key management protocols, the rekeying happens along with each transmitted message. This helps to ensure the forward and backward security. In membership driven group key management protocols, the group key is updated when a member joins or leaves a group.\par
In the rest of this paper we focus more on the first category of protocols. Some examples of centralized and decentralized group key management protocols are discussed in the next section. In the rest of the sections we concentrate more on various distributed( D D D D D D D D )\par
key management techniques and their performance analysis. 
\section[{III.}]{III.} 
\section[{Centralized Protocols}]{Centralized Protocols}\par
As discussed in the introduction section, there will one central key server in centralized techniques. This key server will be responsible for the whole re-keying process. Each member has a shared key called Key Encryption Key (KEK) with the key server. Thus for an nmember group there will be n-keys and the server maintains a list of group members and keys. Anytime when server generates new group key, it encrypts the new group key with n KEKs and send those packets to corresponding group member. Each member then decrypts the packets using their KEK and retrieves the group key. Thus every member receives the same new group key. Every time when a member joins or leaves a group, the key server generates and distributes new group key to ensure forward and backward security. In case of large dynamic group, it will be a serious burden on key server to generate, encrypt and distribute n keys in short time. Transmission of n encrypted packets greatly increases the bandwidth usage. Some of the centralized key management techniques are described below. 
\section[{a) GKMP}]{a) GKMP}\par
Group Key Management Protocol (GKMP) \hyperref[b0]{[1]} is proposed by Harney and Muckenhirn \hyperref[b2]{[3]} . This is a member driven protocol. The secret key (KEK) is shared between server and each member. In this method the server generates a group key packet (GKP) which contains a group traffic encryption key (GTEK) and a group key encryption key (GKEK). When a new member joins a group, the server generates new GKP and sends it securely to the new member by encrypting it with the KEK established with new member. With existing members it sends the new GKP by encrypting it with old GTEK. When a member leaves, the server generates new GKP and distributes it to the remaining members by encrypting it with KEK shared with each member. This ensures forward and backward security. But this method requires O(n) messages for each re-keying and so this method is not suitable for large dynamic groups. 
\section[{b) Hao-Hua Chu's Protocol}]{b) Hao-Hua Chu's Protocol}\par
This method is proposed by Hao-Hua Chu et al \hyperref[b1]{[2]} . This is a message driven protocol. When a member wants to multicast a message, it generates new TEK and encrypts the message before transmitting. It also sends the TEK to group server encrypting it with the KEK shared between the member and group. Server decrypts the TEK using KEK and then the server unicasts the TEK to remaining group members by encrypting each message with the KEK shared between corresponding member and the server. The members then decrypts the message from server and retrieves the new TEK and then uses this key to decrypt the message from the initial group member. Also with every membership change the key server generates new TEK and distributes it to each member. But this adds the burden on server. 
\section[{c) LHK Protocol}]{c) LHK Protocol}\par
This is a membership driven protocol. The basis of this method \hyperref[b2]{[3]} is the logical hierarchical key tree structure. This tree structure will be maintained in server. Root of the key tree is the group key. Leaf node contains the secret key shared between server and individual user. Intermediate keys are used in the distribution of new group keys. Out of all these keys, each member uses only the keys that lie on the path from that user till the server. So along with each membership change, the keys in the affected path has to be updated and redistributed. When a member joins or leaves a group, the key server generates new group key and intermediate keys in the affected path. Then it securely distributes the keys to the corresponding group members. This method is more scalable compared to other unicast based approaches. For a group of N members with degree of key tree as d, the communication cost will be O(log(dN)). But for the above mentioned unicast approaches it is O(n). Since this is also a centralized method all the disadvantages of centralized methods will be there for this method also. 
\section[{d) Code for Key Calculation (CKC)}]{d) Code for Key Calculation (CKC)}\par
This protocol \hyperref[b3]{[4]} is proposed by M. Hajyvahabzadeh, E. Eidkhani, S. A. Mortazavi and A. Nemaney Pour. This method is also based on logical key hierarchy. Unlike LHK, the intermediate node keys are calculated by individual users. When a member joins or leaves a group, the server sends only group key to the members. By using this key the members calculate other keys using node codes and a one way hash function. The security of this method is based mainly on the one wayness/strength of hash function. By this method it reduces the server overhead and also the message size.\par
There are some more works in this category of group key management protocols like Secure Lock \hyperref[b4]{[5]} , One-way Function Tree \hyperref[b5]{[6]} , Centralized Flat Table Key Management \hyperref[b6]{[7]} etc. 
\section[{IV.}]{IV.} 
\section[{Decentralized Protocols}]{Decentralized Protocols}\par
In decentralized techniques, the entire group is divided into several subgroups. Group key is shared among all the members and each sub group has subgroup key shared among the members of that sub group. There will be one central key server and a subgroup key server for each subgroup. Some examples of this method is described below: a) IOLUS Iolus \hyperref[b7]{[8]} is proposed by S. Mittra. In this method is based on a secure distribution tree, in which all the members are divided into certain sub-groups and these sub groups are arranged hierarchically to form a virtual secure group. When a user wants to join a multicast group, it locates its designated GSA (Group Security Agents) and sends a JOIN securely. On receipt of that request the GSA decides whether to approve or deny the request. When request is approved, it generates a secret key shared between new member and GSA and it communicates the key securely to the new member. GSA then saves all the relevant details about the new member in its secure private data base. It then sends out a GROUP KEY UPDATE message securely to all the existing members. This message contains the new sub group key encrypted with old sub group key and it also securely communicates to the new member the sub group key through a secure channel. b) KRONOS Setia et al \hyperref[b8]{[9]} proposed this scalable approach. This is a time-driven approach and thus frequency of rekeying is independent of the group size and its dynamicity. Kronos is built on the key management framework IGKMP. The working is also similar to IGKMP with a major difference that Kronos is period based rekeying technique.\par
Some other examples of decentralized group key management techniques are Hydra \hyperref[b9]{[10]} , Safecast and MARKS \hyperref[b10]{[11]} . The main drawback with these methods is that, long-term secure channels needs to be established by the key server with all the group members. This increases the cost of introducing new key server. 
\section[{V. Distributed Group Key Management Protocols}]{V. Distributed Group Key Management Protocols}\par
Various distributed key management techniques like (DHSA, EDKAS, TGDH, DGKD), will be discussed in this section. All the four are membership driven protocols and so the major two operations which requires attention is member join and member leave. Member join and leave operations for all the above four techniques are discussed below. 
\section[{a) EDKAS (A Efficient Distributed Key Agreement}]{a) EDKAS (A Efficient Distributed Key Agreement}\par
Scheme using one Way Function Trees)\par
This method \hyperref[b11]{[12]} is based on the concept of distributed one way function trees. This is a period based group rekeying approach. This method takes an assumption that, all the members has already been passed through some admission control methods to make it authentic.\par
In this method, each leaf node is assigned one ID and with root node ID as 0. For any non-leaf node with ID v, its child nodes will have IDs (2v+1) and (2v+2). Each leaf node represents the members. Each member has its own secret key and blinded key (generated by applying one way hash function). The secret key of a node can be calculated from the blinded keys of its child nodes, using a mixing function (K v = f(B K2v+1 , B K2v+2 )). In this way the secret key associated with the root node (known as group key) is shared by all the members. Each member holds its own secret key. It also holds all the blinded keys of nodes that are sibling of the nodes in its key path starting from its associated leaf node up to the root node of the tree. A responsible member set, RM, is also associated with a node, which contains members in the sub tree rooted at its sibling node.\par
Member join operation is explained in Fig 1  {\ref .} U 7 wants to join the group. 6 is the insertion node and U 5 is the sponsor. Blinded key BK 14 of U 7 is send to U 5 . U 5 regenerates its secret key K 13 and its blinded key BK 13 , BK 6 and BK 2. U5 then sends BK 6 to U 4 , BK 2 to U 1 ,U 2 and U 3 . It also sends the structure of distributed one way function tree structure, BK 13 , BK 5 and BK 1 to U 7 . Now at this step all the members have the required information to generate group key K 0 . The member leaving case is similar to that of join, with sibling node as the sponsor and this node is promoted to leaving nodes parent position. Then as discussed above, the sponsor initiates   This is actually a period based method. So the above single node join case is extended to a batch join and so upon each join a temporary key tree structure is generated and kept aside. At the beginning of each period, the temporary tree is merged to the actual tree structure.\par
Since this method is period-based, it decouples the frequency of rekeying from the size and membership dynamics of the group. Therefore, this scheme can easily scale to dynamic collaborative groups. Though this method is theoretically efficient, its practical implementation is expensive. b) TGDH (Tree based group key agreement scheme) \hyperref[b12]{[13]} The concept of hierarchical key tree and multiparty Diffie-Hellman is used in this method. The leaves of the key tree represent users.\par
In this method new node join requires two rounds of operation. A new node broadcasts a join request containing its own blinded key. The blinded key is calculated by applying modular exponentiation operation on its secret key. Upon receipt of this message, each node calculates the insertion position. New node will be inserted to the shallowest point in the tree, so that it does not increase the tree height. Sponsor will be the right most leaf rooted at the insertion node. Each member creates a new intermediate node with new node and sponsor as its children. After this step, all the members will be blocked except sponsor node. The sponsor generates new secret key and calculates its blinded keys. Since it contains the blinded keys of all the other nodes, it can calculate the new group key. Then sponsor broadcasts all the blinded keys. Then all the other members and the new member can calculate the new group key.\par
The leave protocol is similar to that of join. The sponsor is the rightmost leaf node of the sub tree rooted at leaving nods's sibling. All the members update their tree structure by deleting the leaving node and promoting the sibling node of leaving node to the parent position of leaving node. Similar to that of join, the sponsor re-calculates new key and the blinded keys and broadcasts it to other members. The members then can calculate the new group key.\par
Since this protocol requires rekey initiation after each membership change, the cost of modular exponentiation makes the entire system slow. c) DGKD (Distributed Group Key Distribution)  {\ref [14]} The concept of sponsor and co-distributer is used in this method. This method is based on hierarchical tree structure. At join/leave, the sponsor generates new group key and initiates key distribution operation. The sponsor distributes new key with the help of co-distributers. Since this is distributed method all the group members are equally capable and mutually trusted. Depending on the relative location of joining/leaving member, any group member can have the potential sponsor.\par
Every member has a sponsor field which will be updated, if it is along the joining member's path. If new members sponsor id is greater than that of the node's sponsor id, then the sponsor id is replaced with the new node's id. In this method, the co-distributor is responsible for generating the affected intermediate node keys. The sponsor might not be having the keys along other branches, co-distributor helps in distributing keys to other individual nodes.\par
The new node, m n+1 , makes a join request by broadcasting its public key PK to all existing members m 1 ,?,m n . The right most member replies to this node after authenticating it. It decides and broadcasts the insertion location of new node. It then sends the virtual key tree and the list of public keys of other nodes to the new member. Then the sponsor member is decided. The new node's sibling node becomes the sponsor. If there is no sibling node, the new node itself becomes its sponsor. The sponsor node generates and distributes the new keys along its path till root. If requires members update the sponsor id also. In a group like the one shown in Fig 3, m4 generates new keys k' 4-5 , k' 4-7 and k' 0-7 and broadcasts the encrypted keys using codistributers public keys like, \{k 4-7 , k 0-7 \} Pk 7 and \{k 0-7 \} Pk 3 . Co-distributers will decrypt the keys and then decrypt using intermediate node keys and then broadcast the messages to other members. The messages will be \{k 0-7 \} k 0-3 by m 3 and m 7 messages will be \{k 4-7 \} k 6-7 and \{k' 0-7 \} k 4-7 . m 4 also encrypts and sends the key to m 5 : \{k' 4-5 , k' 4-7 , k' 0-7 \} Pk 5 .  This method it uses special authentication methodologies. When m4 transmits new keys to m 3 , the packet contains two components. One is k 0-7 signed using m 4 private key and k 0-7 . So that m3 can decrypt and verify the authenticity of message. m 3 while transmitting the message to other members, it keeps the signed k 0-7 also so that each member can verify that the message originally came from m 4 .\par
There are mainly two drawbacks for this method. All the affected intermediate keys have to be generated by the sponsor member, which will increase the work load of sponsor. Also this method uses asymmetric cryptosystem, which is slower than symmetric system. d) DHSA (Distributed Group Key Management using Hierarchical Approach with Diffie-Hellman and Symmetric Algorithm)  {\ref [16]} As name indicates, this distributed group key management approach uses Diffie-Hellman and symmetric algorithm along with the concept of logical hierarchical key tree. In the key tree structure, the public key of each member is stored in leaves and the intermediate nodes contain the symmetric keys. Two types of codes are used in this method -binary code and decimal code. Binary code is used for identifying the position of a member and decimal code is used in the calculation of intermediate node keys. A list containing public key of all the members and their binary codes (called member list) is shared by all the group members. On each membership change this list will be updated. Root node will contain the group key. Intermediate node key is calculated using the below formulae.\par
A sample hierarchical key tree structure is shown in Fig 5  {\ref .} When a new member wants to join a group he/she sends a join request message to the entire group. The node with no siblings will reply .If there are multiple nodes having no siblings, then the node with smallest parent binary code value replies to the join request. On receipt of this join request each member check if it has the smallest binary code value, if so then that node will be responsible for the key management operations at this join. Consider a group with 7 members and joining node U4 (Fig  {\ref 6}). U4 broadcasts a join request to all the seven members. U3 does not have a sibling node so U3 will act as sponsor for U4. It authenticates U4. Both U3 and U4 exchanges the public keys and establishes a shared key (g X3X4 mod p, where X3 is the private key for U3 and X4 is the private key for U4.) using Diffie-Hellman key agreement scheme. U3 adjusts its position to accommodate U4. U3 also calculates the intermediate node codes and key for new node. The updated binary code for U3and new position and public key for U4 are inserted into member list table. At this moment all the other When a member wants to leave a message, then its sponsor will be its sibling node. All the entries, corresponding to the leaving member will be deleted from the shared member list table and the sibling member adjusts its position upwards in the key tree and this new parent binary code will also be updated in the member list table. At this moment all the other members stops its transmissions for a while and listens to the sponsor (sibling node) for new group key. Now the sponsor node calculates the new group key by applying the symmetric algorithm, one time pad. To reduce the key packet transmission the group key is transmitted in a specific order (as shown in Fig 7). The entire group members are divided into (log n -1) groups (\{U1, U2, U3, U4\}, \{U5, U6\}) and one member from each group is randomly selected (say U1 and U5). The sponsor member then uncast the group key to those nodes by encrypting with their shared keys. Then the representative members (U1 and U5) will multicasts the group key to other members by encrypting the new group key with their common intermediate node's (nodes U 1-4 and U 5-6 here) key. The advantage of this method falls in join operation rekeying. In join operation, the group key is transmitted only once in one message i.e. between new node and sponsor. 
\section[{e) Analysis}]{e) Analysis}\par
We discussed four different distributed key management approaches here. Their performance analysis based on key generation overhead and key communication overhead are discussed here. Key generation overhead is the number of keys generated by the sponsor member. The number of messages required to transmit the group key is key communication overhead.\par
The key generation overhead for DGKD and EDKAS are almost similar. The key generation over head is least and constant for DHSA. Because, for DHSA the sponsor node generates only one group key. All the other nodes calculate the group key by taking hash value of existing.\par
Table  {\ref 1} : Key generation overhead analysis for join and leave operations For join operation, DHSA has communication overhead 1. Because, the sponsor transmits group key only to the new member. There is no group key exchange between existing members and sponsor. Communication overhead is the highest for EDKAS, because sponsor sends the keys individually to each member. At member leave, the communication overhead is the same for DGKD and DHSA. But the message size of DHSA is the least, since it contains only group key.  VI. 
\section[{Conclusion}]{Conclusion}\par
Various classifications of group key management techniques are discussed in this paper. We concentrated more on four different distributed key management techniques such as EDKAS, TGDH, DGKD and DHSA. From the performance analysis of the four methods, it is clear that, for new member join case, DHSA has the least key generation, key encryption and communication overheads and is a constant indicating that DHSA is more scalable than other methods. \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-2.png}
\caption{\label{fig_1}E}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1}\includegraphics[]{image-3.png}
\caption{\label{fig_2}Figure 1 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{2}\includegraphics[]{image-4.png}
\caption{\label{fig_3}Figure 2 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{3}\includegraphics[]{image-5.png}
\caption{\label{fig_4}Figure 3 :E}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{4}\includegraphics[]{image-6.png}
\caption{\label{fig_5}Figure 4 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{56}\includegraphics[]{image-7.png}
\caption{\label{fig_6}Figure 5 :Figure 6 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{7}\includegraphics[]{image-8.png}
\caption{\label{fig_7}Figure 7 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{2}\includegraphics[]{image-9.png}
\caption{\label{fig_8}Table 2 :}\end{figure}
 		 		\backmatter  			  				\begin{bibitemlist}{1}
\bibitem[Mittra (1997)]{b7}\label{b7} 	 		‘A Framework for Scalable Secure Multicasting’.  		 			S Mittra 		.  		 doi: 10/1/1/39/4261.  	 	 		\textit{Proc. of ACM SIGCOMM'97},  				 (of ACM SIGCOMM'97)  		Oct. 1997. p. .  	 
\bibitem[Hajyvahabzadeh et al. (2010)]{b3}\label{b3} 	 		‘A New Group Key Management Protocol using Code for Key Calculation: CKC’.  		 			M Hajyvahabzadeh 		,  		 			E Eidkhani 		,  		 			S A Mortazavi 		,  		 			A Nemaney Pour 		.  	 	 		\textit{Proceedings of IEEE, IEEE Computer Society, the International Conference on Information Science and Applications (ICISA2010)},  				 (IEEE, IEEE Computer Society, the International Conference on Information Science and Applications (ICISA2010)Seoul, Korea)  		Apr. 2010. p. .  	 
\bibitem[Chu et al. (2002)]{b1}\label{b1} 	 		‘A Secure multicast Protocol with Copyright Protection’.  		 			H Chu 		,  		 			L Qiao 		,  		 			K Nahrstedt 		.  	 	 		\textit{ACM SIGCOMM Computer Communications Review}  		April 2002.  	 
\bibitem[Hs. Anahita et al. (2009)]{b13}\label{b13} 	 		‘An Efficient Distributed Group Key Management using Hierarchical Approach with Diffie-Hellman and Symmetric Algorithm’.  		 			Hs. Anahita 		,  		 			Alireza Mortazavi 		,  		 			Toshihiko Nemaney Pour 		,  		 			Kato 		.  		 doi: 10.1109/ IAS.2009.344.  	 	 		\textit{Information Assurance and Security (IAS '09)},  				 (Xian, China)  		FEB 2011. Aug. 2009. p. .  	 
\bibitem[Fan et al. (2005)]{b12}\label{b12} 	 		‘DGKD: Distributed Group Key Distribution with Authentication Capability’.  		 			L Fan 		,  		 			D Xiao-Ping 		,  		 			L Qing-Kuan 		,  		 			; P Yan-Ming 		,  		 			X Adusumilli 		,  		 			Zou 		,  		 			Byrav 		.  		 \xref{http://dx.doi.org/10.1109/ISCC.2000.860720}{10.1109/ISCC.2000.860720}.  	 	 		\textit{Proc. of the 2005 IEEE Workshop on Information Assurance and Security},  				 (of the 2005 IEEE Workshop on Information Assurance and SecurityUnited States Military Academy, West Point, NY)  		Jun. 2005. p. .  	 	 (IEEE 5th International Conference on 14) 
\bibitem[Zhang et al. (2006)]{b11}\label{b11} 	 		‘EDKAS: An Efficient Distributed Key Agreement Scheme Using One Way Function Trees for Dynamic Collaborative Groups’.  		 			J Zhang 		,  		 			V Li 		,  		 			C Chen 		,  		 			P Tao 		,  		 			S Yang 		.  		 \xref{http://dx.doi.org/10.1109/CESA.2006.313506}{10.1109/CESA.2006.313506}.  	 	 		\textit{IMACS Multiconference on CESA}  		Oct. 2006. p. .  	 
\bibitem[Harney and Muckenhirn (1997)]{b0}\label{b0} 	 		\textit{Group Key Management Protocol (GKMP) Architecture},  		 			H Harney 		,  		 			C Muckenhirn 		.  		July 1997, RFC 2093.  	 
\bibitem[Rafaeli and Huchison (2002)]{b9}\label{b9} 	 		‘Hydra: a decentralized group key management’.  		 			\& D Rafaeli 		,  		 			Huchison 		.  	 	 		\textit{Proc. of the 11th IEEE International WETICE: Enterprise Security Workshop},  				 (of the 11th IEEE International WETICE: Enterprise Security Workshop)  		Nov. 2002. p. .  	 
\bibitem[Mcgrew and Sherman]{b5}\label{b5} 	 		‘Key Establishment in Large Dynamic Groups Using One-Way Function Trees’.  		 			D A Mcgrew 		,  		 			A T Sherman 		.  	 	 		\textit{IEEE TRANSACTIONS ON SOFTWARE ENGINEERING}  		 	 
\bibitem[Wallne et al. ()]{b2}\label{b2} 	 		‘Key Management for Multicast: Issues and Architectures’.  		 			D Wallne 		,  		 			E Harder 		,  		 			R Agee 		.  	 	 		\textit{National Security Agency}  		1999. p. C2627.  	 
\bibitem[Setia et al. ()]{b8}\label{b8} 	 		‘Kronos: A scalable Group Re-keying Approach for Secure Multicast’.  		 			S Setia 		,  		 			S Koussih 		,  		 			S Jaodia 		,  		 			E Harder 		.  	 	 		\textit{Proc. of IEEE Symposium on Security and Privacy},  				 (of IEEE Symposium on Security and Privacy)  		2000.  	 
\bibitem[Briscoe (1999)]{b10}\label{b10} 	 		‘Marks: Zero Side Effect Multicast Key Management Using Arbitrarily Revealed Key Sequences’.  		 			B Briscoe 		.  	 	 		\textit{Proc. First International Workshop on Networked Group Communication (NGC)},  				 (First International Workshop on Networked Group Communication (NGC)Pisa, Italy)  		November 1999.  	 
\bibitem[Chiou and Chen (1989)]{b4}\label{b4} 	 		‘Secure broadcast using the secure lock’.  		 			G H Chiou 		,  		 			W T Chen 		.  	 	 		\textit{IEEE Transactions on Software Engineering}  		August 1989. 15  (8)  p. .  	 
\bibitem[Waldvogel et al. (1999)]{b6}\label{b6} 	 		‘The Varsakey Framework: Versatile Group Key management’.  		 			M Waldvogel 		,  		 			G Caronni 		,  		 			D Sun 		,  		 			N Weiler 		,  		 			B Plattner 		.  	 	 		\textit{IEEE Journal on Selected Areas in Communications (Special Issues on Middleware)}  		August 1999. 17  (8)  p. .  	 
\end{bibitemlist}
 			 		 	 
\end{document}
