issn 1751-8709 survey of security services on group communications

258

&

www.ietdl.org

Published in IET Information SecurityReceived on 10th December 2009Revised on 19th March 2010doi: 10.1049/iet-ifs.2009.0261

Special Issue on Multi-Agent & Distributed InformationSecurity

ISSN 1751-8709

Survey of security services on groupcommunicationsP. Sakarindr N. AnsariAdvanced Networking Laboratory, Electrical and Computer Engineering Department, NJIT, University Heights,Newark, NJ 07102, USAE-mail: [email protected]

Abstract: Secure group communication (SGC) has attracted much attention, as group-oriented communicationshave been increasingly facilitating many emerging applications that require packet delivery from one or moresender(s) to multiple receivers. Of all proposals reported, most have focused on addressing the issue of keymanagement to SGC systems. The authors, however, advocate that security services are also needed to satisfydifferent security requirements of various applications. The authors also present here a survey on recentadvances in several security requirements and security services in group communication systems (GCSs),illustrate some outstanding GCSs that deploy these security services, and describe challenges for any futureresearch works in designing a secure GCS.

1 IntroductionGroup communication refers to either point-to-multipoint ormultipoint-to-multipoint communications via someunderlying networking infrastructures. In this article, we donot specify the underlying networking infrastructures tosupport group communication systems (GCSs), since thereare currently no concrete works or standards on thosenetworks to effectively secure group communications.However, we will describe the ongoing activities of the IETFmulticast security charter work group (IETF MSEC WG) tostandardise the multicast security framework and architecturesfor internet protocol (IP)-based multicast networks.

Different security services may be needed to satisfy differentsecurity requirements for different applications. This articlediscusses the following six security requirements in groupcommunications: group authentication, group authorisationand access control, group accountability and non-repudiation, group privacy and anonymity, group messageintegrity and confidentiality and group survivability andavailability. These requirements can be achieved mutuallyor independently by five security services, including groupkey management (GKM), group access control, groupanonymity, group signature and secure routing. The mostfundamental component of security services is the

The Institution of Engineering and Technology 2010

cryptographic material, such as keys. Thus, the performanceof security services inherently relies on the strength andsecurity of the cryptographic material. Many proposalsdeveloped so far for SGCs systems have mainly focused onsolving the issues of key management. However, this articleaims to demonstrate that any SGCs system should offer asmany security services as feasibly possible. The readers arefurther referred to [1] for a survey on SGCs in wirelessnetworks, such as mobile ad hoc networks and wirelesssensor networks, for a broader understanding of SGCs.

The rest of the article is organised as follows. Securityrequirements and services in group communications arediscussed in Section 2. Attributes for evaluating each securityservice and a comparison of these attributes are presented inSection 3. Some outstanding GCSs are then reviewed inSection 4. Some existing group communications-orientednetworks are illustrated in Section 5. Finally, we present thechallenges ahead and summarise the article in Sections 6and 7, respectively.

2 Security requirements andservices for group communicationsThis section describes security requirements for groupcommunications, which are also the basic security

IET Inf. Secur., 2010, Vol. 4, Iss. 4, pp. 258–272doi: 10.1049/iet-ifs.2009.0261

IETdo

www.ietdl.org

requirements for most network communications. Securityservices that meet these requirements are depicted in Fig. 1and are elicited separately later in the subsequent section.

Group authentication: It enables a group member to beauthenticated as unspecified, but a legitimate member, suchthat the sending member can multicast a message on behalfof the group without revealing its identity during theverification process performed by the receiver. Besides userauthentication, message authentication allows any groupmessage to be verified for its authenticity.

Group authorisation and access control: Every member maybe assigned the same or different permissions andrestrictions for accessing group resources. The access-controlling entity can verify a member’s request to accessspecified resources by using several means, such as theaccess control list and access hierarchy.

Group accountability and non-repudiation: All groupoperations should be accountable, implying that any groupoperation performed and resources utilised can be trackedand recorded in order to detect any abusing usages ofresources and operations. A non-repudiation requirementensures that the identity of a member whose activities arein dispute can be fully and precisely identified by thedesignated entity.

Group privacy and anonymity: Fundamentally, groupprivacy and anonymity contradict to group accountabilityand non-repudiation because the privacy of a maliciousgroup member should be stripped off and its identityshould be exposed. There have been some researches tryingto determine the trade-offs between these requirements.

Inf. Secur., 2010, Vol. 4, Iss. 4, pp. 258–272i: 10.1049/iet-ifs.2009.0261

For example, some threshold sharing mechanisms mayallow a number of designated entities to gather informationand to recreate some secret elements used to ultimatelyidentify the wrong-doing members.

Group message integrity and confidentiality: Messageintegrity should be preserved by ensuring that the messagehas not been added, deleted or modified by anyunauthorised entity, either unauthorised members oroutsiders. In GCSs, the integrity is ensured by encrypting agroup message with a single shared key, called a group key.Thus, the message protection mainly relies on thecryptographic strength of the group key. Confidentialityensures that only the authorised can retrieve meaningfuldata from the message.

Group survivability and availability: An attacker may attackmulticast routers and other routing infrastructures or targeta joining operation in order to cut off some or all groupmembers or to disrupt group communications, thus causingservice unavailability. To achieve group survivability, therouting protocol should ensure that any member can still beconnected even under attacks. Furthermore, there should besome preventive mechanisms to support group survivabilityby rediscovering connections in the events of link or nodefailures.

3 Performance attributes toevaluate secure GCSsIn order to evaluate and compare different SGC systems, oneneeds to construct evaluation attributes to fairly analyse anddetermine the performance and security analysis of each

Figure 1 Security services correspond to security requirements

259

& The Institution of Engineering and Technology 2010

260

&

www.ietdl.org

SGC system. In this article, evaluation attributes are groupedinto two types: fundamental attributes used to evaluatemechanisms in providing one or more security services toGCSs and specific attributes used as additional propertiescorresponding to those supported security services.

