Antigone: A Flexible Framework for Secure Group Communication

19 Pages·2003·0.13 MB·English

CITITechnicalReport99-2
Antigone: A FlexibleFramework forSecure Group
Communication
PatrickMcDaniel
[email protected]
AtulPrakash
[email protected]
PeterHoneyman
[email protected]
ABSTRACT
Many emerging applications on the Internet requiring group communication have varying securi-
ty requirements. Significant strides have been made in achieving strong semantics and security
guarantees within group environments. However, in existing solutions, the scope of available se-
curitypoliciesisoftenlimited. ThispaperpresentsAntigone,aframeworkthatprovidesasuiteof
mechanismsfromwhichflexibleapplicationsecuritypoliciesmaybeimplemented.WithAntigone,
developersmaychooseapolicythatbestaddressestheirsecurityandperformancerequirements.We
describetheAntigone’smechanisms,consistingofasetofmicro-protocols,andshowhowdifferent
securitypoliciescanbeimplementedusingthosemechanisms.Wealsopresentaperformancestudy
illustratingthesecurity/performancetradeoffsthatcanbemadeusingAntigone.
September8,1999
CenterforInformationTechnologyIntegration
UniversityofMichigan
519WestWilliamStreet
AnnArbor,MI48103-4943
Antigone: A Flexible Framework for Secure Group Communication
(cid:0)
Patrick McDaniel AtulPrakash Peter Honeyman
EECSDept. Centerfor InformationTechnologyIntegration
Universityof Michigan UniversityofMichigan
Ann Arbor Ann Arbor
[email protected] [email protected]
1 Introduction
IPmulticast[Dee89]servicesarebecomingmorewidelyavailableontheInternet. Theuseofgroupcommunication
based on IP multicast as a fundamental building block for a varietyof applications such as video conferencing will
increase. Manyinterestingapplicationsthatrequiregroupcommunication,suchasvideoconferencing,collaborative
applications,datacasting,andvirtualcommunities,areemergingontheInternet.Theseapplications,dependingonthe
perceivedrisksandperformancerequirements,requiredifferentlevelsofsecurity. Inthispaper,wepresentasystem,
calledAntigone,thatprovidesmechanismsforbuildingarangeofsecuritypoliciesforgroupcommunication.
Existing approaches provide two predominant policies. Secure multicast systems [HM97, KA98] view groups as
collectionsofparticipantsthatrequireasharedsecret,calledasessionkey,tosecureapplicationtraffic. Groupmem-
bershipmaychangewithoutaffectingthesecuritycontext.Apotentialsecurityriskisthatpastmembersofthegroup
mayhaveaccesstocurrentcontent. Theadvantageofthisapproachislowcost;rekeyingaftermembershipchangesis
notneeded.
Conversely,secure group communication systems [Rei94] typically have threat models that require the changing of
the security context after each membership change. Thus, protection from members not currently in the group is
achievedatthecostofthecontextchange. Somesystemssupportstrongerthreatmodelsthanarestrictlyrequiredby
applicationsatahighperformancecost.
TheAntigoneframeworkprovidesaflexibleinterfaceforthedefinitionandimplementationofawiderangeofsecure
grouppolicies. AcentralelementoftheAntigonearchitectureisasetofmechanismsthatprovidethebasicservices
neededforsecuregroups. Policiesareimplementedbythecompositionandconfigurationofthesemechanisms.Thus,
Antigone does not dictate the available security policies to an application, but provides high-level mechanisms for
implementingthem.
Toeasethetaskofapplicationdevelopment,wealsoprovideafacilityforconfiguringrapidlyasecuritypolicyfroma
setofstandardpoliciesthathavebeenimplementedusingtheAntigonemechanisms.Anapplicationisfreetousethese
standardpolicies,iftheyaresatisfactoryforitspurpose,orbuilditsownusingthehigh-levelmechanismsprovidedby
Antigone.
Antigone is targeted for systems likely to require IP-multicast services. The majority of existing multicast based
systemsdistributehighbandwidthcontenttoahighlydynamicmembership. Anaturalrequirementofthesesystems
isforefficientgroupandsecuritymanagement.
WeseevideoconferencingasrepresentativeofthetypesofapplicationsthatmaybenefitfromtheAntigoneframework.
However, we do not limit Antigone to continuous media systems. A fully functional secure group communication
(cid:1)
ThisresearchissupportedinpartbytheNASAGraduateStudentResearchersProgram,KennedySpaceCenter,GrantNumber10-52613
systemmaybebuiltontheAntigonemechanisms.
Whiletherearewellknowntechniquesforprovidingsecuregroups,Antigonehasseveralgoalsthatmakeitunique.
WestatethefollowingasthefiveprimarygoalsofAntigone.
1. FlexibleSecurityPolicy-Anapplicationshouldbeabletouseawiderangeofsecuritypolicies,withappro-
priateperformancetradeoffs.
2. FlexibleThreatModel-Thesystemshouldsupportthreatmodelsappropriateforawiderangeofapplications.
3. SecurityInfrastructureIndependence-Oursolutionshouldnotbedependentontheavailabilityofaspecific
securityinfrastructure.
4. Transport Layer Independence - The solution should not depend on the availability of any single transport
mechanism(suchasIPMulticast[Dee89]). Ontheotherhand,oursolutionshouldbeabletotakeadvantageof
IP-multicastswhentheyareavailable.
5. Performance-Theperformanceoverheadsofimplementingsecuritypoliciesshouldbekeptlow.
AnearlyversionofAntigonehasbeenintegratedintothevic[Net96]videoconferencingsystem. Theresultofthat
effort, called the Secure Distributed Virtual Conferencing (SDVC) application, was used to broadcast securely the
September1998Internet2MemberMeetingtoseveralsitesacrosstheUnitedStates. ThebroadcastandotherWAN
testsindicatetheviabilityofourapproach.Usinghighspeedcryptographicalgorithmsweareabletoattaintelevision-
like secure video frame rates (30 frames/second(cid:2)) over a LAN. Details of the implementation and our experiences
deployingSDVCcanbefoundin[MHP98,AAC 99].
Theremainderofthepaperisorganizedasfollows. Section2mapsthedesignspaceofsecuregroupcommunication
policies. Section 3 outlines existing designs and techniques of secure group communication. Section 4 outlines
Antigone’shigh-level,layeredarchitecture. Section5presentsthemechanismsthatcanbeusedtoimplementawide
rangeofgroupsecuritypolicies.Section6showsthatawiderangeofsecuritypoliciescanbeimplementedusingthese
mechanisms. Section7presentstheavailablemulticasttransportmodesofAntigone. Section8presentspreliminary
performance results for some of the policies that can be implemented using Antigone. Section 9 summarizes our
conclusionsandpresentsdirectionsforfuturework.
2 Group Security Policies
Differentgroup communication applicationsrequire differentsecurity policies, depending ontheirthreatmodel and
performancerequirements.Inthissection,wepointoutsomeoftheimportantdimensionsalongwhichgroupsecurity
policiesvary. Toaddress the requirementsofa widerangeofapplications, Antigoneattemptstoprovideabasic set
of high-level mechanisms that can be used to implement a range of group security policies. The dimensions that
are discussed below are: session rekeying policy, application message policy, membership awareness policy, and
failure policy. The session rekeying policy defines the reaction of the group to changes in membership in terms of
rekeyingsessions. Theapplication messagepolicydefines the security guarantees with which application messages
aretransmitted. Themembershippolicydictatestheavailabilityofmembershipinformationtomembers. Thefailure
policy defines the type of failures handled by the system. The remainder of this section describes the nature and
implicationsofthesepolicydecisions.
Antigoneassumesthatallgroupmembersaretrusted,i.e.,membersdonotactivelyattempttocircumventthesecurity
ofthesystem.Non-membershowevermayattempttointerceptmessages,modifymessages,orpreventmessagesfrom
beingdelivered.
2.1 SessionRekeying Policy
Acommonstrategytosupportsecuregroupcommunicationamongtrustedmembersistouseacommonsymmetric
session key. An important policy issue for a group communication application is deciding when a session must be
rekeyed,i.e.,theoldsessionkeyisdiscardedandanewsessionkeyissenttoallthemembers.
There is a close relationship between session rekeying and group membership. Applications often need protection
frommembersnotin thecurrentview.1 Therefore, changesin groupmembership requirethesession tobe rekeyed.
Ifrekeyingisnotperformedaftereachchangeinmembership,theviewwillnotreflectasecuregroup,butindicates
onlywhichmembersareactivelyparticipatinginthesession. Pastmembersmayretainthesessionkeyandcontinue
toreceivecontent. Futuremembersmayrecordandlaterdecodecurrentandpastcontent. Inapplicationsthatdonot
needprotectionfrompastorfuturemembers,rekeyingaftermembershipeventsisunnecessary.
We definetheviewgrouptobethesetofmembersinthecurrentgroupmembershipview. Akeygroupisthesetof
memberswhohaveaccesstothecurrentsessionkey. Thekeygroupmaybeasubset,asuperset,oroverlaptheview
group.
Wesaythatagroupsecuritypolicyissaidtobesensitivetoaneventifitchangesthesecuritycontextinresponseto
thereceptionoftheevent.Typically,thesecuritycontextischangedbydistributinganewsessionkey(rekeying).
Group security policy is often sensitive to group membership events. Group membership events include (1) JOIN
event, which is triggered when a member is allowed to join the group; (2) LEAVE events, which is triggered when
a member leaves the group; (3) PROCESS FAILURE events, when a member is assumed to have failed in some
manner; and (4) MEMBER EJECTevents, when a previouslyadmitted member is purgedfrom the group according
to some group policy. In addition, sessions may be rekeyedwhen a specified time intervalhas passed since the last
sessionrekey.
Thesensitivityofapolicydirectlydefinesitsthreatmodel. Forexample,consideragroupmodelthatissensitiveto
onlyMEMBER EJECTevents.Becausethesessionisrekeyedaftermemberejection,thekeygroupwillnevercontain
anejectedmember. Thus, the applicationisassured thatnoejectedmemberwilleverhaveaccessto futurecontent.
However,thesessioncontentisnotprotectedfromprocessesthathaveleftvoluntarily,areassumedtohavefailed,or
joininthefuture.
The sensitivity mechanisms in Antigone can be used to build a large number of session rekeying policies. In the
followingtext,wedefineandillustratefourgeneralpurposepoliciesthatarerepresentativeofthepoliciesimplemented
inexistingsystems.
Time-sensitiveRekeyingPolicy
Groupsimplementingatime-sensitivepolicyperiodically rekey,independentofgroupmembershipevents. Periodic
rekeyingpreventsthesessionkeyfrom“wearingout”. Thegroupattemptstoguardagainstcryptanalysisbyusinga
sessionkeyonlyforalimitedperiod.
By periodically rekeying, the group may be protected from an adversary who wishes to block the delivery of new
session keys. An adversary blocking rekeying messages may intend for the group to continue to use the current
sessionkey.Withatime-sensitiverekeyingpolicy,ifanewkeyisnotsuccessfullyestablishedafterthecurrentsession
keyexpires,groupmemberscanchoosetonolongercommunicateratherthanusetheexpiredsessionkey.
Time-sensitiverekeying can be useful in a secure on-line subscription service. Paying members would periodically
besentanewkeythatisvaliduntilthenextsubscriptioninterval. TheGKMP[HM97]protocolimplementsatime-
sensitiverekeyingpolicy.
Typically,systems implementingtime-sensitivegroups use KeyEncrypting Keys(KEK) [HM97] toreduce thecosts
ofrekeying. Insystems thatuseKEKs, thekeygroupcontainsallpreviousandcurrentmembersofthegroup. This
approachislimitedinthatanymembermaycontinuetoaccessthegroupcontentafterleaving.SystemsthatuseKEKs
cannotforciblyejectmemberswithoutadditionalinfrastructure.
AllrekeyinginAntigoneissessionkeyindependent. Sessionkeyindependencestatesthatknowledgeofonesession
keyprovidesnoinformationaboutothers. Withthisindependence,Antigoneprovidesastrongerguaranteethantime
sensitivegroupsthatuseKEKs;amemberwhohasleftthegroupmaycontinuetoaccessthegroupcontentonlyuntil
thenextrekey.Apastmembercannotaccesscurrentorfuturegroupcontentwithoutagainjoiningasamember.
Leave-SensitiveRekeyingPolicy
Groupsimplementingaleave-sensitivepolicyrekeyafterLEAVE,PROCESS FAILURE,andMEMBER EJECTevents.
1Agroupviewisthesetofidentitiesassociatedwiththemembersofthegroupduringaperiodwherenochangesinmembershipoccur. Ifthe
membershipchanges(amemberjoinsorleavesthegroup),thenanewviewiscreated.ThisisasimilarconcepttoBirmans’sgroupview[Bir93].
Thus,thekeygroupmaybearbitrarilylargerthantheviewgroup.
The threat model implied by leave sensitive groups states that any member who has left the group will not have
accesstocurrentorfuturecontent. Forexample,abusinessconferencingsystemthatsupportsnegotiationsbetween
a company’s representatives and a supplier may benefit from leave-sensitive rekeying. Once the supplier leaves, a
leave-sensitive rekey policy would prevent subsequent discussions from being available to the supplier, even if the
supplierisabletointerceptallthemessages. TheIolus[Mit97]implementsaleave-sensitiverekeyingpolicy.
Join-sensitiveRekeyingPolicy
Groupsimplementingajoin-sensitivepolicyrekeyonlyaftermembershipJOINevents. Thethreatmodelimpliedby
joinsensitivegroupsstatesthatanymemberjoiningthegroupshouldnothaveaccesstopastcontent. Ajoin-sensitive
rekeyingpolicy,byitself,doesnotensurethatmemberswholeftthegrouporwereejectedfromthegrouparenotable
toaccesscurrentsessioncontent. Theassumptionisthatpastmemberscanbetrustedtonotbeinterestedincurrent
content.
Inpractice,ajoin-sensitiverekeyingpolicyislikelytobeusedinconjunctionwithatime-sensitiveoraleave-sensitive
rekeyingpolicytolimitthedurationoverwhichpastmemberscanaccesscurrentsessioncontent.
Membership-sensitiveRekeyingPolicy
Groupsimplementingamembership-sensitivepolicyrekeyaftereverymembershipevent.Thethreatmodelimpliedby
membershipsensitivegroupsstatesthatanygroupmemberjoiningthegroupwillnothaveaccesstopastcontent,and
thatmemberswhohaveleftthegroupwillnothaveaccesstocurrentorfuturecontent.Thispolicyisthecombination
ofleave-sensitiveandjoin-sensitiverekeying.
Applicationswithcomprehensivesecurityrequirementswilllikelyneedamembership-sensitiverekeyingpolicy.Pro-
vidingstrongguaranteesformessagedelivery(e.g.atomicity,reliability)oftenrequirestightcontrolsoverthemessage
content. Withouttightcontrols,theguaranteesmaybecircumvented.TheRAMPART[Rei94]systemprovidesatype
ofmembership-sensitiveservice.
OtherRekeyingPolicies
Applicationsmayrequireacombinationoftheabovepoliciesormayusedifferentpoliciesdependingontheapplica-
tionstateandthespecificattributesofanevent.
Inthebusinessconferencingapplication,forexample,thepolicymaybetorekeyonlywhenamemberwiththerole
Supplierleaves,butnotwhenamemberwiththeroleRepresentativeleaves. Allowingpoliciesthatmakedistinction
betweenmembersmayallowtheapplicationtooptimizerekeying.
In certain circumstances it may be important for the group to be more sensitive at certain times, but less at others.
Groupsmaywishsensitivitytobeafunctionofgroupsizeorresourceavailability. Inthisway,agroupcanprovide
thestrongestsecuritymodelthatissupportedbythenetworkandhostinfrastructure.
Time-sensitive rekeying can be useful in combination with any of the other schemes. Time-sensitive rekeying in
combinationwithmembership-sensitiverekeying,forexample,helpsensurethatanadversarycannotpreventsession
rekeyingindefinitelywithoutdetectionafteramembershipchangeevent.
2.2 ApplicationMessagePolicy
Anapplicationmessagepolicystatesthetypesofsecurityguaranteesrequiredforapplicationmessages.Forexample,
anapplicationwishingtoensurethatnopartyexternaltothegroupisabletoaccesscontentwilldefineconfidentiality
aspartofitspolicy.
Themostcommontypesofmessagesecurityguaranteesare: integrity,confidentiality,groupauthenticity,andsender
authenticity. Confidentiality guarantees that no member outside the group may gain access to the session traffic.
Integrity guarantees that any modification of an application message is detectable by receivers. A session key is
typicallyusedtoobtaintheseguarantees. However,someguaranteessuchassenderauthenticityaredifficulttoobtain
withoutadditionalsecurityinfrastructure. Antigonesupportsthesefourmessageguarantees.
Note that a single policy need not apply to every message. In most applications, different messages will require
differentguarantees,dependingonthenatureofthemessageandtheassumedthreatmodel.
2.3 MembershipPolicy
Identificationofthemembershipwithinagroupsessionisanimportantrequirementforalargeclassofapplications.
As evidenced by a number of group communication systems, achieving strong guarantees for the availability and
correctness of group membership can be costly. In providing availability, any change in membership requires the
distributionofthenewgroupmembershipviewtoeachmember.
Conversely,members in another class of systems need not be aware of group membership at all. This is the model
usedintypicalmulticastapplications.Inthisenvironment,providingotherservices(suchasreliability,fault-tolerance,
etc.) iscommonlylefttotheapplication.
A membership policy indicates the availability of group membership information. If the policy states that group
membershipbesupported,thegroupview(membershipinformation)isdistributedtoeachmemberasneeded.
Antigoneprovidesmechanismstodistributekeyswithandwithoutmembershipinformation,primarilytoallowhigher-
performanceapplicationswhenmembersdonotneedmembershipinformation.
Currently, Antigone does not attempt to guarantee the confidentiality of group membership. In general, hiding the
group membershipfrom membersand non-membersis difficultto doin currentnetworkswithout introducing noise
networktraffic. Thisisprimarilybecausetheabilitytointerceptmessagesonthenetworkallowsaccesstothesource
and destination ofpackets(in case ofunicasts) and at the multicasttree (incase of IP multicasts). In mountingthis
trafficanalysisattack,anadversarymaydeduceacloseapproximationofgroupmembership.
2.4 Process FailurePolicy
Aprocessfailurepolicystatesthesetoffailurestobedetectedandthesecuritytobeappliedtothefailuredetection
mechanism. Thedefiningcharacteristicofafailuredetectionmechanismisthedefinitionofitsfaultmodel. Thefault
modeldefinesthetypesofbehaviorexhibitedbyafaultyprocessthatthemechanismwilldetect.Typicalcrashmodels
include fail-stop, message omissions, or timing errors [Mul93]. In the strongest (Byzantine failure) model, a faulty
processmayexhibitanybehaviorwhatsoever.
A process failure policy may also state the need for secure failure detection. In securing the failure detection, the
group may be protected from the masking of process failures by an adversary. However, protecting the group from
an adversary who attempts to generate false failures may be more difficult. Failures may be forced by blocking all
communication between the group participants. This is a denial of service attack, which is difficult to address in
software.
Antigonesupportsdetectionoffail-stopfaultsofgroupmembers. Topreventproblemsduetotimingerrors,synchro-
nizedclocksandtimestampsarenotusedintheAntigoneprotocols. However,somemechanismsforfailuredetection
andtime-sensitiverekeyinginAntigonedorelyontimeoutsatindividualprocesses. Aprocesswhoseclockprogress-
esat anincorrectrate may takelongerto detectfailuresofother processes(ifitsclock progresses tooslow)ormay
mistakenlyassumethatthereisafailure(ifitsclockprogressestoofastandthustimesout).
3 Related Work
In this section, we review severalof the key concepts and knowntechniquesin the design of frameworks for group
communication.Twofieldsapplicabletoourinvestigationaresecuregroupcommunicationanddesignapproachesfor
configurableprotocols. Wepresentsomeofthemajorfindingsineachoftheseareas.
Much of the existing technology on which group communication is based was originally implemented in the ISIS
[Bir93] and later HORUS [RBM96] group communication systems. Using these frameworks, developers can ex-
periment with a number of protocol features. One important feature of the HORUS system is the introduction of a
comprehensivesecurityarchitecture. Anelementofthisarchitectureisahighlyfault-tolerantkeydistributionscheme.
Processgroupsemanticsareusedtofacilitatesecurecommunication. ThesessionkeydistributedtomembersinHO-
RUS is maintained for the entiresession, thus providingnosensitivity to membership change events. However, the
vulnerability to attacks from past or future members is limited. Application messages have sender authenticity and
maybeconfidential.
Virtualnetworksprovidedeveloperswithanabstractionforbuildingapplicationsdesignedfor(logically)localnetwork
traffic, but executed across across physically larger networks. The Enclaves system [Gon96] extends this model to
secure group communication. Enclaves provides a leave-sensitive group, distributing a new group key after each
member leave. Also, it is implied that the group key should be changed periodically (time-sensitive). Enclaves
supportsmembershipinformationbutisnotdependentonit. Messageshaveconfidentialityandthroughpoint-to-point
communication,senderauthenticity.
TheRAMPART system[Rei94]providessecurecommunicationinthepresenceofactivelymaliciousprocessesand
Byzantine failures. The system uses secure channels between two members of the protocol to provide authenticity.
Protocolsdependgreatlyontheconsensusofprocessestoreachagreementonthecourseofaction. Amembership-
sensitivegroupisbuiltona securegroup membershipprotocol. Thesecurity contextisnotchangedthroughshared
sessionkeys,butthesecuredistributionofnewgroupviews. Messageshavesender-authenticationandintegrity.
A limitation of manysecure group communication systems isthat they donot scale to largernetworks. In [Mit97],
Mittradefinesthe1effectsnfailure,whereasinglemembershipchangeeventeffectstheentiregroup.TheIolussystem
[Mit97], attempts to address this limitation by introducing locally maintained subgroups. Each subgroup maintains
its own session key, which is replaced after a membership change event in the subgroup. Therefore, the effect of a
membershipchangeislocalizedtothesubgroup. Iolusprovidesaleave-sensitivegroup,andallapplicationmessages
areencryptedwiththegroupsessionkey.NomembershipinformationisdistributedinIolus.
Keyhierarchies[WHA98,WGL98]provideanefficientalternativetosubgroupinginachievingscalable,securegroup-
s. Akeyhierarchyissinglyrootedn-arytreeofcryptographickeys. Theinteriornodekeysareassignedbyasession
leader, and eachleaf node key is a secret key shared shared between the session leader and a single member. Once
thegrouphasbeenestablished,eachmemberknowsallthekeysbetweentheirleafnodekeyandtheroot. Aschanges
inmembershipoccur,rekeyingisperformedbyreplacingonly thosekeysknown(required)bytheleaving(joining)
member. Rekeyingwithoutmembershipchanges(asneededintimesensitivegroups), canbeachievedbyreplacing
therootkey.Thus,thetotalcostofrekeyinginkeyhierarchiesscaleslogarithmically.
TheGroupKeyManagementProtocol(GKMP)[HM97]attemptstominimizethecostsassociatedwithsessionkey
distribution byloosening the requirementthat each session keybe independent of others. Afterbeing accepted into
the group, newly joined members receive a Key Encrypting Key (KEK) under which a future session key will be
delivered. Alimitationofthisgroupisthatmisbehavingmemberscanonlybeejectedbytheestablishmentofanew
group. GKMP reduces the costs of authentication by introducing a peer-to-peer review process in which potential
members are authenticated by different members of the group. The joining member’s authenticity is asserted by
existing members. GKMP providesa time-sensitive group by rekeying at the end of a session key’s lifetime. Note
thatthisisa keymanagementprotocol,and assuchdoesnotmandatehowthesession keyisused. Nomembership
informationisprovidedtomembers.
TheIPSec[KA98]standardsattempttoachieveInternetsecuritybyintroducingsecuritymechanismsatthenetwork
layer. The Scalable Multicast Key Distribution (SMKD) [Bal96] standard extends this approach to the multicast
environment.IntendedasanextensiontoCoreBasedmulticastrouting[BFC93],SMKDusestherouterinfrastructure
todistributesessionkeys.Asthemulticasttreeisconstructed,leafroutersobtaintheabilitytoauthenticateanddeliver
sessionkeystojoiningmembers. Thus,thecostofauthenticationandsessionkeydeliverycanbedistributedamong
the leaf routers. Similar to GKMP, SMKD providesa time-sensitivegroup which is rekeyedat the end of a session
key’slifetime.
Withrespecttosecurity,thepoliciesimplementedbythesesystems areessentiallyfixed. Applicationsmustselecta
solutionthatprovidesapolicythatbestfitsaminimalsetofrequirements.However,theacceptedsolutionmayprovide
unnecessaryfunctionalityatanincreasedcost.
The micro-protocol [HP94, HS98] design methodology is useful when constructing systems with dynamic protocol
stacks. Usingmicro-protocols,asystemdesignermaydecomposethefacilitiesprovidedbyprotocolsintotheiratomic
(cid:3)
Application(cid:13)
Application(cid:13) Membership(cid:13) Process Failure(cid:13)
Rekeying Policy(cid:13)
Message Policy(cid:13) Policy(cid:13) Policy(cid:13)
Predefined Policies(cid:13)
Rekey/Group(cid:13) Application(cid:13)
Authenticate(cid:13) Join(cid:13) Failure Detection(cid:13) Leave(cid:13)
Membership(cid:13) Message(cid:13)
Mechanisms(cid:13)
(cid:4) (cid:5) (cid:6)
Point-to-point(cid:13) Asymmetric Multicast(cid:13) Symmetric Multicast(cid:13)
Broadcast Transport(cid:13)
Multicast/TCP(cid:13)
IP(cid:13)
Figure 1: The architecture of Antigone consists of three layers; the broadcast transport layer, the mechanism layer,
and the predefined policy layer. The broadcast transport component providesa single broadcast abstraction for en-
vironments with differinglevelsof support for multicast. Themechanism layer providesa set of primitivesused to
implement application policies. The predefined policies layer provides a suite of general purpose policies. Where
required,applicationsmaydefineotherpoliciesbyaccessingthemechanismandbroadcasttransportlayerdirectly.
components.Compositeprotocolsareconstructedfromacollectionofthesmallermicro-protocols.Differingfacilities
and guaranteesmay beprovidedthrough thecomposition ofthemicro-protocols. In[HS98], the authorsdefine and
demonstrateasuiteofmicro-protocolsformaintaininggroupmembershipwithinadistributedapplication. Antigone
usesthemicro-protocolapproachtoachieveflexibilityinimplementingvarioussecuritypolicies.
4 Architecture
Described in Fig. 1, the Antigone architecture consists of three software layers; the broadcast transport layer, the
mechanismlayer,andthepredefinedpolicylayer.
Thoughnottypicallyassociatedwithsecurecommunicationservices,thebroadcasttransportcomponentprovidesan
abstractionforunreliablegroupcommunication.Arealityoftoday’sInternetisthattherearevaryinglevelsofsupport
for multicast services. Although significant effort has been expendedon the developmentof WAN multicasting, no
singlesolutionhasbeenfoundtomeettherequirementsofallusers. Developersspecifythelevelofmulticastsupport
ofthetargetenvironmentatruntime. WedescribethebroadcasttransportlayerinSection7.
Themechanismlayerprovidesasetofmechanismsusedtoimplementapplicationpolicies.Themechanismsrepresent
thebasicfeaturesrequiredforasecuregroup. Policiesareflexiblydefinedandimplementedthroughtheselectionand
interactionofmechanisms. Associatedwitheachmechanismisamicro-protocol[HS98]. Thegroupprotocol,called
acompositeprotocol,isdefinedbythecompositionofthemechanismmicro-protocols. Weidentifyanddescribethe
designoftheAntigonemechanismsinSection5.
The predefined policy layer provides a suite of general purpose policies. These policies represent those commonly
providedbysecuregroupcommunicationsystems. Clearly,there aremanypoliciesbeyondwhatisavailableinthis
layer.Whererequired,anapplicationmayextendorreplacethesepoliciesbyaccessingdirectlythebroadcasttransport
andmechanismslayers. WedescribehowthepredefinedpolicesareimplementedthroughtheAntigonemechanisms
inSection6.
Authenticate
(cid:7)(cid:9)(cid:8)(cid:11)(cid:10)(cid:13)(cid:12)(cid:15)(cid:14)(cid:16)(cid:7)(cid:18)(cid:17)(cid:20)(cid:19)(cid:22)(cid:21)
1. (authenticationrequest)
(cid:10)(cid:13)(cid:12)(cid:23)(cid:8)(cid:25)(cid:24)(cid:26)(cid:24)(cid:28)(cid:27)(cid:29)(cid:14)(cid:30)(cid:10)(cid:13)(cid:12)(cid:31)(cid:17)(cid:20)(cid:7) (cid:17)!(cid:19)#"
2. (pairkeyrequest)
(cid:24)(cid:26)(cid:24)(cid:31)(cid:27)$(cid:8)(cid:11)(cid:10)(cid:13)(cid:12)(cid:15)(cid:14)&%(’)+*(,.-/102%3(cid:7)547698;: <=%3(cid:10)(cid:13)(cid:12)(cid:26)476?>A@B(cid:17)(cid:20)(cid:19)#"C47698;:
3. (pairkeyresponse)
(cid:10)(cid:13)(cid:12)(cid:23)(cid:8)D(cid:7)2(cid:14)(cid:30)(cid:10)E(cid:12)(cid:26)(cid:17)(cid:20)(cid:7)(cid:18)(cid:17)F%#G+(cid:17)!(cid:7) (cid:17)(cid:20)(cid:19) (cid:21) (cid:17)(cid:20)(cid:19);HI(cid:17)#’JLKCMONQP(cid:22)R S(cid:22)MOKCP;TU@V(cid:17)!(cid:27)XW+YZ47[C8#:(cid:30)\>
4. (authenticationresponse)
Join
(cid:7)(cid:9)(cid:8)(cid:11)(cid:10)(cid:13)(cid:12)(cid:15)(cid:14)(cid:16)(cid:7)(cid:18)(cid:17)F%3(cid:7) (cid:17)(cid:20)(cid:19) H 4 [ 8#:(cid:30)\>
5. (joinrequest)
Rekey/GroupMembership
(cid:10)(cid:13)(cid:12)(cid:23)(cid:8)D(cid:7)2(cid:14)CG.(cid:17)!(cid:10) *(cid:30), (cid:17)7]O(cid:7) (cid:17);%;G.(cid:17)!(cid:10)(cid:13)^‘_(cid:16)4 [ 8#:(cid:30)\>bac%7de]fG.(cid:17)!(cid:10) *(, (cid:17)#]g(cid:7) (cid:17)F%#G+(cid:17)c(cid:10)(cid:13)^h_(cid:16)4 [ 8;:(cid:30)\>ia(cid:20)ac4 *(6(cid:26)j
6a. (keydistribution)
(cid:10)(cid:13)(cid:12)(cid:23)(cid:8)D(cid:7)2(cid:14)CG.(cid:17)!(cid:10) *(cid:30), (cid:17)7]O(cid:7) (cid:17);%;G.(cid:17)!(cid:10)(cid:13)^‘_(cid:16)4 [ 8#:(cid:30)\>ba(cid:22)(cid:17)(cid:20)kl(cid:17)!mn(cid:17)!op(cid:17);q#q;q7(cid:17)F%7de]fG.(cid:17)!(cid:10) *(, (cid:17)#]O(cid:7)(cid:18)(cid:17)F%#G+(cid:17)c(cid:10)(cid:13)^h_I4 [ 8#:(cid:30)\>ia(cid:22)(cid:17)!k‘(cid:17)cmn(cid:17)(cid:20)op(cid:17)#q;q;qra(cid:22)4 *(6(cid:26)j
6b.
(key/groupmembershipdistribution)
(cid:10)(cid:13)(cid:12)(cid:23)(cid:8)sGUtCK3W(cid:30)Jp(cid:14)CG5u=v(cid:30)(cid:17)!(cid:10)i*(,w(cid:17)#]g(cid:7) (cid:17)F%#GXuxv(cid:16)(cid:17)!(cid:10)E^ _ "#47[C8#:(cid:30)\>ya(cid:22)(cid:17)#]gk‘(cid:17);%;GXuxv(cid:16)(cid:17)c(cid:10)(cid:13)^ _ "#43[38#:(cid:30)\z{aF(cid:17);q;q#q;(cid:17)
(cid:2) (cid:2)
6c.
%7de]fG.(cid:17)!(cid:10)i*(,{(cid:17)#]O(cid:7)(cid:18)(cid:17)F%#GXu=v(cid:30)(cid:17)!(cid:10)(cid:13)^ _ (cid:2) "#47[C8;:(cid:30)\>iaF(cid:17);q#q;q|ac4 *(6 jQ}U~
(sessionrekey)
ApplicationMessaging
(cid:7)(cid:9)(cid:8)sGUtCK3W(cid:30)Jp(cid:14)7G.(cid:17)(cid:20)(cid:7) (cid:17)7’(cid:127)(cid:129)(cid:128)C(cid:130)3(cid:130)#(cid:131)(cid:30)G&(cid:128)#@V(cid:17);%7d(cid:23)](cid:132)G+(cid:17)!(cid:7) (cid:17)(cid:133)(cid:127)(cid:129)(cid:128)C(cid:130)3(cid:130)#(cid:131)(cid:30)G&(cid:128)Cac4 *(6 j
7a. (withintegrity)
(cid:7)(cid:9)(cid:8)sGUtCK3W(cid:30)Jp(cid:14)7G.(cid:17)F%7(cid:7)(cid:18)(cid:17)#’(cid:127)(cid:134)(cid:128)C(cid:130)3(cid:130)7(cid:131)(cid:30)GU(cid:128)#@V4 *(6 j
7b. (withconfidentiality)
(cid:7)(cid:9)(cid:8)sGUtCK3W(cid:30)Jp(cid:14)7G.(cid:17)F%7(cid:7)(cid:18)(cid:17)#’(cid:127)(cid:134)(cid:128)C(cid:130)3(cid:130)7(cid:131)(cid:30)GU(cid:128)#@V4 *(6 j (cid:17);%7d(cid:23)](cid:132)G+(cid:17);%7(cid:7) (cid:17)7’(cid:127)(cid:129)(cid:128)C(cid:130)3(cid:130)#(cid:131)(cid:30)G&(cid:128)#@g4 *(cid:30)6 j ac4 *(6 j
7c. (withintegrityandconfidentiality)
(cid:7)(cid:9)(cid:8)sGUtCK3W(cid:30)Jp(cid:14)7G.(cid:17)(cid:20)(cid:7) (cid:17)7’(cid:127)(cid:129)(cid:128)C(cid:130)3(cid:130)#(cid:131)(cid:30)G&(cid:128)#@V(cid:17)!d(cid:23)]fG.(cid:17)(cid:20)(cid:7)(cid:18)(cid:17)(cid:133)(cid:127)(cid:129)(cid:128)3(cid:130)3(cid:130)7(cid:131)(cid:30)GU(cid:128)Ca(cid:133)(cid:135)+>
7d. (withsenderauthenticity)
FailureDetection
(cid:7)(cid:9)(cid:8)(cid:11)(cid:10)(cid:13)(cid:12)(cid:15)(cid:14)CG.(cid:17)(cid:20)(cid:7)(cid:18)(cid:17)!(cid:10) / (cid:17)!d(cid:23)]fG.(cid:17)!(cid:10) / a [ 8#:(cid:30)\>
8. (memberheartbeat)
(cid:10)(cid:13)(cid:12)(cid:23)(cid:8)sGUtCK3W(cid:30)Jp(cid:14)CG.(cid:17)!(cid:10)E(cid:12)(cid:26)(cid:17)!(cid:10) *(cid:30), (cid:17)(cid:20)de]fG.(cid:17)!(cid:10) *(, a(cid:137)(cid:136)i(cid:138)(cid:20)(cid:139)
9. (sessionleaderheartbeat)
(cid:7)(cid:9)(cid:8)(cid:11)(cid:10)(cid:13)(cid:12)(cid:15)(cid:14)CG.(cid:17)(cid:20)(cid:7)
10. (keyretransmitmessage)
Leave
(cid:7)(cid:9)(cid:8)(cid:11)(cid:10)(cid:13)(cid:12)(cid:15)(cid:14)(cid:16)(cid:7)(cid:18)(cid:17)F%#G+(cid:17)!(cid:7) (cid:17)F%#G+(cid:17)!kh4 *(6 j 47[C8#:(cid:30)\>
11. (leaverequest)
Figure 2: Antigone Micro-Protocol Description - micro-protocols for the various operating modes. A composite
protocolisconstructedfromtheselectionofasubsetofthesemodes. Insomeconfigurations,somemicro-protocols
maybeomittedentirely.
5 Mechanisms
We chose a composite protocol approach [HS98] for the design of Antigone mechanisms. In composite protocols,
featuresarepartitionedintomodulesconsistingofsharedstate,messages,events,andmicro-protocols.Thisapproach
hasseveraldesirablepropertiesthatmakeitapplicabletoAntigone.First,themodulardesignallowsfortheintegration
of future enhancements with minimal effect on other modules. Second, the micro-protocol approach allows state
sharing between modules. We avoid the costs typically associated with state sharing between protocols (message
headers).
Antigoneprovidesmechanisms for providingthefollowingfunctions; authentication, member join, session keyand
group membership distribution, application messaging, failure detection, and member leave. The Antigone micro-
protocol variants associated with each mechanism are defined in Fig. 2. Before describing the micro-protocols, we
explaintheprincipalsintheprotocolsandthenotationused.
Fig.3showstheprincipalsinanAntigonelogicalgroup. Adistinctmemberofthegroupwhoseidentityisknownin
advancetoallmembers,calledthesessionleader(SL),isthearbiterofgroupoperationssuchasgroupjoins,leaves,
etc. Wechoseanarbitratedgroupbecauseofitslowcostanditsapplicabilitytomanyapplications. Forexample,ina
securepay-per-viewvideobroadcastapplication,thecablecompanywouldprovideasessionleaderthatenforcesthe
desiredaccesscontrolandkeydistributionpolicy.
A Trusted Third Party (TTP) providesthe mechanism for the session leader to authenticatejoining group members.
^ /
Eachpotentialmember,A,ofagroup(includingthesessionleader)hasasharedsecret registeredwiththetrusted
third party (TTP). This secret key is generated and registered with the TTP before the party attempts to join any
session. Weassumeanoutofbandmethodforregisteringthesekeysandforinformingeveryoneabouttheidentityof
thesessionleader.
(cid:7)
Inour protocol descriptions, we use the termSL to referto the identity ofthe session leader, torefer to a current
%#(cid:140)(cid:23)43(cid:141)
orpotentialmemberofthesession, andTTPtorefertothe trustedthird party. referstomessageX encrypted
underthe keyk. The viewidentifier,g, is usedto uniquelytag thechanging viewsofgroup membership. Theterm
(cid:10)(cid:13)^h_ G (cid:10)(cid:13)^‘_ " G(cid:142)u$v
(cid:2)
refers toasession keyinview , and forthe(next)view . ThetermI,possiblywithasubscript,
) /w-(cid:143)
refers to a nonce value. Key distribution protocols based on Leighton-Micali define a term , called a pair key,
usedtosupportsecretcommunicationbetweencollaboratingmembersAandB.Derivedfromthepairkey,thesession
*(,.-/
leaderandapotentialmemberAmaintainasharedsecretkey(cid:144) . Acryptographichashforthetext(cid:145) isdescribed
d(cid:23)] a
by (cid:145) . WeusetheMD5hashalgorithm[Riv92]inourimplementation.
The format of the identity, nonce, key, and view identifier values used in our current protocol implementation is as
follows. Each identity is a unique 16 byte null terminated ASCII string of alphanumeric characters. A potential
memberisassignedthisvaluewhenregisteringalongtermkeywiththeTTP.Noncevaluesareunique64bitvalues.
Toensurethatnoncesarenotreused,somesourceofmonotonicvalues,suchasthesystemclock,maybeused. Key
formatisalgorithmdependent. TheDESstandardusesaneightbytekey(includingeightparitybits).Inthefuture,as
G
otherciphersareintegratedintoAntigone,wewillneedtosupportotherformats. Theviewidentifier consistsofa
twoparts.Thefirstpartisaneightbyte,nullterminatednamestringthatidentifiesthegroup,usedonlyfordisplaying
GZu(cid:146)v
anddebuggingpurposes. Thesecondisaneightbitnoncevalue.Eachtimeanewviewiscreated( ),anewnonce
isgeneratedandappendedtothegroupnamestringtocreatethenewviewidentifier.
JLKCM(cid:132)NQP(cid:22)R(cid:18)SFMOKCP;T
A isdistributedbythesessionleadertoeachgroupmemberduringtheauthenticationprocess. Defined
bytheapplication,thepolicyblockisanarbitrarybytestringstatingthegrouppolicy.Wedescribetheuseofthisdata
bythepredefinedpolicieslayerinSection6.
(cid:27)XW Y (cid:27)Xt Y (cid:27)XW Y
Thesessionleadercreatesanasymmetrickeypair( , )duringgroupinitialization. Thepublickey( )is
deliveredtopotentialmembersduringtheauthenticationprocess. Thepublickeyisusedtoreducethecostofsending
secureheartbeatsfromthesessionleader.
Wheresenderauthenticityisconfigured,weassumetheexistenceofacertificatedistributionservice[HFPS98]. The
m9/
certificateservicewouldprovideaccesstocertificatesforeachgroupmember( ). Notethatnocertificatedistribu-
(cid:27)XW+Y (cid:27)Xt#Y
tionserviceisrequiredinourprotocoltogenerateordistributethe( , )asymmetrickeypair.
WeuseDES[Nat77]forallencryptioninthecurrentimplementation. Itsinherentstrengthisevidentfromits20-year
history,yetits56-bitkeylengthhaslongbeenthesubjectofdebate. Relatedalgorithmssuchastriple-DES[ANS85]
orDESX[KR96]offerthestrengthofDESwithconsiderablylongerkeys. Ourprotocolsarenottiedtoanyspecific
propertyofDES,andmaybereplacedwithothercryptographicalgorithmsasnecessary.
Weassumethatallprocessesthathaveachievedmembership,andthushavebeenauthenticated,adheretothesystem
specification. Weassumenomemberwillingfullydisclosesitslongtermorsessionkeys. AllmemberstrusttheTTP
nottodisclosetheirlongtermkey,andtogeneratepairkeysaccordingtothespecification.
Thefollowingtextdescribeseachofthemicro-protocolmodulesinFig.2. AllcitedmessagenumbersrefertoFig.2.
Authentication Mechanism - The authentication mechanism provides facilities for the authentication of potential
groupmembers. Thepurposeofthismechanismistwofold. First,thesessionleaderauthenticatesthepotentialgroup
member.Second,asharedsecretbetweenthetwopartiesisnegotiated.Thesharedsecret,calledthesharedsecretkey,
islaterusedtoimplementasecurechannelbetweenthetwoparties.
We usethe Leighton-Micalikeydistributionalgorithm [LM94]to authenticatethejoining process andnegotiate the
sharedsecret. ThemainadvantageofLeighton-Micaliislowcost;itusessymmetrickeyencryptionthroughout,with
none of the modular exponentiation operations associated with public key cryptosystems. Public key cryptography
requiressignificantlymorecomputationthansymmetricalgorithms. Thede-factostandardforpublic-keycryptogra-
phy,RSA,canbeupto100timesslowerinsoftwareand1000timesslowerinhardwarethanDES,thepredominant
symmetricalgorithm[Sch96].