3.1 Fundamental attributes

The fundamental attributes for a SGC system may includethe following as depicted in Fig. 2.

Types of group management: The group may be establishedand managed by three approaches: centralised (with acentral authority), partially distributed (with a group ofdesignated controllers) and fully distributed (without anyexplicitly designated controller). The group controller mayperform the group initiation and termination, themembership admission, the group material generation andthe distribution of some controlling messages. The groupcontroller may also act as a key server, if given the capacity.

Overheads: In general, three types of overheads are incurredby all network operations: storage, communications andprocessing. For storage overheads, a group controller and agroup member may require different amounts of memoryto store group information such as session and group keys,list of group members, cryptography materials and otherservice-related materials. For communications overheads,the characteristics of group communications likely incuradditional communications messages. For example,dynamic group membership changes cause members toreorganise group operations (i.e. sending joining or leavingnotifications, selecting new group controllers) and to rekeyall related keys to ensure key secrecy (i.e. distributions ofnew keys). To process overheads, each group operationrequires computation which can be measured in terms ofthe number of processing steps (iterations), processing


duration and complexity bound. The key generation anddistribution, rekeying and message encryption/decryption/digestion/signing processes are computationally expensive.

Scalability: The performance should not be degradeddrastically as the group size increases; it should be linearwith the group size. In addition, the scalability may beincreased in many scenarios: for example, a group ismanaged in a distributed approach (because of easiness toexpand the group).

Dynamic membership: GCSs should be able to handle amembership change (i.e. any individual member leaves orjoins the group at any time) without significant systemperformance degradation. Some systems may treat groupsmerging and partitioning the same way as a bulk ofindividual membership changes, and may thus suffer fromdegraded performance when handling a large group ofmembership changes. Different networks may handle thegroup membership changes differently. For example,wireless ad hoc networks may observe higher mobility ofmembers (more frequent membership changes), whereasmulticast wired networks may expect less or even fixedmobility (less frequent membership changes).

Trust relationship: Some systems require a trusted thirdparty such as the certificate-issuing authority and the keyserver, which can make the trusted third entity a point ofattack. Some systems assume trust relations among groupcontrollers or between a group controller and members, butignore the need for additional security mechanisms toprotect trust operations such as trust establishment andupdating trust relations.

Resilience: It is necessary to include a threat model and thesecurity analysis in designing and evaluating a SGC system.To analyse the threat model and security analysis, both

Figure 2 Fundamental attributes for evaluating performance and security in a SGC system


IETdo

www.ietdl.org

network-based attacks and service-related attacks areconsidered. The network-based attacks are general attacksthat explore the vulnerabilities of a network. The service-related attacks specifically target the security servicemechanisms originally deployed to satisfy some securityrequirements. For example, a group signature satisfiesprivacy and authentication, but unintentionally, leaves theSGC system with new vulnerabilities, such as weaknessesin the signature algorithm or erroneous source codes ingenerating the signatures. The security analysis may be ableto detect and prevent such vulnerabilities.

Control channels: Some systems require offlinecommunications channels, such as using a telephone orcontrol channels. The performance and security analysisshould measure online impacts of the offline channel.

3.2 Service-specified attributes

Additional properties or attributes for specific securityservices are discussed separately as depicted in Fig. 3.

3.2.1 Group key management: A GKM schemeshould exhibit the following six additional properties:


Types of key management: In a centralised key management,a key manager generates the keys, distributes them toassociated members and maintains all the keys. Thesecurity of key generation is strong, but the key managercarries most of the workloads and becomes the attacktarget. In a partially distributed key management scheme, aset of key managers generate the keys and distribute themto all group members. Thus, each key manager has areduced workload. Each key manager may still become theattack target, and the security of key generation isweakened. In a contributory key management scheme, eachmember randomly selects its contribution, exchanges withina group and generates a shared group key without a centralkey server/manager. The security of key selection andgeneration is low, but there is no need for a key manager.All members equally share the workloads.

Key secrecies: There are three aspects of key secrecies:forward secrecy, backward secrecy and perfect forwardsecrecy. The forward secrecy ensures that a new joiningmember cannot use the new key to decrypt all messageswhich have been encrypted with the previous key(s). Thebackward secrecy ensures that a leaving member cannot usethe previous key(s) to decrypt all messages encrypted with

Figure 3 Service-specified attributes for evaluating security services in a SGC system

261


26

&

www.ietdl.org

the new key. The perfect forward secrecy ensures that acompromise of a long-term key seed that generates thepresent short-term key(s) cannot deprive the secrecy ofother previous short-term keys which have been generatedby the compromised long-term key.

Key independence: A disclosure of a subset of session keyscannot deprive the secrecy of other subsets of session keyswhich have been generated by the same long-term key seed.

Key serialisation: The key materials are selected and thegroup key is generated by members in an ordered sequence.An attack on any participating member disrupts the wholeprocess. Instead, some schemes may construct the key byother means; that is, broadcasting the key materials orestablishing a key tree, at the expense of overheads.

Rekeying: There are several factors in evaluating rekeying asfollows: (i) The number of rekey messages – the number ofdistributed and received messages per member or per keymanager may be different; (ii) The length of rekey messages –some protocols aggregate multiple rekey messages into asingle message, which in return increases the consumedbandwidth for one transmission. Thus, the performanceanalysis should also determine the bandwidth consumptionper message in addition to the number of transmittedmessages; (iii) The rekeying process – the rekeyingoperation should reduce or optimise the computation andtime complexity of the rekeying operation with respect to agroup size; (iv) Triggering conditions – there are threescenarios: first (rekeying based on membership changes),keys associated with the membership changes must berekeyed to ensure the key secrecy for the remainingmembers; second (periodic rekeying), the rekeying operationis invoked periodically to prevent keys from beingcompromised over time and third (specified rekeying), asystem enables the rekeying operation for specified incidents,such as upon detection of attacks or violations.

3.2.2 Group access control: The following twoadditional properties related to a group access controlscheme are considered:

Access control: The group resources and group messagesshould be accessible only to authorised members.

Dynamic access control: The system enables its members todynamically change their request to access resources.Consequently, the system must be able to update accesspermissions and restrictions with additional mechanismswhen a member’s access privilege changes.

3.2.3 Group signature: Three additional propertiesrelated to a group non-repudiation scheme are considered:

Message signature: A system requires messages to be signedwith a membership certificate to identify the originator(signer) of the message.

2The Institution of Engineering and Technology 2010

Timestamp or sequence number: Timestamps and/orsequence numbers can be used to limit the validation of acertificate or message signature in order to prevent replayattacks.

Revocation of certificates: The expired certificate or misuse of acertificate should be revoked by the issuer, and publiclyannounced in the revocation list. Some systems may keepthe expired certificates for future verification at the expenseof additional storage overhead.

Characteristics of a signature: There are four basicrequirements of a digital signature: (i) unforgeable – agroup of colluded attackers cannot generate a groupsignature identical to that generated by a legitimatemember; (ii) non-allegeable – a group of colluded attackerscannot generate a group signature by which a groupcontroller falsely identifies a legitimate member as anattacker; (iii) linkable – a group of colluded attackerscannot generate a valid group signature by which a groupcontroller cannot identify the identity of any of theseattackers; and (iv) secretive –a member’s secret elementscan neither be retrieved from a group signature nor fromany part of the signature.

3.2.4 Group anonymity: Two additional propertiesrelated to the group privacy and anonymity scheme areconsidered:

Unlinkability of anonymous communications: There are threeanonymities: sender anonymity – a sender shall not belinked to its sent message to prevent attackers fromlearning of the message’s origin; receiver anonymity – areceiver shall not be linked to the received message toprevent attackers from learning of the message’s destinationand sender–receiver anonymity – the sender and receivershall not be linked together, and they are also relativelyanonymous to each other.

Types of management: There are two types of management:centralised management – a system relays messagesthrough a trusted anonymous entity to hide identities ofthe sender and receiver and distributed management – asystem relays messages through a group of anonymousentities or hides the identities by other means such asencapsulating messages and coding with the XOR operation.

3.2.5 Secure routing: Two additional properties relatedto a secure routing scheme are considered:

Management: A system can establish and maintain routing-related information in a centralised or distributed manner.

Prevention: Updating routing information must berestricted to authorised members. A new routing pathshould be tested to prevent routing black hole and loopholes.Any request to join/add/update the routing table and other


IETdo

www.ietdl.org

routing-related information should be authenticated andauthorised.

We shall next compare existing outstanding secure GCSsin terms of the properties discussed above. The results aresummarised in Tables 1 and 2, in which shaded boxes inTable 2 indicate that the security services are irrelevant tothe systems and are thus excluded from consideration.

4 Security services for groupcommunicationsThis section discusses essential security services that meetsecurity requirements mentioned before. Many conceptsand existing solutions have been proposed to provide suchservices, but only a few promising concepts and solutionsare highlighted here owing to the space limit.

4.1 Group key management

Any GKM scheme should exhibit the following properties:the key generation and rekeying should be provably secure;an imitation of the group key should be mathematicallyinfeasible or computationally difficult; the group key issecurely distributed and only the legitimate users can obtaina valid group key and a revocation of the group key upon amembership change should be immediately notified.

Banerjee and Bhattacharjee [2] proposed a managementscheme based on a clustering protocol and a hierarchy ofkeys. All members are divided into several clusters in alayer. In each cluster, a cluster header will be selected andbe a cluster member of the upper layer. This process isrepeated until there is only one cluster member in the toplayer. The clustering protocol is deployed to cluster themembers in each layer such that when a membershipchanges, only one cluster in each layer requires itsassociated keys to be updated. It was demonstrated that, foran individual membership change, the overheads incurredby group members are constant with respect to the groupsize. In addition, for a bulk membership change, theprocessing and communication overheads at the key serverare logarithmic with respect to the group size.

Wong et al. [3] introduced three-key graph-based rekeyingapproaches (user-, key- and group-oriented) to mitigate thescalability problem. In events of membership changes, threerekeying approaches operate as follows: for user-orientedrekeying, the key server generates new keys for eachaffected member and encrypts them with keys previouslyheld by that member; for key-oriented rekeying, the newkeys are encrypted individually with previous keys at thesame key nodes of the key tree and multicast in multiplerekey messages and for group-oriented rekeying, it issimilar to the key-oriented rekeying except that all newkeys are put together in a single rekey message. Thesimulation results demonstrated that the complexities ofrekeying overheads of the three approaches are linear with


the logarithm of the group size. In addition, the group-oriented approach performs the best from the perspective ofthe key server, whereas the user-oriented approach has thebest performance from the perspective of the group member.

Amir et al. [4] secured group communications with asecure service from the proposed robust and contributorykey agreement protocol and the virtual synchronysemantics. The proposed protocol enhances the groupDiffie–Hellman key agreement in two ways: first, it canmitigate the member serialisation problem that requires thegroup key to be constructed or rekeyed in a serial ordering;second, it incorporates a membership protocol such that itis aware of any membership changes during the keygeneration and rekeying processes. In addition, theproposed protocol can effectively handle events of membersjoining and leaving within a very short time interval. Theirsimulated system, called secure spread, demonstrated thereduction of time used to successfully establish a securegroup and generate a group key after a membership waschanged.

4.2 Group access control

In group-oriented networks, group members can be assignedwith multiple access privileges. The data stream can beaccessed with different access privileges such that onlymembers who have an appropriate privilege can access tocorresponding portions of contents of the data stream (orsome data streams of the aggregated data stream). This isreferred to as multiple access privilege. In addition, someGCSs can support dynamic access control.

Sun and Liu [5] proposed multi-group (MG) keymanagement scheme to construct the logical key graph byintegrating key trees of all members. Each authorisedmember holds a set of keys associated with the nodes fromthe leaf node to the root node in the key graph. The accessprivilege for each member is determined by the possessedset of keys. The scheme can provide forward and backwardsecrecies when a member changes its access privileges (orleaves the group) because the set of keys and resourcesassociated with that member are reassigned (or withdrawn).It was shown that overheads caused by the rekeyingincidents are greatly reduced. In addition, the scalabilityand complexity of the scheme is improved.

Zhang and Wang [6] proposed a hierarchical access control(HAC) key management scheme, where a key server maintainsthe description of relations of memberships and resources inthe form of unified hierarchy. Instead of classifying memberswith different resource requirements into multiple groups asof the conventional multi-group (MG) key managementscheme, the HAC scheme constructs a membership-groupsub-graph and a resource-group sub-graph, and combinesthem into a single unified logical key graph that determineswhich resource the specified member can access. Thesimulation results have demonstrated that, with the HAC

263


26

&

www.ietdl.org

Table 1 Comparison of secure GCSs along with fundamental performance properties

Services Group key management Group access control Group signature

Evaluation properties Ref [3] Ref [4] Ref [5] Ref [6] Ref [7] Ref [8] Ref [9] Ref [10]

type of groupmanagement

partiallydistributed (anauthentication

and accesscontrol server +cluster leaders)

distributed(subgroups)

distributed(logicalservers)

centralised(with a keydistributioncenter) +

contributoryscenarios

any (with akey server)

centralised(a groupmanager)

centralised(with ashadow

distributioncentre)

centralised(a groupmanager)

reduction of storageoverheads

yes yes no yes yes no only onesecret kept

at eachmember

no

reduction ofcommunicationoverheads

yes yes yes N/A N/A no no no

reduction ofprocessing overheads

yes yes yes yes (forrekeying)

yes (forrekeying)

no no no

performance is steadywith a group size

yes yes yes yes possible butnot clearly

stated

N/A N/A N/A

scalability supported yes yes yes yes possible butnot clearly

stated

no no no

Dynamicmember-ship

individualchange

yes yes yes yes yes yes no no

a bulk ofchanges

yes no yes no no no no no

trust among groupentities required

yes (amongmembers)

yes (for keyserver(s))

no no no no no yes (for theverifier(s))

message integritymethods

N/A session key group key session keyand key-

encryptedkeys

dataencryption

keys (resourceand

membership-group keys)

N/A N/A N/A

Services Anonymity Secure multicast routing

Evaluation properties Ref [11] Ref [12] Ref [13] Ref [14]

type of groupmanagement

centralised (a group authorityand a group controller)

fully distributed partially distributed(sub-branch corerouters, and an

authentication service)

partially distributed(domain core routers + a

center router)

reduction of storageoverheads

yes no no no

reduction ofcommunicationoverheads

yes yes no no

reduction ofprocessing overheads

yes yes no no

performance is steadywith a group size

no yes no no (for edge/ core/ centerrouters)

scalability supported yes unlikely but not clearly stated yes (for key generationand management)

no (forrekeying)

yes

Continued

4 IET Inf. Secur., 2010, Vol. 4, Iss. 4, pp. 258–272The Institution of Engineering and Technology 2010 doi: 10.1049/iet-ifs.2009.0261

IEd

www.ietdl.org

Table 1 Continued

Services Anonymity Secure multicast routing

Evaluation properties Ref [11] Ref [12] Ref [13] Ref [14]

Dynamicmember-ship

individualchange

N/A N/A yes yes

a bulk ofchanges

no no no no

trust among groupentities required

no no yes no

message integritymethods

message encryption andsession keys

pseudorandom sequences random encryptionkeys + branch keys

hash of encryptedmessages + domain control

key + group datakey + sender specific keys

To

scheme, the storage and rekeying overheads at every memberand the key server can be significantly reduced by at least20% as compared with those of the MG scheme.

4.3 Group signature

The group signature is used to authenticate the sourcewhether the message is sent from the signer who is alegitimate, but unidentified, group member and toauthenticate the message whether it has been altered duringtransmission. In case of a dispute, the third trusted party orthe group controller can identify the actual signer of thesigned message.

Chen et al. [7] proposed a scheme that combines aprovably secure scheme and identification (ID)-basedscheme to provide authentication, anonymity and non-repudiation. Unlike the original ID-based signaturescheme, the proposed scheme generates a member’s publickey from its identity information (e.g. e-mail address,name, network address, etc.). As an advantage to thescheme, the group controller uses the smaller ID ratherthan the larger public key, as used by a public keyinfrastructure-based scheme, to generate a member’s privatekey in order to reduce the storage overhead. A membersigns the message with its private key on behalf of the group.

Lee [8] proposed a threshold signature scheme withmultiple signing policies. The scheme enables the groupsignature-generating functionality to be shared among atleast any t members out of n members, so that a thresholdvalue of the signature is t. Any t 2 1 or lower memberscannot generate or reconstruct the same signature with thethreshold value of t. This proposed scheme demonstratedthat each user stores only a group secret key (called a publicshadow), thereby significantly reducing the storage andcommunication overheads for group signature generation.

Ateniese et al. [9] proposed a provably secure groupsignature scheme and a modified identity escrow scheme.The proposed scheme enables a group member toauthenticate the new comers by using the zero knowledge


proof method before issuing a membership certificate. Inaddition, the scheme allows group members to performgroup signing by showing the proof of knowledge of theircertificates. Using a modified identity escrow scheme, thereceiver is not aware of the signer’s identity but isguaranteed by the third trusted verifier that the signer’ssignature can be opened and linked to the signer. Thus, asigner does not expose its secret to the verifier during theverification process. Furthermore, the scheme is provablycoalition-resistant against an adaptive attacker who canadaptively run the joining process as multiple new membersin order to obtain sufficient information to generate validgroup certificates.

4.4 Group anonymity

Many articles have proposed solutions to provide anonymityin unicast communications, but these solutions may not besuitable for group communications in the following ways:(i) a node has to hide from multiple nodes; (ii) groupmembership management becomes challenging forproviding anonymity; (iii) an extremely complicated GKMis needed to anonymously generate, distribute and managemultiple keys, including the group key and other keys-protected keys, so that anonymity in group communicationscan be possibly preserved.

The following schemes attempt to provide anonymity ingroup communications: Xiao et al. [10] proposed themutual anonymous multicast protocol that allowscommunications among three types of nodes: anonymousmember (AM), non-anonymous member (NM) andmiddle outsider (MO) nodes. Initially, a set of NM nodesform the anonymous multicast tree. Then, an AM nodesets up connections with three possible choices: NMnodes on the tree that can still accommodate connections –called unsaturated NM nodes, unsaturated AM nodes onthe tree and MO nodes that are invited to join the tree.The protocol combines the well-known reverse onionprotocol [11] and crowd protocol [12] in the followingways. Each AM node creates a remailer as a list ofintermediate nodes whose identities are encrypted with

265


26

&

www.ietdl.org

Table 2 Comparison of secure GCSs along with additional performance properties

Evaluationproperties

Group key management-based systems Group access control-basedsystems

Group signature-based systems

Ref [3] Ref [4] Ref [5] Ref [6] Ref [7] Ref [8] Ref [9] Ref [10]

keymanagement

structure of keys hierarchicalcluster-based

key graph typical groupkey

agreement

tree-basedMulti-group

key graph

logical keygraph

type ofcryptosystemused

DL RSA DL and RSA N/A N/A

forward secrecy yes yes yes yes yes

backwardsecrecy

yes yes yes yes yes

perfect forwardsecrecy

N/A N/A yes N/A N/A

key serialisation no no no no no

keyindependence

yes yes yes N/A N/A

rekeying membershipchanged

membershipchanged

membershipchanged

membershipand access

privilegechanged, and

periodic

membershipchanged

keymanagement

centralised (a keyserver)

centralised (akey server)

contributory centralised (akey

distributioncentre)

centralised (akey server)

authentication

userauthentication

yes (auth.list + credential.)

yes no yes(membershipcert. + zero-knowledge

proof)

no yes(membershipcert. + zero-knowledge

proof)

messageauthentication

no yes yes yes (groupsigning keys)

yes (groupsecretkeys)

N/A

access control

authorisation/access control

yes yes (accesscontrol list)

no yes(hierarchical

accesscontrol)

yes(hierarchical

accesscontrol)

dynamic accesscontrol

no no no yes no

signature

messagesignature

no messagedigest

messagesignature

ID-basedgroup

signature

threshold-basedgroup

signature

groupsignature

non-repudiation N/A unforgeableand linkable

unforgeableand linkable

unforgeable,non-

allegeable,and linkable

unforgeable,non-

allegeable,and linkable

unforgeable,non-

allegeable,and

linkable

Continued

6 IET Inf. Secur., 2010, Vol. 4, Iss. 4, pp. 258–272The Institution of Engineering and Technology 2010 doi: 10.1049/iet-ifs.2009.0261

IETdo

www.ietdl.org

Table 2 Continued


Group key management-based systems Group access control-basedsystems

Group signature-based systems

Ref [3] Ref [4] Ref [5] Ref [6] Ref [7] Ref [8] Ref [9] Ref [10]

anonymity

anonymitysupported

yes yes yes

unlinkability ofanonymouscommunications

sender sender sender

type ofanonymitymanagement

N/A N/A N/A

secure routing

management

prevention


Anonymity-based systems Secure multicast routing-based systems

Ref [11] Ref [12] Ref [13] Ref [14]

keymanagement

Structure of keys hierarchical branch-based tree hierarchical domain-based tree

type ofcryptosystemused

N/A RSA

forward secrecy yes yes

backwardsecrecy

yes yes

perfect forwardsecrecy

N/A N/A

key serialisation no no

keyindependence

N/A N/A

rekeying membership changed andperiodically changed

membership changed

keymanagement

partially distributed (sub-branch routers)

partially distributed (domainrouters)

authentication

userauthentication

Possible but not clearly stated no yes (certificate) yes

messageauthentication

yes no yes yes

access control

authorisation/access control

yes (access control cert. andlist + access control anonymiser)

no yes (access control list.) yes (an authorisationservice + access control list)

dynamic accesscontrol

no no yes no

signature

messagesignature

messages signature no digital signature no

Continued

Inf. Secur., 2010, Vol. 4, Iss. 4, pp. 258–272 267i: 10.1049/iet-ifs.2009.0261 & The Institution of Engineering and Technology 2010

26

&

www.ietdl.org

Table 2 Continued


Anonymity-based systems Secure multicast routing-based systems

Ref [11] Ref [12] Ref [13] Ref [14]

non-repudiation N/A N/A N/A N/A

anonymity

anonymitysupported

yes yes no no

unlinkability ofanonymouscommunications

sender-receiver sender, receiver and sender-receiver

type ofanonymitymanagement

centralised (anonymisers) distributed

secure routing

management partially distributed(sub-branches)

partially distributed (domains)

prevention unauthorised modificationprevention

unauthorised modificationprevention

N/A stands for ‘not applicable’ or ‘no available information’If a system design does not offer some security services, the corresponding table cells of these security services are emptiedand shaded

8

their associated public keys in layers, similar to layers of anonion. The NM nodes on the tree keep all remailersassociated with a particular AM node. The packetoriginated from or destined to an AM node will beforwarded through the remailer associated with this AMnode. For the AM-to-NM connections, an intermediatenode chooses either to deliver the packet directly to theNM node or randomly forward the packet to another node,according to the predefined forwarding probability. For theAM-to-AM connections (mutual anonymous connections),the AM 1 node will select one of its middle nodes toestablish a connection with one of AM 2’s middle nodes.

Grosch [13] provided both sender and receiver anonymityto multicast traffics through both dedicated and sharedanonymisers. The anonymiser receives messages from asender, processes the messages (for the purposes ofintegrity, confidentiality and anonymity) and forwards themas its own messages to receivers via a secured multicastchannel. The scheme determines the location of theanonymiser on the multicast tree in such a way that thenetwork loads and average distance (i.e. the average numberof links) from the anonymiser to all receivers can beoptimised. To find such an optimal location, the schemefirst selects a candidate node in the undirected graph.Then, it assigns the weight of each link on the graph as thenumber of all receivers that are connected downstream.Based on the link weights, the shortest paths from thecandidate node to all receiving nodes are determined, andthe multicast tree is formed. To reduce the network load,all nodes can be grouped in a smaller group size, althoughfewer nodes can then be selected as anonymisers. Given thespecified pair of the candidate node and group size value,


the scheme calculates the overall weight for this multicasttree as the sum, over all links, of the probability that eachlink is used. Repeat the process for all combination ofcandidate nodes and group size values. The node with thelowest overall weight is selected as the anonymiser.

Dolev and Ostrovsky [14] proposed the XOR tree-basedscheme to provide efficient anonymous multicast (eithersender anonymity, receiver anonymity or both) and toprotect the multicast network against the traffic analysis andcollusion attacks. The idea is that a forwarding memberperforms an XOR operation bit-by-bit on data streamforwarded to its predecessor with pseudo-random stream inorder to hide the true bits of the data stream. It isanalytically demonstrated that the communication overheadon each link and the computational overhead incurred at anymember on the forwarding path is greatly reduced.

4.5 Secure routing

In this service, the IP-based multicast network is mainlyconsidered. A single packet is delivered through multicastrouters to a large group of receivers. If an attacker can joina multicast group and launches either passive or activeattacks, these attacks would effectively incur high overheadsand network-wide failures and unavailability.

Unfortunately, many GCSs assume that the group routingstructure (e.g. multicast tree) is secure and unauthorised usersneither send nor receive the messages. However, a few securegroup routing schemes have been proposed to safeguard therouting infrastructures physically and logically. Several


IETdo

www.ietdl.org

SGC-based networks illustrate the implementation ofsecurity services in various group communications.

Shields and Aceves [15] proposed a keyed hierarchicalmulticast routing protocol (KHIP) that allows onlyauthorised and trusted members with proper privileges toaccess and update the multicast tree and preventsunauthorised users from joining or expanding the multicasttree. Data messages are protected with random encryptionkeys and branch keys, but there is no shared group key forthe entire multicast group. A member who serves as thecore for each branch reprocesses all passing messages attheir origin before forwarding to the parent and childrenbranches of the multicast tree. It was demonstrated that aminimal number of nonces are added to the headers of dataand routing updated messages to prevent the replay attackand the forgery attack. Furthermore, the impact of denial-of-service attacks undertaken by untrusted members (e.g.untrusted multicast routers) could be minimised.

Shim [16] introduced a secure multicast routing protocolbased on intra-domain and inter-domain routing protocols.The network is divided into domains, each managed by acore router, and all controlling messages associated with thedomain are encrypted with a domain control key. Alldomains are managed by the centre router in a hierarchicaltree manner. A non-member user is only able to send datamessages encrypted with its corresponding sender specifickey (SSK). All members use the shared group data key toencrypt and decrypt data messages sent by members, anduse the SSK to decrypt data messages sent by an associatednon-member user. The protocol is claimed to achievescalability and prevent several active and passive attacks,including unauthorised joining the routing multicast tree.

5 Group communication-orientednetworksThis section reviews some SGC frameworks which have beenimplemented on several existing networks, including multi-agent systems (MASs), personal area networks (PANs) andIP multicast networks.

5.1 Multi-agent system

An MAS fundamentally consists of three components:agents, hosts and controller/coordinators. An agent can bea software code that runs on a host, operates in anautonomous manner, interacts with other agents andconnects to one or multiple agent coordinators. An MAS isagent-based, implying that security services must beprovided to end-to-end communications at the agent level,not at the host level. Keys and other group-related resourceand information are usually stored in agents and protectedfrom hosts on which these agents operate.

Li and Lan [17] proposed a mobile agent system operatingthrough a secure and high performance agent-based multicast


network. The proposed solution adopts the concept ofmulticast by supporting communications between an agentcoordinator and an agent on a host or communicationsamong agents at the agent level. The security solution usestwo keys: a group key and a secret key. The centralisedagent coordinator generates a secret key that is thencryptographically separated into secret key shadows, eachshared individually by an agent. The key management isbased on the concept of (k, n) threshold secrecy, by whichthe secret is shared among n agents and, to reveal thesecret, the shares must be obtained from at least k agents.The secret key shadows are used to derive the groupkey. The group key and secret key shadows are protectedfrom the resided hosts. The coordinator can evict any agentand take charge of rekeying by excluding the secret keyshadow of the evicted agent from the original secret key.The existing agents can correctly compute the new groupkey while the evicted agent cannot.

Pros: Key secrecies are provided. Security and performanceanalysis of the proposed solutions are shown. The schemewas claimed to have reduced communications andprocessing overheads without solid proofs.

Cons: The scheme requires a priori embedment of thesecret key shadow in the agent, and the scheme makes aweak assumption that an agent is well protected viacryptographic means and that each agent is trusted.

5.2 Personal area network

PAN communication is enabled by either wired technologies(i.e. USB and Firewire), wireless technologies (i.e. Bluetooth,Infrared and Wi-Fi) or a combination of both. In PANs,devices can communicate to each other and form thenetwork around the person. Data can be passed throughfrom one device to others or conveyed to other networks.Data can be encrypted by using a group key that is sharedby all devices. The number of nodes is generally not largeand most devices are operated by one person. With suchcharacteristics, the central authority can be most effective inkey management, and membership changes may not befrequent.

Shin et al. [18] proposed a framework consisting of keyexchanged protocols against a compromised insider device:leakage-resilient and forward-secure authenticated keyexchanges 1 and 2 (LRFS-AKE1 and LRFS-AKE2). Theproposed protocols require a centralised server, whichexchanges two long-term secret elements with a user: onefor authentication (called the verification data) and anotherfor securing its pair-wise communication (called thesymmetric key). The group key generation and distributionoccur within three phases. In the first phase, followingLRFS-AKE1, the server and a user verify themselves byusing the verification data, that is, a combination of arandom number and the user’s password, along withthe symmetric key and the list of devices. Subsequently, a

269


27

&

www.ietdl.org

pair-wise session key is generated individually for each device.In the second phase, following LRFS-AKE2, each deviceperforms a contributory group key generation in an orderlymanner, assisted by the server but without user interaction.The session key is used to secure the distribution of itscontributed key portion. In the third phase, the same groupsession key is generated independently by each user.

Pros: Threat models are discussed; proposed protocols aresuitable for PANs.

Cons: No rekeying mechanism exists; group key secrecy isnot fully guaranteed due to the same password being usedby the same user; a symmetric key is assumed to be doneoffline; additional user password is required; a centralisedserver is ignorantly assumed as trusted; and no membershipchange protocol exists.

5.3 Multicast security in IP multicastnetworks

Since 2000, the IETF MSEC working group aims tostandardise SGC protocols over Internets with at leastthree security objectives [19]: first, providing fundamentalsecurity services, such as GKM, access control, groupauthorisation, group policy management and user andmessage authentication; second, extending operability fromcentralised networks to distributed networks where multipletrusted entities are deployed throughout networks andthird, defending against network-based attacks.

Chaddoud and Varadharajan [20] proposed a securesource-specific multicast (S-SSM) communicationsarchitecture that offers two security services: access controland data integrity for commercial content delivery. Itoperates by using the protocol independent multicast-SSM(PIM-SSM) routers which form the backbone of thenetwork. The PIM-SSM router is the router that providessecurity, especially access control, and Internet groupmanagement protocol (IGMP) version 3-based routing forSSM traffic. S-SSM divides the whole service area intodomains and has two layers of controls: the domain-widelevel via local controllers and the network-wide level viaa global controller. The global controller and contentdistribution server are connected directly to the PIM-SSMrouters. The global controller manages data distribution,authorises user access, generates channel keys andauthorises rekeying. To manage subscribers, the IGMPversion 3 is deployed in some PIM-SSM routers, which arelocated outside the backbone and connect directly tosubscribers. In the IGMPv3/PIM-SMM routers, the localcontroller functionality is added to authenticate newsubscribers, to distribute a channel key to subscribers, andto periodically rekey the channel key as authorised by thegroup controller.

Pros: Computation overhead is roughly analysed based on thenumber of computing operations; GKM, access control,


traffic confidentiality and integrity and authenticationservices are offered; and dynamic membership is supported.

Cons: There is insufficient information about communicationand computation overheads, and security analysis tosubstantiate the claim that the proposed scheme is veryinefficient; and some communications on the offlinechannel may be required.

6 Challenging factors in designingsecure GCSsAs illustrated in Tables 1 and 2, there is no unique scheme orsystem that can achieve all security requirements. Here, wesummarise various perspectives and attributes in designinga secure and high performance GCS.

6.1 Environment and systemperformance

From the perspective of group management, a central groupcontroller (and, in some systems, a key server) in a centralisedGCS can afford intensive computations and storage overheadbut, in return, becomes a point of the attack which threatensto shutdown all group operations. The other upsides are thathigh security can be achieved effectively and quickly, and eachgroup member sustains less workload. A decentralised GCSreduces the workload performed by each sub-groupcontroller. The apparent downsides include an additionalcommunication overhead caused by communicationsamong sub-group controllers, and the single point of failureproblem. A distributed scheme increases workloads for eachmember in terms of storage and computation overheads,although the system is more scalable and eliminates theneed of the central authority. For either environment(centralised or distributed), the design should optimise thesystem performance measured in terms of overheads(communication, computation and storage) burdened oneach group member, the key server and the controller ofthe system.

6.2 Efficiency of key managementand distribution

The efficiency of several security services relies on thestrength of the key management and the cryptographicstrength of the keys. An efficient GKM scheme shouldmainly reduce the time complexity and the computationalload of key generation, key distribution and rekeying. Thescheme should be scalable as the group size increases.Many efficient GKMs generate keys based on a structureof a key tree and a hierarchy of keys, especially forcentralised and decentralised environments. In a distributedenvironment, a contributory GKM scheme seems moresuitable.


IETdo

www.ietdl.org

6.3 Early detection and prevention

The secure GCS should be operated with strongauthentication and access control mechanisms by which aviolation of resource utilisation and unauthorised activities,for example, a member impersonation and a messagefabrication, can be detected early and prevented. A groupsignature signed on messages can also provide sourceauthentication, message integrity and non-repudiationservices to the receiver and verifier. Since communication,storage and processing overheads are the primary cost forthese security services, a trade-off between overheads andthe protection level should be properly optimised.

6.4 Increased concern over privacy

Privacy becomes a major concern for users participating ingroup communications where there are a large number ofmessage recipients so that message confidentiality may notbe fully guaranteed, and security enforcement may not bepossible or adequate. In general, anonymity servicesubstantially increases overheads and the complexity. Thus,it may not be suitable in a deployment on distributedenvironments where resources are scarce. Instead, partialanonymity can be utilised in such a way that, for a largegroup, only partial identification is required to prove arightful communication while it still preserves memberprivacy.

6.5 Implementation of security servicesfor different applications

From the perspective of group-oriented applications, securityservices should be offered and compatibly interacted for anyapplications to achieve a high security level. Thus, thesystem should be transparent to applications.

7 ConclusionsThis article provides a better understanding on varioussecurity requirements and security services in many GCSs.We have presented Figs. 2 and 3 to identify fundamentalattributes for evaluating mechanisms that provide one ormore security services to GCSs as well as additionalproperties corresponding to those supported securityservices. Then, based on properties in Figs. 2 and 3, wehave presented the comparisons of those outstanding secureGCSs, as depicted in Tables 1 and 2. These tables showthat most existing GCSs have been proposed based on onlyone or two security services and will not be able to satisfyother security requirements. Furthermore, these tables showhow these schemes can be categorised, with respect to thesecurity services offered, and what characteristics andattributes should be compared. Having understood theevaluation attributes, readers and researchers can exploitany other GCSs’ merits, missing attributes or, perhaps,weaknesses that should have been further examined. Toexemplify the usage of our evaluation attributes, we have


evaluated and presented the advantages and disadvantagesof three group communications networks in Section 5. Theresults showed that some important issues were notproperly addressed in these GCS networks, such as norekeying mechanism in [18], no overheads analysis in [19],and weak assumptions in [20], that might make thesenetworks vulnerable against attacks. We have summarisedsome challenges for designing SGCs, such as system-wideperformance, efficiency of key management, privacy issue,implementation and trade-off between security andoverheads.

8 References

[1] SAKARINDR P., ANSARI N.: ‘Security services in groupcommunications over wireless infrastructure, mobile ad-hoc, and wireless sensor network’, IEEE Wirel. Commun.Mag., Spec. Issue Security Wirel. Mobile Ad Hoc SensorNetw., 2007, 14, (5), pp. 8–20

[2] BANERJEE S., BHATTACHARJEE B.: ‘Scalable secure groupcommunication over IP multicast’, IEEE JSAC, 2000, 22,(8), pp. 1511–1527

[3] WONG C.K., GOUDA M., LAM S.S.: ‘Secure groupcommunications using key graphs’, IEEE/ACM Trans.Network., 2000, 8, (1), pp. 16–30

[4] AMIR Y., KIM Y., ROTARU C.N., SCHULTZ J.L., STANTON J., TSUDIK G.:‘Secure group communication using robust contributorykey agreement’, IEEE Trans. Parallel Distrib. Syst., 2004,15, (5), pp. 468–480

[5] SUN Y., LIU K.J.R.: ‘Hierarchical group access control forsecure multicast communications’, IEEE/ACM Trans. Netw.,2007, 15, (6), pp. 1514–1526

[6] ZHANG Q., WANG Y.: ‘A centralized key managementscheme for hierarchical access control’. Proc. IEEEGLOBECOM 2004, Dallas, Texas, December 2004,pp. 2067–2071

[7] CHEN Z., HUANG J., HUANG D., JIANHONG Z., YUMIN W.: ‘Provablysecure and ID-based group signature scheme’. Proc. IEEEAINA 2004, Fukuoka, Japan, March 2004, pp. 384–387

[8] LEE N.-Y.: ‘Threshold signature scheme with multiplesigning policies’, Proc. IEE Comput. Digit. Tech., 2001,148, (2), pp. 95–99

[9] ATENIESE G., CAMENISCH J., JOYCE M., TSUDIK G.: ‘A practical andprovably secure coalition-resistant group signaturescheme’. Proc. IEEE CRYPTO 2000, Santa Barbara,California, August 2000, pp. 255–270

[10] XIAO L., LIU Y., GU W., XUAN D., LIU X.: ‘A design of overlayanonymous multicast protocol’, ACM J. Parallel Distrib.

271


27

&

www.ietdl.org

Comput., Spec. Issue Security Grid Distrib. Syst., 2006, 66,(9), pp. 1205–1216

[11] SYVERSON P.F., GOLDSCHLAG D.M., REED M.G.: ‘Anonymousconnections and onion routing’, IEEE JSAC, 1998, 16, (4),pp. 44–53

[12] REITER M.K., RUBIN A.D.: ‘Crowds: anonymity for webtransactions’, ACM TISSEC 1998, 1998, 1, (1), pp. 66–92

[13] GROSCH C.: ‘Framework for anonymity in IP-multicastenvironments’. Proc. IEEE GLOBECOM 2000, San Francisco,California, December 2000, pp. 365–369

[14] DOLEV S., OSTROVSKY R.: ‘XOR-trees for efficientanonymous multicast and reception’, ACM TISSEC 2000,2000, 3, (2), pp. 63–84

[15] SHIELDS C., GARCIA-LUNA ACEVES J.J.: ‘KHIP: a scalableprotocol for secure multicast routing’. Proc. ACMSIGCOMM 1999, Cambridge, Massachusetts, September1999, pp. 53–64


[16] SHIM Y.-C.: ‘A new approach for secure multicast routingin a large scale network’. Proc. ICICS 2001, Xian, China,November 2001, pp. 95–106

[17] LI T., LAM K.-Y.: ‘A secure group solution for multi-agentEC system’. Proc. IPDPS 2001, San Francisco, CA, April2001, pp. 1749–1756

[18] SHIN S., FATHI H., KOBARA K., IMAI H.: ‘A secure groupcommunication framework in private personal areanetworks (P-PANs)’. Proc. ICWMC 2007, Guadeloupe,French Caribbean, March 2007, pp. 59–67

[19] HARDJONO T., WEIS B.: ‘The multicast group securityarchitecture’. IETF working group, multicast security(MSEC) chapter, retrieved from http://www.ietf.org/html.charters/msec-charter.html and http://www.ietf.org/rfc/rfc3740.txt, accessed December 2009

[20] CHADDOUD G., VARADHARAJAN V.: ‘Efficient secure groupmanagement for SSM’. Proc. IEEE ICC 2004, Paris, France,June 2004, pp. 1436–1440


issn 1751-8709 survey of security services on group communications

Documents