<%BANNER%>

Framework for Scalable Secure Source Specific Multicast


PAGE 1

FRAMEWORKFORSCALABLESECURESOURCESPECIFICMULTICAST By MURALI M. BRAHMADESAM A THESIS PRESENTED TO THE GRADUA TE SCHOOL OF THE UNIVERSITY OF FLORID A IN P AR TIAL FULFILLMENT OF THE REQUIREMENTS F OR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORID A 2002

PAGE 2

Cop yrigh t 2002 b y Murali M. Brahmadesam

PAGE 3

T o My w onderful Mom & Dad

PAGE 4

A CKNO WLEDGMENTS I w ould lik e to express m y deep est gratitude to m y advisor, Dr. Ric hard E. Newman, for giving me the opp ortunit y to w ork on this in teresting eld of secure m ulticasting. This w ork w ould not ha v e b een p ossible but for his excellen t advice and guidance through dieren t stages of the thesis. Thanks go to Dr. Randy Cho w and Dr. Jonathan Liu for their suggestions during sev eral researc h meetings. Thanks go to Mr. Rah ul Shah and Mr. Chira yu Shah of Proto cols group, Ericsson IP Infrastructure, Ro c kville, MD, for their v aluable guidance in m ulticast proto cols dev elopmen t and deplo ymen t during m y In ternship in summer 2001. Sp ecial thanks go to the p eople in v olv ed in IETF, with whom I ha v e in teracted regarding m ulticast proto cols. But for their dedication, the In ternet w ould not ha v e gro wn this h uge or robust. Finally I w ould lik e to thank m y paren ts for their con tin ued and encouraging supp ort throughout m y p erio d of study here. iv

PAGE 5

T ABLE OF CONTENTS page A CKNO WLEDGMENTS . . . . . . . . . . . . . . iv LIST OF FIGURES . . . . . . . . . . . . . . . . vii KEY TO ABBREVIA TIONS . . . . . . . . . . . . . viii ABSTRA CT . . . . . . . . . . . . . . . . . . x CHAPTER 1 INTR ODUCTION . . . . . . . . . . . . . . . 1 2 KEY MANA GEMENT REQUIREMENTS F OR MUL TICAST APPLICA TIONS . . . . . . . . . . . . . . . . . 3 3 MUL TICAST R OUTING AR CHITECTURE . . . . . . . 5 3.1 IGMPv3 . . . . . . . . . . . . . . . . 5 3.2 PIM-SM . . . . . . . . . . . . . . . . 6 3.3 Summary . . . . . . . . . . . . . . . 8 4 MUL TICAST KEY DISTRIBUTION: EXISTING SOLUTIONS . . 9 4.1 Iolus F ramew ork . . . . . . . . . . . . . . 9 4.1.1 Group Initialization and Mem b er Addition . . . . 9 4.1.2 Mem b er Deletion . . . . . . . . . . . 9 4.1.3 Data T ransmission . . . . . . . . . . . 10 4.1.4 Merits of the Iolus F ramew ork . . . . . . . . 10 4.1.5 Limitations of the Iolus F ramew ork . . . . . . 10 4.1.6 Summary . . . . . . . . . . . . . . 12 4.2 Group Key Managemen t Arc hitecture (GKMA) . . . . . 12 4.2.1 Ov erview . . . . . . . . . . . . . . 12 4.2.2 Detailed Description . . . . . . . . . . . 13 4.2.3 Merits of GKMA . . . . . . . . . . . 16 4.2.4 Limitations of GKMA . . . . . . . . . . 16 4.3 General Limitations of an y GKMP . . . . . . . . 17 4.3.1 Group Secrets . . . . . . . . . . . . 17 4.3.2 P olicy Complexit y . . . . . . . . . . . 17 4.4 Summary . . . . . . . . . . . . . . . 18 v

PAGE 6

5 MUL TICAST KEY MANA GEMENT: EXISTING SOLUTIONS . . 19 5.1 Naiv e Key Managemen t . . . . . . . . . . . 19 5.2 T ree Based Solution Using Bo olean F unction Minimization . . 19 5.2.1 Individual Mem b er Remo v al . . . . . . . . 20 5.2.2 Remo v al of Multiple Mem b ers . . . . . . . . 20 5.2.3 Collusion A ttac ks . . . . . . . . . . . 22 5.2.4 P erformance Analysis . . . . . . . . . . 22 5.3 Summary . . . . . . . . . . . . . . . 22 6 A PRA GMA TIC FRAMEW ORK F OR SCALABLE SECURE SOUR CE SPECIFIC MUL TICAST . . . . . . . . . . . . 24 6.1 Design F eatures and Requiremen ts . . . . . . . . . 24 6.2 Key Distribution . . . . . . . . . . . . . 25 6.2.1 F ramew ork . . . . . . . . . . . . . 25 6.2.2 Op erational Ov erview . . . . . . . . . . 26 6.2.3 Data T ransmission . . . . . . . . . . . 29 6.3 Key Managemen t . . . . . . . . . . . . . 30 6.3.1 Detailed Description . . . . . . . . . . . 31 6.3.2 Mem b er Join . . . . . . . . . . . . . 31 6.3.3 Individual Mem b er deletion . . . . . . . . . 32 6.3.4 Cum ulativ e Mem b er Deletion . . . . . . . . 33 6.3.5 T ree Gro wth . . . . . . . . . . . . . 33 6.3.6 T ree Shrink age . . . . . . . . . . . . 33 6.4 Prop erties . . . . . . . . . . . . . . . 34 6.5 Summary . . . . . . . . . . . . . . . 34 7 CONCLUSION AND FUTURE W ORK . . . . . . . . . 36 7.1 Conclusion . . . . . . . . . . . . . . . 36 7.2 F uture W ork . . . . . . . . . . . . . . . 38 REFERENCES . . . . . . . . . . . . . . . . . 39 BIOGRAPHICAL SKETCH . . . . . . . . . . . . . . 41 vi

PAGE 7

LIST OF FIGURES Figure page 3.1 An example of a group-shared and source-sp ecifc tree using PIM . 8 4.1 Data transmission in Iolus . . . . . . . . . . . . 11 4.2 Group Securit y Asso ciation Mo del . . . . . . . . . . 14 5.1 Key Up date in a group of size 8 for departure of c 5 . . . . . 21 5.2 Example of departure of m ultiple mem b ers . . . . . . . 21 6.1 Pragmatic F ramew ork for Scalable Secure Multicast . . . . . 27 vii

PAGE 8

KEY TO ABBREVIA TIONS A CL: Access Con trol List CBT: Core Based T ree DR: Designated Router DSP: Data Securit y Proto col D VMRP: Distance V ector Multicast Routing Proto col GCKS: Group Con troller / Key Serv er GKMA: Group Key Managemen t Arc hitecture GKMP: Group Key Managemen t Proto col GSA: Group Securit y Agen ts GSC: Group Securit y Con troller GSI: Group Securit y In termediary IGMP: In ternet Group Mem b ership Proto col IP: In ternet Proto col IPSEC: IP Securit y Proto col KEK: Key Encrypting Key LKS: Lo cal Key Serv er PIM-SM: Proto col Indep enden t Multicast Sparse Mo de RKP: Re-Key Proto col RP: Registration Proto col RP: Rendezv ous P oin t RSPT: Rev erse Shortest P ath T ree SA: Securit y Asso ciation viii

PAGE 9

SDP: Session Description Proto col SPI: Securit y P arameter Index SPKI: Simple Public Key Infrastructure SSM: Single Source Multicast TEK: T rac Encrypting Key ix

PAGE 10

Abstract of Thesis Presen ted to the Graduate Sc ho ol of the Univ ersit y of Florida in P artial F ulllmen t of the Requiremen ts for the Degree of Master of Science FRAMEW ORK F OR SCALABLE SECURE SOUR CE SPECIFIC MUL TICAST By Murali M. Brahmadesam Decem b er 2002 Chair: Ric hard E. Newman Ma jor Departmen t: Computer and Information Science and Engineering Multicast is a mo de of message deliv ery in whic h a single message is deliv ered to a group of recipien ts. Multicast deliv ery minimizes the demand on the sender and net w ork resources. With the standardization of sev eral m ulticast routing and group mem b ership proto cols, the task of m ulticast pac k et deliv ery is fairly complete. Issues lik e group access con trol, source authen tication, and secrecy ha v e b een the ma jor h urdles in w orld-wide deplo ymen t of m ulticast. Secure m ulticast is the term used to indicate a m ulticast service pro viding the aforemen tioned securit y features. Secure m ulticast is generally ac hiev ed b y pro viding a symmetric cryptographic k ey called a session k ey to the group mem b ers and b y sending the group data encrypted using the session k ey Th us only the legitimate group mem b ers will b e able to decipher the group data. The task of pro viding secure m ulticast is divided in to t w o ma jor subtasks, namely secure k ey distribution, and secure k ey managemen t. Secure k ey distribution in v olv es distributing the session k ey securely to legitimate group mem b ers. Secure k ey managemen t in v olv es generating the session k ey and facilitating k ey up dates in an ecien t manner. x

PAGE 11

This thesis discusses v arious existing tec hniques to pro vide secure k ey distribution and managemen t. Scalabilit y is a k ey issue to enable large scale deplo ymen t of secure m ulticast. A sp ecial category of m ulticast, namely Source Sp ecic Multicast (SSM), is considered. In SSM the m ulticast group con tains a single source and the remaining mem b ers are just receiv ers. A framew ork for scalable secure source sp ecic m ulticast is prop osed with the k ey distribution sc heme pro viding a tree based solution where the group mem b ership c hanges ha v e only a lo cal eect, and the k ey managemen t sc heme solving the lo cal mem b ership c hanges ecien tly with the help of a lo cal k ey serv er. xi

PAGE 12

CHAPTER 1 INTR ODUCTION Multicasting enables group comm unication b y deliv ering a single message sen t to m ultiple receiv ers. Applications suc h as audio and video distribution, and sev eral other \push" applications are the driving forces for m ulticast deplo ymen t. Reliabilit y (timely and orderly deliv ery of messages) and securit y (group access con trol, source authen tication and secrecy) ha v e b een the tallest h urdles in the path of commercial utilization of m ulticast applications. Multicast pac k et deliv ery is a connectionless deliv ery sc heme, hence its use in applications is done trusting that the source of pac k ets is from the actual sender. Since it is not mandatory that only a mem b er of a m ulticast group should send pac k ets to a m ulticast group, there is no easy w a y to authen ticate the pac k ets deliv ered using ordinary m ulticast. Also, some applications require secrecy e.g., a highly conden tial video conference. Moreo v er, access con trol migh t b e desired in some applications, including conden tial collab oration and cases in whic h the service pro vider in tends to c harge the customer for con ten t deliv ery Se cur e multic ast is the term used to indicate a m ulticast service pro viding the aforemen tioned securit y features. Secure m ulticast is generally ac hiev ed b y providing a symmetric cryptographic k ey called a session k ey to the group mem b ers, and b y sending the group data encrypted using the session k ey Th us only the legitimate group mem b ers will b e able to decipher the group data. The essen tial k ey managemen t requiremen ts for m ulticast applications is explained in c hapter 2. The task of pro viding secure m ulticast is divided in to t w o ma jor subtasks: secure k ey distribution and secure k ey managemen t. Secure k ey distribution in v olv es distributing the session k ey securely to legitimate group mem b ers. Secure k ey 1

PAGE 13

2 managemen t in v olv es generating the session k ey and facilitating k ey up dates in an ecien t manner. This thesis explains the imp ortan t con tributions that ha v e b een made in the eld of secure m ulticast in c hapters 4, and 5. Multicast pac k et deliv ery is based on the m ulticast deliv ery tree formed b y the m ulticast routing proto col. Hosts and routers use a group managemen t proto col to manage group mem b ership information. Brief tutorials of the widely implemen ted m ulticast routing proto col, Proto col Indep enden t Multicast Sparse Mo de (PIM-SM) [1], and the group managemen t proto col, In ternet Group Managemen t Proto col v ersion 3 (IGMPv3) [2], are pro vided in c hapter 3 to dra w a roadmap along whic h a deplo y able solution for secure m ulticast ma y b e ac hiev ed. The prop osed pragmatic framew ork for scalable secure source sp ecic m ulticast is explained in c hapter 6, and the p ossible future w ork and extensions, and conclusions are pro vided in c hapter 7 concludes the thesis.

PAGE 14

CHAPTER 2 KEY MANA GEMENT REQUIREMENTS F OR MUL TICAST APPLICA TIONS Multicast applications use a Group Key Managemen t Proto col (GKMP) to pro vide the legitimate mem b ers with the up-to-date cryptographic state they need for their secrecy and authen ticit y requiremen ts. The follo wing is the list of requiremen ts for suc h a k ey managemen t solution for m ulticast applications: Join Se cr e cy : this ensures that the new mem b er cannot decipher past messages, th us mandates that a new session k ey b e used for eac h mem b er addition; L e ave Se cr e cy : this ensures that an old mem b er cannot decipher future messages, th us mandates that a new session k ey b e used for eac h mem b er deletion; Sour c e A uthentic ation : this enables eac h receiv er to v erify the authen ticit y of origin of eac h message; A c c ess Contr ol : this ensures that only legitimate mem b ers can access the group data; Memb er de-r e gistr ation : this is essen tial for most commercial m ulticast applications, in whic h mem b er de-registration is used for billing information; lea v e secrecy has to b e main tained after mem b er de-registration. The follo wing is the list of essen tial ev aluation criteria for k ey managemen t solutions. A more exhaustiv e list can b e found in Mo y er et al. [3], Canetti et al. [4]. Numb er of keys with a c ontr ol ler : Apart from the common session k ey the group con troller/k ey serv er (GCKS) main tains more k eys to enable ecien t k ey up dates; Numb er of keys with e ach gr oup memb er : Apart from the common session k ey eac h mem b er main tains more k eys to enable ecien t k ey up dates; 3

PAGE 15

4 Communic ation c omplexity for a join : This is an estimate of n um b er of messages that ha v e to b e sen t b y the GCKS for eac h mem b er join; Communic ation c omplexity for a le ave : This is an estimate of n um b er of messages that ha v e to b e sen t b y the GCKS for eac h mem b er remo v al; Computation c omplexity for a join : This is an estimate of n um b er of cryptographic op erations that ha v e to b e done for eac h join. Separate estimates are giv en for GCKS and for a mem b er. Computation c omplexity for a le ave : This is an estimate of n um b er of cryptographic op erations that ha v e to b e done for eac h lea v e. Separate estimates are giv en for GCKS and for a mem b er. This list enables one to ev aluate dieren t k ey managemen t and k ey distribution sc hemes for scalabilit y

PAGE 16

CHAPTER 3 MUL TICAST R OUTING AR CHITECTURE Multicast pac k et deliv ery is based on the m ulticast deliv ery tree formed b y a m ulticast routing proto col. A group managemen t proto col is used b y the hosts and the routers to manage group mem b ership information. The follo wing is a brief o v erview of IGMPv3 [2], whic h is the group managemen t proto col for IPv4, and PIM-SM [1], whic h is the most widely implemen ted m ulticast routing proto col. 3.1 IGMPv3 Multicast addresses are class D IP addresses in IPv4. The address 224.0.0.0 is guaran teed not to b e assigned to an y group, and 224.0.0.1 is used as the group for all IP hosts; i.e., all the hosts and routers are mem b ers of this group. The follo wing lists the messages sen t b y the hosts. All the IGMP messages are sen t with TTL 1, and hence will not b e forw arded outside the subnet. Memb ership R ep orts : The host can send a mem b ership rep ort to the router indicating the group address and/or list of the sources of in terest for that m ulticast group. IGMPv3 adds supp ort for sour c e fltering ; i.e., the abilit y for a system to rep ort in terest in receiving pac k ets only from sp ecifc source addresses, or from all but sp ecifc source addresses, sen t to a particular m ulticast address. The source fltering information is used b y the m ulticast routing proto cols to a v oid deliv ering m ulticast pac k ets from sp ecifc sources to net w orks where there are no in terested receiv ers. Mem b ership rep orts are sen t either due to a mem b ership query sen t b y the router or due to mem b ership status c hanges in the host. A single mem b ership rep ort ma y con tain the information p ertaining dieren t m ulticast groups, or that of just a single m ulticast group. L e ave Gr oup : IGMPv2 sp ecifes a separate lea v e group message; in IGMPv3 a host can lea v e from a group b y sending a mem b ership rep ort indicating that it excludes all the sources of a particular m ulticast group. The follo wing lists the messages sen t b y the routers. 5

PAGE 17

6 Gener al Query : This is sen t b y a router to learn the complete m ulticast reception state of the hosts. Gr oup-Sp e cic Query : This is sen t b y the router to learn the reception state of the hosts with resp ect to a single m ulticast address. Gr oup-and-Sour c e-Sp e cic Query : This is sen t b y the router to learn if an y of the hosts in tend to receiv e messages from a particular source of a particular group. The General Query is sen t p erio dically b y the router to the m ulticast address 224.0.0.1, while the other t w o query messages are sen t only to the particular m ulticast group address it in tends to query and are sen t due to mem b ership c hanges. 3.2 PIM-SM The op eration of PIM-SM can b e explained with ease if the design considerations of this routing proto col are understo o d. These in turn are based on the merits and limitations of t w o other m ulticast routing proto cols briery explained b elo w. The Distance V ector Multicast Routing Proto col (D VMRP) is a m ulticast routing proto col that used a source-sp ecic tree for data deliv ery A source-sp ecic tree is the shortest path tree built with the source for the m ulticast group as the ro ot, the m ulticast routers as non-lea v es and the mem b ers as lea v es. The shortest path tree, whic h is a spanning tree ro oted at the source, is referred to as Rev erse Shortest P ath T ree (RSPT), based on the metho d used to build suc h a tree. RSPTs are b est suited for high data rate sources, and are to b e constructed for eac h of the sources of the m ulticast group. The Core Base T ree (CBT) is a m ulticast routing proto col that uses a shared tree built for the en tire m ulticast group for data deliv ery This single tree is used b y all the sources of the m ulticast group. The shared tree is w ell suited for a large n um b er of lo w data rate sources, and results in trac concen tration as all the pac k ets from all the sources are deliv ered through the same shared tree.

PAGE 18

7 PIM is designed to mak e use of b oth the shared tree and shortest path trees for data deliv ery The c hoice of whic h of the trees to use dep ends on the data rate of the source. Initially only the shared tree will b e created for the en tire group, and an RSPT will b e created only if the data rate of a particular source at whic h the tree will b e ro oted exceeds a threshold. Th us creation of RSPTs is data-driv en. After the creation of the RSPT for a source, this tree will b e used to deliv er pac k ets from that source to the m ulticast group. P ac k ets from the other sources will con tin ue to use the shared tree of the m ulticast group. If the data rate of the source for the RSPT falls b elo w the threshold, the shared tree will b e used for subsequen t pac k et deliv ery PIM op eration using an RSPT is referred as PIM-Dense Mo de (PIM-DM), and the op eration using the shared tree is called PIM-Sparse Mo de (PIM-SM). PIM-SM requires predetermined p er-group Rendezv ous P oin ts (RPs) for the creation of shared trees. When a host sends the IGMP join message to its Designated Router (DR), the router sends the PIM join message to w ards the RP adv ertised for the particular group. In termediate routers pro cess this message, resulting in the creation of a branc h from the RP to the DR used for pac k et deliv ery A similar branc h will b e created b et w een the source of the m ulticast group and the RP Th us when a source sends pac k ets at lo w data rates, the pac k ets reac h the RPs and are sen t to the other DRs for deliv ery to the mem b ers. When the data rate exceeds a threshold, the creation of an RSPT ro oted at the DR connected to the source is triggered at the DRs. PIM Prune messages are sen t to w ards the RP and PIM join messages are sen t to w ards the DRs forming the next hop of the RSPT. Figure 3.1 sho ws an example PIM-SM tree structure. The con tin uous lines represen t edges of the shared tree and dashed lines represen t the edges of the shortest path tree.

PAGE 19

8 DR DR DR DR DR DR DR DR DR DR DR RP S Figure 3.1: An example of a group-shared and source-sp ecic tree using PIM 3.3 Summary This c hapter briery explained IGMPv3 and PIM-SM. IGMPv3 is the group managemen t proto col for IPv4, and is used b y the routers and hosts to manage the group mem b ership information. IGMPv3 queries and rep orts w ere explained briery Multicast pac k ets are deliv ered using a m ulticast deliv ery tree formed b y a m ulticast routing proto col. PIM-SM is the most widely deplo y ed m ulticast routing proto col. PIM-SM uses a group shared tree for lo w er bit rate pac k et deliv ery and a source sp ecic tree for higher bit rate pac k et deliv ery

PAGE 20

CHAPTER 4 MUL TICAST KEY DISTRIBUTION: EXISTING SOLUTIONS This section explains imp ortan t arc hitectural framew orks for secure m ulticast. These arc hitecutral framew orks enable the session k ey to b e distributed securely to legitimate group mem b ers. Existing solutions are also analyzed for ease of deplo ymen t. 4.1 Iolus F ramew ork Iolus [5] partitions the m ulticast group in to a hierarc h y of subgroups, eac h with relativ ely few mem b ers and its o wn separate m ulticast address. The tree is comprised of Group Securit y Agen ts (GSAs). The ro ot of the tree is called the Group Securit y Con troller (GSC), and the other GSAs are called Group Securit y In termediaries (GSIs). The GSI of a subgroup manages the subgroup's k eys and mediates all the comm unication b et w een its subgroups and other subgroups. 4.1.1 Group Initialization and Mem b er Addition A t rst, only the GSC exists, and all the GSIs are a w are of the GSC's unicast address. When there is a request to a GSA from an outsider to join the group, after c hec king with its Access Con trol List (A CL), it generates a new session k ey sends it via secure unicast to the new mem b er, and encrypted with the old k ey it is m ulticast to the existing mem b ers. If the GSA is the GSI, and if the curren t request is the rst join request, then the GSI joins a higher lev el m ulticast group, pro ceeding un til a subtree is formed with GSC. The GSIs are supplied with the A CLs to pro cess joins lo cally 4.1.2 Mem b er Deletion On mem b er deletion, the lo cal GSI generates a new session k ey and giv es it to the remaining n mem b ers in the subgroup separately via secure unicast. Ev en 9

PAGE 21

10 though the time complexit y for this is O ( n ) it is not bad, as the size of the en tire m ulticast group can b e m uc h larger than n If this remo v al results in no mem b er for the subgroup, then the GSI lea v es the tree. 4.1.3 Data T ransmission The source m ulticasts directly within its subgroup, and eac h GSI rem ulticasts to the other subgroup in whic h it is a mem b er. Since the other subgroup uses a dieren t session k ey the GSI m ust decrypt the data with the k ey of one subgroup and encrypt with the k ey of the other subgroup b efore m ulticasting. Instead of doing this for the en tire message, the source m ulticasts f K r and g K sk 1 f Data g K r and where K r and is the random k ey generated b y the source for eac h message, and K sk 1 is the session k ey of the subgroup. The GSI of the subgroup decrypts f K r and g K sk 1 and rem ulticasts f K r and g K sk 2 f Data g K r and to the other subgroup with K sk 2 as its session k ey Th us, only the random k ey has to b e encrypted eac h time with a dieren t k ey Figure 4.1 sho ws data transmission from a source in subgroup G 2 A to the en tire group. 4.1.4 Merits of the Iolus F ramew ork The adv an tanges of the Iolus framew ork are listed b elo w. This arc hitecture lo calizes the eect of group mem b ership c hanges to one sub-group. It distributes the securit y o v er man y no des, eliminating an y single p oin t of failure except the top-lev el GSC. The use of the lo cal session k eys as Key Encrypting Keys (KEKs) in data deliv ery remo v es the burden of decrypting and encrypting the en tire data pa yload at eac h GSA. 4.1.5 Limitations of the Iolus F ramew ork The dra wbac ks of the Iolus framew ork are listed b elo w. The GSC still remains as a single p oin t of failure.

PAGE 22

11 Figure 4.1: Data transmission in Iolus Re-k eying on mem b er departure tak es O ( n ) messages, where n is the n um b er of remaining mem b ers in the subgroup. Ev en though this can b e m uc h smaller than the en tire group size, there m ust b e n umerous GSIs to reduce the n um b er of mem b ers in eac h subgroup. The framew ork fails to men tion where the GSIs ha v e to b e placed in the actual m ulticast deliv ery tree created b y m ulticast routing proto cols. This is v ery imp ortan t b ecause the seman tics of op erations b ecome blurred if the GSIs can b e outside the subnets and a w a y from the actual deliv ery tree created b y the m ulticast routing proto cols. In this case the GSIs ha v e to b ecome the mem b ers of the global m ulticast tree but the routing proto cols ha v e to b e c hanged so that the pac k ets are not sen t directly to the mem b ers but only through the GSIs. Eac h GSI has to b e a mem b er of a separate subgroup. When an outsider in tends to b ecome a mem b er of a global group, he has to join a lo cal subgroup. The mapping b et w een the lo cal subgroup and the global group has to b e dened.

PAGE 23

12 The requiremen t for dieren t subgroups results in use of m ultiple m ulticast addresses for the single global m ulticast group. Since no routing proto cols are designed this w a y GSIs ha v e to tak e resp onsibilit y for routing pac k ets. 4.1.6 Summary Iolus is the m ulticast k ey distribution framew ork whic h is highly scalable. The comp onen ts and op eration of Iolus is explained. The ev aluation of Iolus with deplo ymen t as the core ev aluation criteria is done and it indicates that this arc hitecture cannot co-exist with the already deplo y ed m ulticast routing proto cols lik e PIM-SM. 4.2 Group Key Managemen t Arc hitecture (GKMA) GKMA [6] in tends to dene a common arc hitecture and design for dieren t Group Key Managemen t Proto cols (GKMPs) for in ternet, transp ort, and application services. GKMP enables only the mem b ers (senders and receiv ers) of a secure m ulticast group to gain access and authen ticate the group data. This design is based on a group con troller mo del with a single group o wner as the ro ot of trust. The group o wner designates a group con troller for mem b er registration and re-k ey 4.2.1 Ov erview The GKMP pro vides the group mem b ers with an up-to-date Data Securit y Proto col Securit y Asso ciation (SA) or Data SA, whic h con tains the information necessary to secure the group data. The con ten ts of the Data SA is giv en in 4.2.2. T o ac hiev e this goal, the GKMA consists of the follo wing proto cols: Registration Proto col; Re-k ey Proto col; Data Securit y Proto col. Registration proto col (RP). The RP is a t w o-w a y unicast proto col b et w een the Group Con troller/Key Serv er (GCKS) and a joining mem b er. The RP uses the Registration Proto col SA to ensure that the transfer of information from GCKS to

PAGE 24

13 mem b er is done in an authen ticated and conden tial manner. The RP facilitates m utual authen tication b et w een GCKS and a joining mem b er, and allo ws v ercation of authorization of a joining mem b er. Up on successfull authen tication and authorization v erication, the GCKS pro vides the joining mem b er with sucien t information to initialize a Re-k ey Proto col SA with the joining mem b er if the Group Securit y P olicy (GSP) calls for it, and sucien t information to initialize a Data Securit y Proto col SA with the joining mem b er. Re-k ey proto col (RKP). RKP is an optional proto col and is used b y GCKS p erio dically to send re-k ey information to the group mem b ers due to mem b ership c hanges or expiry of the T rac Encrypting Keys (TEK). Re-k ey messages are protected b y the Re-k ey Proto col SA. The messages are either sen t b y m ulticast to group mem b ers or are unicast to a particular group mem b er. RKP is optional as other means for managing the k eys lo cally without in teraction b et w een the GCKS and mem b er ma y b e used. The re-k ey messages are to b e deliv ered in a timely manner and should sub jected to source authen tication. Data securit y proto col (DSP). DSP uses the TEK to secure the group data. 4.2.2 Detailed Description Eac h group mem b er uses the RP to obtain authorized, authen ticated access to a particular group, its p olicies, and its k eys. The t w o t yp es of group k eys are: Key Encrypting Key (KEK): this k ey is used b y the re-k ey proto col, and is used to encrypt the TEK; T ext Encrypting Key (TEK): this k ey is used b y the Data Securit y Proto col (DSP) to protect the group data. Group Securit y Asso ciation (GSA). The GCKS is a separate, logical en tit y that p erforms mem b er authen tication and authorization according to the group p olicy that is set b y the group o wner. The GCKS creates the KEK and TEK, and sends

PAGE 25

14 Figure 4.2: Group Securit y Asso ciation Mo del them to the joining mem b er. Up on receipt of a TEK from a re-k ey message or a Registration Proto col exc hange, the mem b er's group k ey managemen t will pro vide a securit y asso ciation to a Data Securit y Proto col for the data sen t from the sender to the receiv er. In Figure 4.2, the Securit y Proto col SA protects the data sen t on the arc lab eled \D A T A SECURITY PR OTOCOL," the Re-k ey SA protects the data sen t on the arc lab eled \RE-KEY PR OTOCOL," and the Registration Proto col SA protects the RP exc hanges. These three SAs comprise the Group Securit y Asso ciation. The p olicy and authorization infrastructures indicated in Figure 4.2 are external to GKMP The group-p olicy will b e distributed through b oth announcemen t and k ey managemen t proto cols [7]. The group-p olicy con tains at least the follo wing:

PAGE 26

15 group o wner, authen tication metho d, and delegation metho d for iden tifying a GCKS for the group; group GCKS, authen tication metho d, and an y metho d used for delegating other GCKSs for the group; group mem b ership rules or list and authen tication metho d. It also con tains t w o additional p olicy-related requiremen ts external to group k ey managemen t: authorization and authen tication infrastructure suc h as Simple Public Key Infrastructure (SPKI)[8 ]or pre-shared k ey sc heme in accordance with the group p olicy for a particular group; an announcemen t mec hanism for secure groups and ev en ts that op erates according to group p olicy for a particular group, (for example Session Description Proto col (SDP)). Con ten ts of Re-k ey SA. The Re-k ey SA protects the Re-k ey proto col. It con tains the follo wing: Re-k ey SA p olicy: the mem b ership managemen t algorithm that enforces forw ard and bac kw ard access con trol, the KEK encryption algorithm, the authen tication algorithm, the con trol group address, the re-k ey serv er address; Group Iden tit y: to iden tify the group if m ultiple groups can b e initialized in a single in v o cation of the RP or RKP; KEKs and their lifetimes; GCKS authen tication k ey: a symmetric k ey or public k ey for authen tication of the re-k ey messages; sequence n um b ers: for repla y protection; Securit y P arameter Index (SPI): the triple (Group Iden tit y SPI, an iden tier for \Re-k ey SA") that uniquely iden ties an SA. Con ten ts of the Data SA. The Data SA protects the group data. It con tains the follo wing: Group Iden tit y: to iden tify the group if m ultiple groups can b e initialized in a single in v o cation of the RP or RKP;

PAGE 27

16 source iden tit y: to iden tify the source for the group; trac encrypting k ey; authen tication k ey; sequence n um b ers: for repla y protection; Securit y P arameter Index (SPI):the triple (Group iden tit y SPI, an iden tier for \Re-k ey SA") that uniquely iden ties an SA; Data SA p olicy The Data SA p olicy includes encryption algorithm and parameters, the source authen tication algorithm and parameters, the group authen tication algorithm and parameters, and/or repla y protection information. 4.2.3 Merits of GKMA The implemen tation of the proto cols is not dep enden t on the arc hitecture, allo wing the requiremen ts of the application to dictate the proto col op eration. F or example, a re-k ey proto col for a small group could use m ultiple unicast transmissions with symmetric authen tication, while that for a large group could use IP Multicast with pac k et-lev el forw ard error correction and source authen tication. There is no need for a unicast exc hange to pro vide data k eys to existing mem b ers of the group. Data k eys can b e pushed in the Re-k ey Proto col. This allo ws fast rek eying for existing mem b ers. The authorization infrastructure can supp ort delegation, as do es SPKI. This hierarc hically-organized k ey distribution with m ultiple GCKSs can handle \rash-cro wds." 4.2.4 Limitations of GKMA Handling departing mem b ers. The follo wing p oin ts list the limitations of GKMA in the w a y it handles departing mem b ers. If the departing mem b er fails to rep ort to the GCKS that it is no longer in the group, the GCKS m ust w ait un til the SAs time out b efore freeing up the asso ciated data structures and timers.

PAGE 28

17 The timeouts for the SA expiry cannot b e v ery small as this w ould p ose considerable o v erhead for the GCKS, since it usually handles SAs of n umerous mem b ers. If the group is for a paid service, the GCKS uses the time of SA remo v al for billing information. If the mem b er fails to rep ort its departure to GCKS the mem b er will b e exp ected to pa y un til the SA expires, ev en though it w as not a mem b er for the in terv ening time. In large-scale m ulticast applications, de-registration is an essen tial service (e.g, for billing information), and th us has the p oten tial to cause implosion at the GCKS. Handling rash cro wds. Ev en though GKMA sp ecication indicates that m ultiple GCKSs can b e used b y delegation to handle rash cro wds, it lac ks the means to handle a ro o d of departing mem b ers (discussed ab o v e) in a satisfactory w a y Moreo v er, additional proto cols are required b et w een the dieren t GCKSs to generate the same k eys on mem b er joins or lea v es based on the group p olicy as the source will b e using a single k ey to encrypt group data. Dynamic groups. Dynamic groups in v olv e m ultiple join and lea v e requests o v er a short p erio d of time. A single GCKS cannot handle this as k ey generation requires a considerable amoun t of time. This dela y ma y result in more lea v e requests w orsening the situation. In the w orst case scenario, the source ends up w aiting for the k ey from the GCKS rather than sending group data. 4.3 General Limitations of an y GKMP This section discusses the general limitations of an y GKMP [6]. 4.3.1 Group Secrets Group mem b ers are trusted to preserv e the group secrets. It is v ery dicult to nd if a legitimate mem b er has disclosed the group secrets to an outsider, and if suc h an outsider is listening to the group data. Moreo v er, authen tication b y symmetric k eys should b e a v oided unless all the group mem b ers can b e trusted. 4.3.2 P olicy Complexit y Unlik e p eer-to-p eer securit y p olicy whic h is an in tersection of the p olicy of the individual p eers, a group o wner sets the group p olicy externally The c hoice of the

PAGE 29

18 group p olicy p oses new risks to the mem b ers of the group. The group o wner and mem b ers need to determine minimal acceptable lev els of trust, authen ticit y and conden tialit y for the group. 4.4 Summary GKMA denes a common arc hitecture and design for dieren t GKMPs. The comp onen ts and op eration of GKMA is explained. The ev aluation of GKMA with deplo ymen t as the core ev aluation criteria indicates that it do es not handle burst y and rash cro wds for dynamic m ulticast groups. General limitations of an y GKMP with resp ect to group secrets and p olicy complexit y is explained.

PAGE 30

CHAPTER 5 MUL TICAST KEY MANA GEMENT: EXISTING SOLUTIONS In secure m ulticast, join and lea v e secrecy m ust b e main tained, whic h in v olv es generating a new session k ey used for subsequen t encryption of the group data, and distributing the new session k ey securely to the remaining mem b ers. Secure k ey managemen t in v olv es generating the session k ey and facilitating k ey up dates in an ecien t manner. In this section a naiv e k ey managemen t sc heme is explained rst to emphasize the scalabilit y requiremen ts of the k ey managemen t sc hemes. A detailed explanation of the tree-based solution using Bo olean function minimization is giv en. Detailed explanations of other tree based solutions are co v ered in a previous surv ey of securit y issues in m ulticast comm unications [3]. Mem b er de-registration, as explained earlier, in v olv es preserving lea v e secrecy Since most m ulticast applications in v olv e burst y joins and lea v es, it is essen tial to pro vide cumulative memb er r emoval for scalabilit y reasons. The tree-based tec hnique using Bo olean function minimization pro vides suc h a solution. Other k ey managemen t solutions are explained in W allner et al. [9]. 5.1 Naiv e Key Managemen t Here, the GCKS stores n + 1 k eys: the common session k ey and one for eac h of the n mem b ers. F or eac h join or lea v e, the GCKS securely unicasts the new group k ey to eac h mem b er, so the computation and comm unication complexit y in GK C are eac h O ( n ). Clearly this sc heme do es not scale w ell for applications with n umerous mem b ers and in v olving burst y joins and lea v es. 5.2 T ree Based Solution Using Bo olean F unction Minimization In the tree-based solution using Bo olean function minimization [10], the GCKS main tains a complete balanced binary tree where the N lea v es are attac hed to 19

PAGE 31

20 another N no des represen ting the N mem b ers of the group. Eac h of the N mem b ers is giv en an unique UID represen ted b y a binary string of length n = d l og 2 N e Eac h nonleaf no de in the tree con tains an auxiliary k ey A mem b er with UID X n 1 X n 2 :::X 0 receiv es the common session k ey SK, and the set of n auxialiary k eys K n 1 ; K n 2 ; :::; K 0 where K i is k i if X i = 1, and k 0 i if X i =0. The auxialiary k eys are used to up date the session k ey in secure fashion. F or example, in Figure 5.1, the mem b er c 0 with UID 000 will ha v e SK, k 0 2 k 0 1 k 0 0 and the mem b er c 6 will ha v e SK, k 2 ; k 1 ; k 0 0 So the GCKS main tains 2 l og 2 N auxiliary k eys, and eac h mem b er will main tain l og 2 N auxiliary k eys. 5.2.1 Individual Mem b er Remo v al F or eac h mem b er remo v al the GCKS sends l og 2 N messages. F or example, to remo v e a mem b er c 5 with UID 101, the GCKS sends the new session k ey S K new encrypted with k 0 0 ; k 1 ; k 0 2 c 5 cannot decrypt an y of these three messages as it has only k 0 ; k 0 1 and k 2 Figure 5.1 sho ws a visual in terpretation of this re-k eying sc heme. In the gure, the k eys corresp onding to the solid round no des corresp ond to the k eys p ossessed b y the departing mem b er c 5 The hatc hed round no des represen t the complemen tary set, that is, the k eys not p ossessed b y c 5 Since the lea ving mem b er could listen to future k ey up dates, the auxiliary k eys are also up dated. T o up date a k ey K i a one w a y hash function f is used that yields the up dated auxialiary k ey as follo ws K i new = f ( K i ; S K new ). Since the lea ving mem b er do es not ha v e the new session k ey SK, it will not b e able to compute the new auxiliary k ey 5.2.2 Remo v al of Multiple Mem b ers An ecien t w a y to remo v e m ultiple mem b ers uses Bo olean function minimization. F or example, if mem b ers c 0 and c 4 with UIDs 000 and 100, resp ectiv ely are to b e remo v ed from the group, the new k ey S K new has to b e giv en securely to c 1 ; c 2 ; c 3 ; c 5 ; c 6 ; c 7 It is enough if GCKS sends f S K new g k 0 ; f S K new g k 1

PAGE 32

21 Figure 5.1: Key Up date in a group of size 8 for departure of c 5 The rst message can b e decrypted only b y c 1 ; c 3 ; c 5 and c 7 and the second only b y mem b ers c 2 ; c 3 ; c 6 and c 7 Th us the remaining mem b ers can b e up dated with the new k ey using only t w o messages instead of six messages. Figure 5.2 depicts this scenario. Figure 5.2: Example of departure of m ultiple mem b ers Bo olean function minimization. Cum ulativ e mem b er remo v al is equiv alen t to grouping the remaining mem b ers that share common bits in the UID, and hence common k eys, whic h are dieren t from those p ossessed b y the remo v ed mem b ers. This problem is equiv alen t to Bo olean function minimization. Metho ds for

PAGE 33

22 minimizing the Bo olean function can b e used to nd the minim um n um b er of messages to b e sen t. 5.2.3 Collusion A ttac ks In collusion attac k, a set of remo v ed mem b ers collude and b y com bining their sets of k eys, and ma y b e able to obtain the curren tly v alid set of k eys. This will enable them to listen to the group comm unication. It is imp ossible to eliminate the risk of a collusion attac k with less than O ( N ) auxiliary k eys [10]. The risk of collusion attac k ma y b e reduced with a large auxiliary k ey space and a sparse distribution of UIDs. 5.2.4 P erformance Analysis Detailed pro of for the follo wing p erfomance analysis results is giv en in Chang et al. [10 ]. W orst case p erformance. Re-k eying a secure m ulticast group of size 2 n when t w o group mem b ers are to b e remo v ed requires at most n messages, and when 2 n 1 mem b ers are to b e remo v ed, it requires at most 2 n 1 messages. Av erage case p erformance. The a v erage n um b er of messages required for aggregate remo v al of an arbitrary n um b er of mem b ers from a m ulticast group is equiv alen t to a v erage n um b er of pro ducts in the minim um sum-of-pro ducts expressions of Bo olean functions. Extensiv e pro of of this is giv en in [10 ] 5.3 Summary Secure k ey managemen t in v olv es in generating the session k ey and facilitating k ey up dates in an ecien t manner. It also helps in main taining join and lea v e secrecy A naiv e k ey managemen t tec hnique is explained to pro vide an insigh t on the complexit y requiremen ts of secure k ey managemen t. A tree based solution using Bo olean function minimization is explained as it solv es the cum ulativ e mem b er remo v al in an ecien t manner. Cum ulativ e mem b er remo v al is the most desirable feature for large dynamic groups in whic h the lea v es are burst y Other

PAGE 34

23 op erations are also done in logarithmic time complexit y with few er n um b er of k eys to b e main tained in the GCKS and the mem b ers compared to other k ey managemen t tec hniques.

PAGE 35

CHAPTER 6 A PRA GMA TIC FRAMEW ORK F OR SCALABLE SECURE SOUR CE SPECIFIC MUL TICAST The previous discussions of k ey distribution and k ey managemen t w ere fo cussed mainly on scalabilit y Giv en the merits and limitations of v arious sc hemes, and with the m ulticast routing arc hitecture in mind, this section prop oses a framew ork for scalable k ey distribution and managemen t for secure m ulticast. 6.1 Design F eatures and Requiremen ts Scalabilit y is the driving force b ehind this framew ork. Muc h emphasis is giv en for the framew ork to b e pragmatic b y considering only the widely deplo y ed proto cols for routing and mem b ership. The design features and requiremen ts are giv en b elo w. Scalabilit y Core ideas from Iolus and GKMP discussed in section 4 ha v e b een used in the prop osed k ey distribution framew ork. The k ey managemen t sc heme using Bo olean function minimization discussed in section 5.2 is used as it has man y desirable features suc h as cumm ulativ e mem b er remo v al, and b etter complexit y than other sc hemes. Ease of deplo ymen t. The framew ork is designed considering the w orking mo des of widely deplo y ed proto cols suc h as PIM-SM and IGMPv3. The en tire framew ork b ecomes more scalable b y using the messages of these proto cols. The framew ork is free of the limitations listed earlier in subsection 4.2.4. Wh y source sp ecic m ulticast? In source sp ecic m ulticast [11 ] [12], there is only one source S, for the en tire group G. The group data sen t b y the source to the group is said to form a stream/c hannel iden tied b y the (S,G) pair. The other group mem b ers can b ecome subscrib ers of this c hannel b y using IGMPv3 [2] for 24

PAGE 36

25 IPv4 and MLDv2 [13 ] for IPv6 proto cols. The m ulticast deliv ery tree will b e built b y PIM-SM [1], the most widely deplo y ed m ulticast routing proto col. Based on the previous discussion of PIM-SM, SSM mostly results in using the source sp ecic tree created for eac h (S,G). An y source m ulticast (ASM) is not considered in this prop osal, where an y mem b er can b e a source for the group. The seman tics of op eration of secure ASM is v ery m uc h dieren t from that of secure SSM. The presence of a single source to the group in SSM suits w ell with man y of the applications ha ving a p oten tial to ha v e m ultiple receiv ers and requiring access con trol. 6.2 Key Distribution 6.2.1 F ramew ork Large dynamic groups do not scale w ell if a single k ey serv er is used. Dynamic here denotes that the there is no restriction for the group mem b ers to join at a particular time of the group existence or to remain in the group for a p erio d of time. Dynamic groups usually ha v e burst y joins and lea v es. Multicast groups are often denoted b y a pair ( ; G ) or b y ( S; G ). Here represen ts an y source for the m ulticast group G and S represen ts a single source S for the m ulticast group G. A mem b er of a m ulticast group G listening to the messages sen t b y a source S is said to b e a subscrib er of the ( S; G ) c hannel. In this framew ork, a secure distribution tree lik e that of Iolus is used. The cen tral GCKS ma y b e replicated, and in suc h a case an election algorithm is used to select a primary GCKS. The election algorithm ma y b e simple: the GCKS with the smallest IP address v alue is selected as the primary The lo cal k ey serv ers (LKSs) are sen t the list of IP addresses of the GCKSs. Eac h LKS can pic k a random GCKS and comm unicate with it. The LKS has to b e presen t in the listening zone of IGMPv3. Listening zone here means that the LKS should b e able to listen to the IGMPv3 messages sen t b y the mem b ers, outsiders, and b y the

PAGE 37

26 m ulticast-a w are routers. This enables an LKS to nd the presence or absence of group mem b ers subscribing to an ( S; G ) c hannel immediately There can b e m ultiple LKSs within the listening zone, and an LKS can also b e presen t as a part of the m ulticast a w are router. Since the LKSs are presen t in eac h of the listening zones, the lo cal c hanges in mem b ership aect only the lo cal session k ey and not the global session k ey The LKS here do es the same op eration as that of GSI in Iolus. The list of LKSs is sen t to the joining mem b er after initial IGMPv3 join request, then the joining mem b er pic ks a random LKS from the list of LKSs sen t b y the primary LKS and comm unicates with it. Figure 6.1 sho ws an example of the prop osed framew ork. In the gure, solid lines represen t the group shared tree created b y PIM for a m ulticast group, the dashed lines represen t the source-sp ecic tree created b y PIM for a particular source S for a m ulticast group, and the dotted lines represen t the secure unicast connections established b et w een the LKS and the GCKS. The thatc hed circles represen t the primary LKS/GCKS elected b y an election algorithm. 6.2.2 Op erational Ov erview The detailed description of the prop osed framew ork is giv en b elo w. Startup. The framew ork requires the GCKS(s) to b e a v ailable when the group is started. The list of GCKSs, public k ey of GCKS (a single k ey is used b y all the GCKSs), the address of source, and the group address are distributed using a Session Description Proto col (SDP). The GCKS main tains the A CL, whic h is used to pro vide access con trol for the group data. Only those mem b ers who satisfy the access con trol pro cedure will b e pro vided the group k ey and hence will b e able to listen to the group data. Joins. An outsider sends a IGMPv3 join message indicating the pair ( S; G ) to its m ulticast-a w are router. The router uses PIM-SM to join the distribution tree corresp onding to ( S; G ). The primary LKS listening to the IGMPv3 messages will

PAGE 38

27 DRLKS DRLKS HOSTs IGMP HOST IGMP IGMP IGMP IGMP HOSTs LKSs DR HOSTs DRLKS HOSTs HOSTs HOSTs LKS RP GCKSs DR HOSTs LKSs S Figure 6.1: Pragmatic F ramew ork for Scalable Secure Multicast send a list of LKSs to the sender of the join message. The mem b er pic ks a random LKS and establishes secure unicast c hannel with that LKS using proto cols suc h as the IP Securit y Proto col (IPSEC). The mem b er no w uses this secure c hannel to send the required information to satisfy the access con trol pro cedure dictated b y the group p olicy F or example, the message can b e f < username > < passw ord > g P uK GC K S where the < username > and < passw ord > can b e used b y the GCKS to pro vide access to the group data. Since the LKS has no means to v erify access con trol (dictated b y the group p olicy), and it is not realisitic to exp ect GCKS to pro vide suc h A CL related information to ev ery LKS, the mem b er encrypts this information with the public k ey of the GCKS. This ensures that only the GCKS

PAGE 39

28 can decrypt this information as it alone has its priv ate k ey whic h can b e used to decrypt it. 1 The LKS uses the list of GCKSs sen t via SDP pic ks a random GCKS, and establishes a secure unicast c hannel using IPSEC. The LKS uses this secure c hannel to send the encrypted information sen t b y the (p ossible) mem b er. The GCKS v erifes and sends OK/NOK message to LKS. If the returned message is OK then the LKS no w starts k ey managemen t service and pro vides the mem b er with the secure k ey If not, the failure is indicated to the rejected mem b er and the SAs corresp onding to this sender are remo v ed. The LKS need not send the information sen t b y the p ossible mem b er to GCKS immediately; rather it ma y collect man y suc h requests to join, and send them as a bulk request to the GCKS. In this case the LKS assigns a nonce 2 as the pac k et ID, and the GCKS replies with the same pac k et ID with OKs/NOKs in the same order as that of the corresp onding request, so that the LKS can matc h the p osition of the requests it sen t with that of the replies it has receiv ed and tak e appropriate actions. Usually the joins are burst y and hence this tec hnique reduces the burden on LKS and GCKS. If the curren t request sen t b y the p ossible mem b er is the frst one, then the LKS establishes a secure unicast c hannel with a randomly pic k ed GCKS and uses it for all future comm unication. Lea v es. When a mem b er sends a IGMPv3 lea v e message indicating ( S; G ) c hannel, the primary LKS listening to this message immediately remo v es the SA corresp onding to this mem b er and sends a mem b er lea v e request to the GCKS, 1 In the priv ate, public cryptographic k ey pair, if one is used for encryption the other one can b e used for decryption 2 nonce denotes the non-rep eating, random sequence used in secure comm unication to distinguish dieren t messages

PAGE 40

29 whic h in turn uses it for accoun ting purp oses. The LKS also starts the k ey managemen t service to pro vide the remaining mem b ers with the new session k ey The router pro cessing the IGMPv3 lea v e messages sends messages to nd if there are an y other listeners for this ( S; G ) c hannel, and if there is no resp onse, remo v es itself from the global distribution tree using PIM-SM. The LKS listening to the IGMPv3 messages remo v es an y remaining SAs for this ( S; G ) c hannel, sends the list of mem b ers it has not heard from, and also indicates to the GCKS that it is no more in the k ey distribution tree as there are no more mem b ers it has to serv e. Th us this tec hnique enables the GCKS to compile nearly accurate billing information (it is men tioned as nearly accurate as IGMPv3 sourceand group-sp ecic queries are sen t, and the conclusion that no mem b er is presen t subscribing to this c hannel is deduced only after a timeout for getting a IGMPv3 rep ort bac k from at least one mem b er subscribing to this c hannel). 6.2.3 Data T ransmission The data transmission sc heme is adopted from the Iolus sc heme. The senders send the messages in this format: f K r and g K LK S 1 f Data g K r and where K r and is the random k ey generated b y the sender, and K LK S 1 is the lo cal session k ey The LKS decrypts and encrypts random k ey with next lev el of lo cal session k ey The message no w will b e: f K r and g K LK S 2 f Data g K r and This tec hnique reduces the necessit y of decrypting and encrypting the whole message eac h time with the new k ey The group mem b ers will decrypt the data after getting the random k ey using the lo cal k ey The m ulticast-a w are router do es the decryption and encryption of the k ey if the LKS is a part of the router itself. If the LKS is a separate en tit y then the m ulticast router sends the pac k et as a unicast to the primary LKS and the LKS m ulticasts the pac k et after decrypting and re-encrypting the random k ey with the lo cal session k ey The router, instead of sending the pac k et as m ulticast, uses the

PAGE 41

30 link address of the primary LKS, so that LKS alone pro cesses it b efore rem ulticasting. 6.3 Key Managemen t Key Managemen t for the en tire m ulticast group is sub divided in to lo cal k ey managemen t tasks done b y LKS to manage the actual mem b ers, and the k ey managemen t task done b y GCKS to manage the global session k ey distributed to the LKSs. The tree-based k ey managemen t sc heme using Bo olean function minimization tec hnique (see section 5.2) ma y b e used as it has the follo wing desirable features. Cumulative memb er r emoval : this is the most desirable feature as mem b er de-registration in most dynamic m ulticast groups tends to b e burst y Numb er of keys maintaine d in the LKS : this measure is (2 l og 2 N ) + 1 where N is the n um b er of mem b ers within LKS's listening zone, whic h is comparitiv ely few er than the n um b er that ha v e to b e main tained in other tec hniques. Numb er of keys maintaine d in the memb er : this measure is ( l og 2 N ) + 1 where N is the n um b er of mem b ers within LKS's listening zone, and is comparitiv ely few er than the n um b er that ha v e to b e main tained in other tec hniques. Better over al l c ommunic ation and c omputation c omplexities : F or N mem b ers in the listening zone of an LKS, the single mem b er join or lea v e tak es O ( l og 2 N ) computation and comm unication complexities, but cum ulativ e mem b er remo v al uses Bo olean function minimization and results in few er messages and hence few er computations to b e done b y LKS and b y the mem b ers. The GCKS also uses Bo olean function minimization to main tain the global session k ey and distributes it to the LKSs. The GCKS need not b e presen t along the global data distribution tree built b y the m ulticast routing proto col PIM-SM; rather, it ma y b e presen t as a separate en tit y visible to the LKSs. Th us the GCKS main tains 2 l og 2 N + 1 k eys, where N is the n um b er of LKSs. The LKSs ha v e to main tain l og 2 N + 1 k eys for this purp ose, where N is the n um b er of LKSs. This set

PAGE 42

31 of k eys is in addition to the set of k eys main tained b y eac h of the LKSs to manage k eys for the actual mem b ers in their listening zones. The analysis of the k ey managemen t tec hnique using Bo olean function minimization indicates that the single mem b er remo v al requires O ( l og 2 N ) computation and comm unication complexities for N mem b ers. A tec hnique to reduce this logarithmic complexit y to a constan t complexit y is prop osed and is explained in section 6.3.1. 6.3.1 Detailed Description The k ey managemen t sc heme prop osed here is an impro v emen t to the sc heme discussed in 5.2. Here also the LKS main tains a k ey distribution tree, with the N mem b ers attac hed to N lea v es. Eac h mem b er is giv en an unique binary string represen ting its UID. The mem b ers ha v e the n = l og 2 N k eys corresp onding to the bits in their UIDs. All the messages sen t b y the LKS use IPSEC, so that they can b e authen ticated. In this prop osal, the LKS sends the new session k ey encrypted with an auxiliary k ey and the mem b ers send the new session k ey encrypted b y other auxiliary k eys according to the algorithm giv en b elo w. The auxiliary k eys are up dated lo cally b y eac h of the mem b er as in section 5.2. 6.3.2 Mem b er Join When a new mem b er is added, the new mem b er is giv en the new session k ey and auxiliary k eys are sen t via secure unicast c hannel established b et w een the LKS and the mem b er. The new session k ey with the UID of the new mem b er is sen t in a single m ulticast pac k et encrypted with the old session k ey All the existing mem b ers will receiv e the new session k eys and will up date the auxiliary k eys according to the UID of the new mem b er.

PAGE 43

32 6.3.3 Individual Mem b er deletion In this prop osal, resp onsibilit y of m ulticasting the new session k ey is shared with the mem b ers. Th us in the b est case, the LKS sends only one k ey up date message, and eac h of the mem b ers will send at most one k ey up date message to the group. F or example in Figure 5.1, for the departure of c 5 the LKS sends f U I D ( c 5 ) f S K new g P r K LK S g k 0 2 where U I D ( c 5 ) = 101 is the UID of the mem b er c 5 S K new is the new session k ey P r K LK S is the priv ate k ey of LKS, and k 0 2 is the auxiliary corresp onding the bit X 2 = 0 in the UID. Th us, with this message, c 0 ; c 1 ; c 2 ; c 3 can up date their session and auxiliary k eys. F rom the U I D ( c 5 ) = 101, it is kno wn that one m ulticast with k 1 where k 1 is the auxiliary corresp onding the bit X 1 = 1 in the UID, another t w o mem b ers can receiv e the session k ey Both c 0 ; c 1 do es not ha v e k 1 but c 2 ; c 3 ha v e k 1 so eac h of them pic ks a random time and bac ks o and when the timer expires sends f U I D ( c 5 ) f S K new g P r K LK S g k 1 If c 2 sends this message, c 3 do es not send this message again. Since the new session k ey is signed b y the priv ate k ey of LKS, it is authen tic. With this message c 6 ; c 7 receiv es the new session k ey Again from the U I D ( c 5 ) = 101, it is kno wn that one m ulticast with k 0 0 where k 0 0 is the auxiliary corresp onding the bit X 0 = 0 in the UID, the remaining mem b er can receiv e the session k ey c 0 ; c 2 ; c 6 already ha v e the new session k ey Eac h of them pic ks a random time and bac ks o, and when the timer expires sends f U I D ( c 5 ) f S K new g P r K LK S g k 0 0 If c 0 sends rst c 2 ; c 6 refrain from sending the same message. Th us c 4 receiv es the new session k ey Eac h mem b er calculates the new auxiliary k eys lo cally The k ey up date messages are sen t as m ulticast, so the LKS will also receiv e the k ey up date messages. If there are no messages sen t b y the mem b ers, then the LKS has to tra v erse the tree and send the new session k ey encrypted with the k ey not held b y the mem b er b eing remo v ed. Th us in the w orst case LKS will b e sending O ( l og 2 N ) messages.

PAGE 44

33 6.3.4 Cum ulativ e Mem b er Deletion The tec hnique using Bo olean function minimization 5.2 results in minimal n um b er of messages to b e sen t for cum ulativ e mem b er deletion. Th us this tec hnique is used in the prop osed framew ork. 6.3.5 T ree Gro wth When a mem b er join results in increase of the heigh t of the KM tree in LKS b y one, the LKS sends the gro wth message to the existing mem b ers with the a new auxiliary k ey whic h is common to all the mem b ers. The message is f K new aux g SK, where K new aux is the new auxiliary k ey and SK is the existing common session k ey This message will also cause all the mem b ers to c hange their UIDs b y prexing a '0' to their existing UIDs. F or example, if the UID of a mem b er is X n 1 X n 2 :::X 0 will b e c hanged to X n X n 1 X n 2 :::X 0 where X n = 0. Clearly K new aux corresp onds to X n = 0. 6.3.6 T ree Shrink age When a mem b er deletion results in only one half of the tree (either left or righ t) to con tain mem b ers, the heigh t of the KM tree in LKS can b e reduced b y one. The LKS sends the shrink age message to the existing mem b ers indicating them to discard the k ey corresp onding to their MSB in UIDs. This also results in the remo v al of the MSB from the UIDs of all the mem b ers. F or example if the UID of a mem b er is X n X n 1 X n 2 :::X 0 then after remo v al of the MSB the UID c hanges to X n 1 X n 2 :::X 0 The k ey corresp onding to X n is also discarded. If the tree is sparsely p opulated b y mem b ers, the half of the tree (either left or righ t) with few er mem b ers is c hosen to b e remo v ed from the tree. LKS sends rejoin messages to those mem b ers and hence remo v es them from the tree and assigns them new UIDs when they rejoin. If b oth the halv es con tain equal n um b er of mem b ers, one half is c hosen randomly

PAGE 45

34 6.4 Prop erties Early Detection of mem b er absence. Since the LKS is presen t in the listening zone of IGMPv3 messages, it can detect the absence of a mem b er and hence the corresp onding SAs can b e remo v ed. This is imp ossible if LKS is outside the listening zone, where the SAs are remo v ed only after timeout. Here, SAs will b e remo v ed ev en if the mem b er crashes; IGMPv3 messages disco v er suc h absences. No access con trol information leak. LKS cannot decrypt this information sen t b y the mem b er to b e sen t to the GCKS. Multiple License made easy Since the LKS can b e placed lo cally an organization can obtain m ultiple licenses for the en tire organization and the LKS need not indulge in k ey managemen t services for eac h mem b er join or deletion. The lo cal k ey can b e k ept constan t, or the LKS can decrypt the en tire message and send to the mem b er. Collusion A ttac ks. Collusion attac ks b y mem b ers still exist as the k ey managemen t tec hnique using Bo olean function minimization is used. 6.5 Summary A pragmatic framew ork for scalable secure source sp ecic m ulticast is prop osed with scalabilit y and ease of deplo ymen t as the core design requiremen ts. The prop osed framew ork is designed to co-exist with the m ulticast routing arc hitecture with IGMPv3 and PIM-SM. The k ey distribution arc hitecture is designed with desirable features from Iolus and GKMA. The prop osed k ey distribution sc heme lo calizes the group c hanges and hence the global session k ey remains mostly constan t while the lo cal session k eys ma y c hange often. The k ey managemen t sc heme follo ws the tec hnique using Bo olean function minimization. The op erations for individual mem b er deletion has b een mo died so that in the b est case, the LKS sends only one k ey up date message, and eac h of the mem b ers will send at most one k ey up date message to the group. Cum ulativ e mem b er deletion is p ossible as

PAGE 46

35 Bo olean function minimization is used. The features lik e early detection of mem b er absence, no access con trol information leak, and ease of pro viding m ultiple license enable easy deplo ymen t. Collusion attac ks remain as Bo olean function minimization tec hnique is used.

PAGE 47

CHAPTER 7 CONCLUSION AND FUTURE W ORK 7.1 Conclusion This thesis do cumen t started with a brief explanation of the m ulticast routing arc hitecture comprising m ulticast group managemen t and m ulticast routing proto cols. IGMPv3 is the group managemen t proto col for IPv4, and is used b y the routers and hosts to manage the group mem b ership information. IGMPv3 queries and rep orts w ere explained briery Multicast pac k ets are deliv ered using a m ulticast deliv ery tree formed b y a m ulticast routing proto col. PIM-SM is the most widely deplo y ed m ulticast routing proto col. PIM-SM uses a group shared tree for lo w er bit rate pac k et deliv ery and a source sp ecic tree for higher bit rate pac k et deliv ery Secure m ulticast is the term used to indicate a m ulticast service pro viding group access con trol, source authen tication, and secrecy Secure m ulticast is generally ac hiev ed b y pro viding a symmetric cryptographic k ey called a session k ey to the group mem b ers, and b y sending the group data encrypted using the session k ey Th us only the legitimate group mem b ers will b e able to decipher the group data. The task of pro viding secure m ulticast is divided in to t w o ma jor subtasks namely secure k ey distribution, and secure k ey managemen t. Secure k ey distribution in v olv es distributing the session k ey securely to legitimate group mem b ers.Iolus is the m ulticast k ey distribution framew ork whic h is highly scalable. The comp onen ts and op eration of Iolus is explained. The ev aluation of Iolus with deplo ymen t as the core ev aluation criteria is done and it indicates that this arc hitecture cannot co-exist with the already deplo y ed m ulticast routing proto cols lik e PIM-SM. GKMA denes a common arc hitecture and design for 36

PAGE 48

37 dieren t GKMPs. The comp onen ts and op eration of GKMA is explained. The ev aluation of GKMA with deplo ymen t as the core ev aluation criteria indicates that it do es not handle burst y and rash cro wds for dynamic m ulticast groups. General limitations of an y GKMP with resp ect to group secrets and p olicy complexit y is explained. Secure k ey managemen t in v olv es in generating the session k ey and facilitating k ey up dates in an ecien t manner. It also helps in main taining join and lea v e secrecy A naiv e k ey managemen t tec hnique is explained to pro vide an insigh t on the complexit y requiremen ts of secure k ey managemen t. A tree based solution using Bo olean function minimization is explained as it solv es the cum ulativ e mem b er remo v al in an ecien t manner. Cum ulativ e mem b er remo v al is the most desirable feature for large dynamic groups in whic h the lea v es are burst y Other op erations are also done in logarithmic time complexit y with few er n um b er of k eys to b e main tained in the GCKS and the mem b ers compared to other k ey managemen t tec hniques. A pragmatic framew ork for scalable secure source sp ecic m ulticast is prop osed with scalabilit y and ease of deplo ymen t as the core design requiremen ts. The prop osed framew ork is designed to co-exist with the m ulticast routing arc hitecture with IGMPv3 and PIM-SM. The k ey distribution arc hitecture is designed with desirable features from Iolus and GKMA. The prop osed k ey distribution sc heme lo calizes the group c hanges and hence the global session k ey remains mostly constan t while the lo cal session k eys ma y c hange often. The k ey managemen t sc heme follo ws the tec hnique using Bo olean function minimization. The op erations for individual mem b er deletion has b een mo died so that in the b est case, the LKS sends only one k ey up date message, and eac h of the mem b ers will send at most one k ey up date message to the group. Cum ulativ e mem b er deletion is p ossible as Bo olean function minimization is used. The features lik e early detection of mem b er

PAGE 49

38 absence, no access con trol information leak, and ease of pro viding m ultiple license enable easy deplo ymen t. Collusion attac ks remain as Bo olean function minimization tec hnique is used. In this thesis, v arious issues in secure m ulticast ha v e b een highligh ted. Imp ortan t con tributions in the area of secure k ey distribution and k ey managemen t ha v e b een explained and review ed with deplo ymen t as the core ev aluation criteria. The review indicates that most of the solutions are not prop osed with realistic implemen tations in mind. A framew ork for secure m ulticast is prop osed to alleviate these shortcomings and with ease of deplo ymen t as the essen tial feature. 7.2 F uture W ork Key managemen t. The follo wing is the list of impro v emen ts that can b e done for k ey managemen t: Impr ove d tr e e gr owth and shrinkage op er ations: It is b eneftial to build the tree b efore hand to a certain heigh t, instead of increasing the heigh t of the tree incremen tally The adv an tages are t w ofold: it minimizes the threat of collusion attac ks as the incremen tal gro wth of the tree results in duals 1 more often as the LKS can assign UIDs randomly This also reduces the o v erhead on the LKS during normal op eration when there are lot of joins. It is also b eneftial to main tain the KM tree at a certain heigh t for a p erio d of time b efore shrinking it. The reason is that, for dynamic groups, this ma y reduce the ructuations of KM tree from gro wing and shrinking alternately This also results in few er k eys b eing discarded and generated, the latter b eing a costly op eration. Early gener ation of keys: LKS can generate m ultiple SKs b eforehand, thereb y impro ving the p erfomance during normal op eration of the LKS during k ey distribution. 1 duals are a pair of mem b ers whose UIDs are one's complemen t of eac h other, resulting in the pair of mem b ers ha ving all the k eys in the KM tree

PAGE 50

REFERENCES [1] D. Estrin, D. F arinacci, A. Helm y D. Thaler, S. Deering, M. Handley V. Jacobson, C. Liu, P Sharma, L. W ei \Proto col Indep enden t Multicast-Sparse Mo de (PIM-SM): Proto col Sp ecifcation," RF C2362, In ternet Engineering T ask F orce, June 1998 [2] B. Cain, S. Deering, B. F enner, I. Kouv elas, A. Th y agara jan, \In ternet Group Managemen t Proto col, V ersion 3," h ttp://www.ietf.org/in ternet-drafts/draft-ietf-idmr-igmp-v3-09.txt, W ork in progress, Jan uary 2002 [3] M. J. Mo y er, J. R. Rao, P Rohatgi, \A Surv ey of Securit y Issues in Multicast Comm unications," IEEE Net w ork, No v em b er 1999 [4] R. Canetti, P Rohatgi, P Cheng, \Multicast Data Securit y T ransformations: Requiremen ts, Considerations, and Prominen t Choices," h ttp://searc h.ietf.org/in ternet-drafts/ draft-irtf-sm ug-data-transforms.txt, W ork in progress, Jan uary 2000 [5] S. Mittra, \Iolus: A F ramew ork for Scalable Secure Multicasting," Pro ceedings of A CM SIGCOMM 1997 [6] M. Baugher, R. Canetti, L. Dondeti, \Group Key Managemen t Arc hitecture," h ttp://www.ietf.org/ in ternet-drafts/ draft-ietf-msec-gkmarc h-01.txt, W ork in progress, Octob er 2001 [7] T. Hardjono, H. Harney P McDaniel, A. Colegro v e, P Dinsmore, \Group Securit y P olicy T ok en," h ttp://www.ietf.org/ in ternet-drafts/ draft-ietf-msec-gspt-00.txt, W ork in Progress, Septem b er 2001 [8] S. Chokhani, W. F ord, \In ternet X.509 Public Key Infrastructure Certifcate P olicy and Certifcation Practices F ramew ork," RF C2527, In ternet Engineering T ask F orce, Marc h 1999 [9] D. W allner, E. Harder, R. Agee, \Key Managemen t for Multicast: Issues and Arc hitectures," RF C2627, In ternet Engineering T ask F orce, June 1999 [10] I. Chang, R. Engel, D. Kandlur, D. P endarakis, D. Saha, \Key Managemen t for Secure In ternet Multicast using Bo olean F unction Minimization T ec hniques," Pro ceedings of IEEE Info com, pages 689-698, 1999 39

PAGE 51

40 [11] H. Holbro ok, B. Cain, \Source-Sp ecifc Multicast for IP ," h ttp://www.ietf.org/in ternet-drafts/draft-ietf-ssm-arc h-00.txt, W ork in Progress, Ma y 2002 [12] S. Bhattac haryy a, C. Diot, L. Giuliano, R. Ro c k ell, J. Meylor, D. Mey er, G. Shepherd, B. Hab erman, \An Ov erview of Source-Sp ecifc Multicast (SSM)," h ttp://www.ietf.org/in ternet-drafts/draft-ietf-ssm-o v erview-03.txt, W ork in progress, Marc h 2002 [13] R. Vida, L. Costa, S. Fdida, S. Deering, B. F enner, I. Kouv elas, B. Hab erman, \Multicast Listener Disco v ery V ersion 2 (MLDv2) for IPv6," h ttp://www.ietf.org/in ternet-drafts/draft-vida-mld-v2-03.txt, W ork in progress, June 2002

PAGE 52

BIOGRAPHICAL SKETCH Murali M. Brahmadesam w as b orn in Tiruc hirappalli, T amil Nadu, India, on July 5th, 1979. He earned his high sc ho ol diploma from YW CA matriculation higher secondary sc ho ol. He graduated with a Bac helor of Engineer degree with distinction in computer science and engineering in 2000 from Regional Engineering College, Tiruc hirappalli. He came to Gainesville, Florida, to pursue a Master of Science in Computer and Information Science and Engineering Departmen t, Univ ersit y of Florida. 41


Permanent Link: http://ufdc.ufl.edu/UFE0000509/00001

Material Information

Title: Framework for Scalable Secure Source Specific Multicast
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000509:00001

Permanent Link: http://ufdc.ufl.edu/UFE0000509/00001

Material Information

Title: Framework for Scalable Secure Source Specific Multicast
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000509:00001


This item has the following downloads:


Full Text











FRAMEWORK FOR SCALABLE SECURE SOURCE SPECIFIC MULTICAST


By

MURALI M. BRAHMADESAM















A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2002


































Copyright 2002

by

Murali M. Brahmadesam




































To

My wonderful Mom & Dad















ACKNOWLEDGMENTS

I would like to express my deepest gratitude to my advisor, Dr. Richard E.

Newman, for giving me the opportunity to work on this interesting field of secure

multicasting. This work would not have been possible but for his excellent advice

and guidance through different stages of the thesis.

Thanks go to Dr. Randy Chow and Dr. Jonathan Liu for their -i',- -,H,'

during several research meetings.

Thanks go to Mr. Rahul Shah and Mr. Chirayu Shah of Protocols group,

Ericsson IP Infrastructure, Rockville, MD, for their valuable guidance in multicast

protocols development and deployment during my Internship in summer 2001.

Special thanks go to the people involved in IETF, with whom I have interacted

regarding multicast protocols. But for their dedication, the Internet would not have

grown this huge or robust.

Finally I would like to thank my parents for their continued and encouraging

support throughout my period of study here.















TABLE OF CONTENTS

page

ACKNOWLEDGMENTS ................... ...... iv

LIST OF FIGURES ..................... ......... vii

KEY TO ABBREVIATIONS ................... ...... viii

A BSTRACT . . . . . . . . . x

CHAPTER

1 INTRODUCTION ..................... ........ 1

2 KEY MANAGEMENT REQUIREMENTS FOR MULTICAST APPLI-
CATIONS. ............ ...... .......... ..... 3

3 MULTICAST ROUTING ARCHITECTURE ...... ...... ... 5

3.1 IG M Pv3 . . . . . . . . 5
3.2 PIM-SM .......................... .... 6
3.3 Sum m ary . . . . . . . 8

4 MULTICAST KEY DISTRIBUTION: EXISTING SOLUTIONS ..... 9

4.1 Iolus Framework ............................ 9
4.1.1 Group Initialization and Member Addition ......... 9
4.1.2 Member Deletion .......... ............ 9
4.1.3 Data Transmission .......... ............ 10
4.1.4 Merits of the Iolus Framework ...... ........ 10
4.1.5 Limitations of the Iolus Framework ............. 10
4.1.6 Summary ...... ........... ........ 12
4.2 Group Key Management Architecture (GKMA) .......... 12
4.2.1 Overview . . . . . . . 12
4.2.2 Detailed Description .......... ....... .... 13
4.2.3 Merits of GKMA ......... .............. 16
4.2.4 Limitations of GKMA ......... ........ .... 16
4.3 General Limitations of any GKMP ...... ........... 17
4.3.1 Group Secrets ......................... 17
4.3.2 Policy Complexity .......... ....... ..... 17
4.4 Summary ................... ....... 18









5 MULTICAST KEY MANAGEMENT: EXISTING SOLUTIONS ..... 19

5.1 Naive Key Management ......... ..... ..... 19
5.2 Tree Based Solution Using Boolean Function Minimization .... 19
5.2.1 Individual Member Removal ........ ......... 20
5.2.2 Removal of Multiple Members ............... .. 20
5.2.3 Collusion Attacks .................. .. 22
5.2.4 Performance Analysis ................ .. .. 22
5.3 Summary .................. ............ .. 22

6 A PRAGMATIC FRAMEWORK FOR SCALABLE SECURE SOURCE
SPECIFIC MULTICAST .................. ..... .. 24

6.1 Design Features and Requirements ................. .. 24
6.2 Key Distribution .................. ...... .. .. 25
6.2.1 Framework .................. ........ .. 25
6.2.2 Operational Overview ................ .. .. 26
6.2.3 Data Transmission .................. .. 29
6.3 Key Management .................. ........ .. 30
6.3.1 Detailed Description .................. ..... 31
6.3.2 M ember Join .................. ....... .. 31
6.3.3 Individual Member deletion ................. .. 32
6.3.4 Cumulative Member Deletion. .............. .. 33
6.3.5 Tree Growth .................. ....... .. 33
6.3.6 Tree Shrinkage .................. ..... .. 33
6.4 Properties .. .. .. .. .. ... .. .. .. ... .... .. 34
6.5 Summary .................. ............ .. 34

7 CONCLUSION AND FUTURE WORK ................. .. 36

7.1 Conclusion .................... . .... 36
7.2 Future Work .................. ........... .. 38

REFERENCES ................... ............ ... 39

BIOGRAPHICAL SKETCH .................. ......... .. 41















LIST OF FIGURES


An example of a group-shared and source-specific tree

Data transmission in Iolus .. ............

Group Security Association Model .. .........

Key Update in a group of size 8 for departure of c5

Example of departure of multiple members ......

Pragmatic Framework for Scalable Secure Multicast .


using PIM.


Figure

3.1

4.1

4.2

5.1

5.2

6.1


page

8















KEY TO ABBREVIATIONS


ACL: Access Control List

CBT: Core Based Tree

DR: Designated Router

DSP: Data Security Protocol

DVMRP: Distance Vector Multicast Routing Protocol

GCKS: Group Controller / Key Server

GKMA: Group Key Management Architecture

GKMP: Group Key Management Protocol

GSA: Group Security Agents

GSC: Group Security Controller

GSI: Group Security Intermediary

IGMP: Internet Group Membership Protocol

IP: Internet Protocol

IPSEC: IP Security Protocol

KEK: Key Encrypting Key

LKS: Local Key Server

PIM-SM: Protocol Independent Multicast Sparse Mode

RKP: Re-Key Protocol

RP: Registration Protocol

RP: Rendezvous Point

RSPT: Reverse Shortest Path Tree

SA: Security Association









SDP: Session Description Protocol

SPI: Security Parameter Index

SPKI: Simple Public Key Infrastructure

SSM: Single Source Multicast

TEK: Traffic Encrypting Key















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

FRAMEWORK FOR SCALABLE SECURE SOURCE SPECIFIC MULTICAST

By

Murali M. Brahmadesam

December 2002

Chair: Richard E. Newman
Major Department: Computer and Information Science and Engineering

Multicast is a mode of message delivery in which a single message is delivered

to a group of recipients. Multicast delivery minimizes the demand on the sender

and network resources. With the standardization of several multicast routing

and group membership protocols, the task of multicast packet delivery is fairly

complete. Issues like group access control, source authentication, and secrecy have

been the major hurdles in world-wide deployment of multicast.

Secure multicast is the term used to indicate a multicast service providing

the aforementioned security features. Secure multicast is generally achieved by

providing a symmetric cryptographic key called a session key to the group members

and by sending the group data encrypted using the session key. Thus only the

legitimate group members will be able to decipher the group data.

The task of providing secure multicast is divided into two major subtasks,

namely, secure key distribution, and secure key management. Secure key distri-

bution involves distributing the session key securely to legitimate group members.

Secure key management involves generating the session key and facilitating key

updates in an efficient manner.









This thesis discusses various existing techniques to provide secure key distribu-

tion and management. Scalability is a key issue to enable large scale deployment of

secure multicast. A special category of multicast, namely, Source Specific Multicast

(SSM), is considered. In SSM the multicast group contains a single source and

the remaining members are just receivers. A framework for scalable secure source

specific multicast is proposed with the key distribution scheme providing a tree

based solution where the group membership changes have only a local effect, and

the key management scheme solving the local membership changes efficiently with

the help of a local key server.















CHAPTER 1
INTRODUCTION

Multicasting enables group communication by delivering a single message

sent to multiple receivers. Applications such as audio and video distribution, and

several other "push" applications are the driving forces for multicast deployment.

Reliability (timely and orderly delivery of messages) and security (group access

control, source authentication and secrecy) have been the tallest hurdles in the

path of commercial utilization of multicast applications.

Multicast packet delivery is a connectionless delivery scheme, hence its use in

applications is done trusting that the source of packets is from the actual sender.

Since it is not mandatory that only a member of a multicast group should send

packets to a multicast group, there is no easy way to authenticate the packets

delivered using ordinary multicast. Also, some applications require secrecy, e.g.,

a highly confidential video conference. Moreover, access control might be desired

in some applications, including confidential collaboration and cases in which the

service provider intends to charge the customer for content delivery.

Secure multicast is the term used to indicate a multicast service providing the

aforementioned security features. Secure multicast is generally achieved by pro-

viding a symmetric cryptographic key called a session key to the group members,

and by sending the group data encrypted using the session key. Thus only the

legitimate group members will be able to decipher the group data. The essential

key management requirements for multicast applications is explained in chapter 2.

The task of providing secure multicast is divided into two major subtasks: secure

key distribution and secure key management. Secure key distribution involves

distributing the session key securely to legitimate group members. Secure key









management involves generating the session key and facilitating key updates in an

efficient manner. This thesis explains the important contributions that have been

made in the field of secure multicast in chapters 4, and 5.

Multicast packet delivery is based on the multicast delivery tree formed by the

multicast routing protocol. Hosts and routers use a group management protocol

to manage group membership information. Brief tutorials of the widely imple-

mented multicast routing protocol, Protocol Independent Multicast Sparse Mode

(P'Ii-Si1) [1], and the group management protocol, Internet Group Management

Protocol version 3 (IGMPv3) [2], are provided in chapter 3 to draw a roadmap

along which a deployable solution for secure multicast may be achieved. The pro-

posed pragmatic framework for scalable secure source specific multicast is explained

in chapter 6, and the possible future work and extensions, and conclusions are

provided in chapter 7 concludes the thesis.















CHAPTER 2
KEY MANAGEMENT REQUIREMENTS FOR MULTICAST APPLICATIONS

Multicast applications use a Group Key Management Protocol (GKMP) to

provide the legitimate members with the up-to-date cryptographic state they

need for their secrecy and authenticity requirements. The following is the list of

requirements for such a key management solution for multicast applications:

Join S, i i, this ensures that the new member cannot decipher past
messages, thus mandates that a new session key be used for each member
addition;

Leave S, i ,1 this ensures that an old member cannot decipher future
messages, thus mandates that a new session key be used for each member
deletion;

Source Authentication: this enables each receiver to verify the authenticity of
origin of each message;

Access Control: this ensures that only legitimate members can access the
group data;

Member de-registration: this is essential for most commercial multicast
applications, in which member de-registration is used for billing information;
leave secrecy has to be maintained after member de-registration.

The following is the list of essential evaluation criteria for key management

solutions. A more exhaustive list can be found in Moyer et al. [3], Canetti et al.

[4].

Number of keys with a controller: Apart from the common session key, the
group controller/key server (GCKS) maintains more keys to enable efficient
key updates;

Number of keys with each *.',,1 member: Apart from the common session key,
each member maintains more keys to enable efficient key updates;









Communication i, -,.,!1. il ;i for a join: This is an estimate of number of
messages that have to be sent by the GCKS for each member join;

Communication 1.'!1., i ;ifi for a leave: This is an estimate of number of
messages that have to be sent by the GCKS for each member removal;

Computation -, ,.1,1, i; Ii for a join: This is an estimate of number of
cryptographic operations that have to be done for each join. Separate
estimates are given for GCKS and for a member.

Computation .,'1,' i ;I, for a leave: This is an estimate of number of
cryptographic operations that have to be done for each leave. Separate
estimates are given for GCKS and for a member.

This list enables one to evaluate different key management and key distribution


schemes for scalability.















CHAPTER 3
MULTICAST ROUTING ARCHITECTURE

Multicast packet delivery is based on the multicast delivery tree formed by a

multicast routing protocol. A group management protocol is used by the hosts and

the routers to manage group membership information. The following is a brief

overview of IGMPv3 [2], which is the group management protocol for IPv4, and

PIM-SM [1], which is the most widely implemented multicast routing protocol.

3.1 IGMPv3

Multicast addresses are class D IP addresses in IPv4. The address 224.0.0.0 is

guaranteed not to be assigned to any group, and 224.0.0.1 is used as the group for

all IP hosts; i.e., all the hosts and routers are members of this group. The following

lists the messages sent by the hosts. All the IGMP messages are sent with TTL 1,

and hence will not be forwarded outside the subnet.

Membership Reports: The host can send a membership report to the router
indicating the group address and/or list of the sources of interest for that
multicast group. IGMPv3 adds support for source filtering; i.e., the ability for
a system to report interest in receiving packets only from specific source
addresses, or from all but specific source addresses, sent to a particular
multicast address. The source filtering information is used by the multicast
routing protocols to avoid delivering multicast packets from specific sources to
networks where there are no interested receivers. Membership reports are sent
either due to a membership query sent by the router or due to membership
status changes in the host. A single membership report may contain the
information pertaining different multicast groups, or that of just a single
multicast group.

Leave Group: IGMPv2 specifies a separate leave group message; in IGMPv3 a
host can leave from a group by sending a membership report indicating that
it excludes all the sources of a particular multicast group.

The following lists the messages sent by the routers.









General Query: This is sent by a router to learn the complete multicast
reception state of the hosts.

Group-Specific Query: This is sent by the router to learn the reception state
of the hosts with respect to a single multicast address.

Group-and-Source-Specific Query: This is sent by the router to learn if any of
the hosts intend to receive messages from a particular source of a particular
group.

The General Query is sent periodically by the router to the multicast address

224.0.0.1, while the other two query messages are sent only to the particular

multicast group address it intends to query, and are sent due to membership

changes.

3.2 PIM-SM

The operation of PIM-SM can be explained with ease if the design considerations

of this routing protocol are understood. These in turn are based on the merits and

limitations of two other multicast routing protocols briefly explained below.

The Distance Vector Multicast Routing Protocol (DVMRP) is a multicast

routing protocol that used a source-specific tree for data delivery. A source-specific

tree is the shortest path tree built with the source for the multicast group as the

root, the multicast routers as non-leaves and the members as leaves. The shortest

path tree, which is a spanning tree rooted at the source, is referred to as Reverse

Shortest Path Tree (RSPT), based on the method used to build such a tree.

RSPTs are best suited for high data rate sources, and are to be constructed for

each of the sources of the multicast group.

The Core Base Tree (CBT) is a multicast routing protocol that uses a shared

tree built for the entire multicast group for data delivery. This single tree is used

by all the sources of the multicast group. The shared tree is well suited for a large

number of low data rate sources, and results in traffic concentration as all the

packets from all the sources are delivered through the same shared tree.









PIM is designed to make use of both the shared tree and shortest path trees for

data delivery. The choice of which of the trees to use depends on the data rate of

the source. Initially, only the shared tree will be created for the entire group, and

an RSPT will be created only if the data rate of a particular source at which the

tree will be rooted exceeds a threshold. Thus creation of RSPTs is data-driven.

After the creation of the RSPT for a source, this tree will be used to deliver

packets from that source to the multicast group. Packets from the other sources

will continue to use the shared tree of the multicast group. If the data rate of the

source for the RSPT falls below the threshold, the shared tree will be used for

subsequent packet delivery. PIM operation using an RSPT is referred as

PIM-Dense Mode (PIM-DM), and the operation using the shared tree is called

PIM-Sparse Mode (PIi-S\i).

PIM-SM requires predetermined per-group Rendezvous Points (RPs) for the

creation of shared trees. When a host sends the IGMP join message to its

Designated Router (DR), the router sends the PIM join message towards the RP

advertised for the particular group. Intermediate routers process this message,

resulting in the creation of a branch from the RP to the DR used for packet

delivery. A similar branch will be created between the source of the multicast

group and the RP. Thus when a source sends packets at low data rates, the packets

reach the RPs and are sent to the other DRs for delivery to the members. When

the data rate exceeds a threshold, the creation of an RSPT rooted at the DR

connected to the source is triggered at the DRs. PIM Prune messages are sent

towards the RP and PIM join messages are sent towards the DRs forming the next

hop of the RSPT. Figure 3.1 shows an example PIM-SM tree structure. The

continuous lines represent edges of the shared tree and dashed lines represent the

edges of the shortest path tree.












DR DR



-RP D--R----- DR
DR DR


DR R)
DR




(DR


Figure 3.1: An example of a group-shared and source-specific tree using PIM



3.3 Summary

This chapter briefly explained IGMPv3 and PIM-SM. IGMPv3 is the group

management protocol for IPv4, and is used by the routers and hosts to manage the

group membership information. IGMPv3 queries and reports were explained

briefly. Multicast packets are delivered using a multicast delivery tree formed by a

multicast routing protocol. PIM-SM is the most widely deployed multicast routing

protocol. PIM-SM uses a group shared tree for lower bit rate packet delivery, and a

source specific tree for higher bit rate packet delivery.















CHAPTER 4
MULTICAST KEY DISTRIBUTION: EXISTING SOLUTIONS

This section explains important architectural frameworks for secure multicast.

These architecutral frameworks enable the session key to be distributed securely to

legitimate group members. Existing solutions are also analyzed for ease of

deployment.

4.1 Iolus Framework

lolus [5] partitions the multicast group into a hierarchy of subgroups, each with

relatively few members and its own separate multicast address. The tree is

comprised of Group Security Agents (GSAs). The root of the tree is called the

Group Security Controller (GSC), and the other GSAs are called Group Security

Intermediaries (GSIs). The GSI of a subgroup manages the subgroup's keys and

mediates all the communication between its subgroups and other subgroups.

4.1.1 Group Initialization and Member Addition

At first, only the GSC exists, and all the GSIs are aware of the GSC's unicast

address. When there is a request to a GSA from an outsider to join the group,

after checking with its Access Control List (ACL), it generates a new session key,

sends it via secure unicast to the new member, and encrypted with the old key, it is

multicast to the existing members. If the GSA is the GSI, and if the current

request is the first join request, then the GSI joins a higher level multicast group,

proceeding until a subtree is formed with GSC. The GSIs are supplied with the

ACLs to process joins locally.

4.1.2 Member Deletion

On member deletion, the local GSI generates a new session key and gives it to

the remaining n members in the subgroup separately via secure unicast. Even

9









though the time complexity for this is O(n) it is not bad, as the size of the entire

multicast group can be much larger than n. If this removal results in no member

for the subgroup, then the GSI leaves the tree.

4.1.3 Data Transmission

The source multicasts directly within its subgroup, and each GSI remulticasts to

the other subgroup in which it is a member. Since the other subgroup uses a

different session key, the GSI must decrypt the data with the key of one subgroup

and encrypt with the key of the other subgroup before multicasting. Instead of

doing this for the entire message, the source multicasts {Kradn}Kkl{Data}Krnd,

where Krand is the random key generated by the source for each message, and Kskl

is the session key of the subgroup. The GSI of the subgroup decrypts {Krand}KskI

and remulticasts {Kr.d}Ksk2{Data}Kjand to the other subgroup with Ksk2 as its

session key. Thus, only the random key has to be encrypted each time with a

different key. Figure 4.1 shows data transmission from a source in subgroup G2A

to the entire group.

4.1.4 Merits of the Iolus Framework

The advantages of the Iolus framework are listed below.

This architecture localizes the effect of group membership changes to one
sub-group.

It distributes the security over many nodes, eliminating any single point of
failure except the top-level GSC.

The use of the local session keys as Key Encrypting Keys (KEKs) in data
delivery removes the burden of decrypting and encrypting the entire data
payload at each GSA.

4.1.5 Limitations of the Iolus Framework

The drawbacks of the Iolus framework are listed below.

The GSC still remains as a single point of failure.
































Figure 4.1: Data transmission in Iolus


* Re-keying on member departure takes O(n) messages, where n is the number
of remaining members in the subgroup. Even though this can be much
smaller than the entire group size, there must be numerous GSIs to reduce
the number of members in each subgroup.

* The framework fails to mention where the GSIs have to be placed in the
actual multicast delivery tree created by multicast routing protocols. This is
very important because the semantics of operations become blurred if the
GSIs can be outside the subnets and away from the actual delivery tree
created by the multicast routing protocols. In this case the GSIs have to
become the members of the global multicast tree but the routing protocols
have to be changed so that the packets are not sent directly to the members
but only through the GSIs.

* Each GSI has to be a member of a separate subgroup. When an outsider
intends to become a member of a global group, he has to join a local
subgroup. The mapping between the local subgroup and the global group has
to be defined.









The requirement for different subgroups results in use of multiple multicast
addresses for the single global multicast group. Since no routing protocols are
designed this way, GSIs have to take responsibility for routing packets.

4.1.6 Summary

Iolus is the multicast key distribution framework which is highly scalable. The

components and operation of Iolus is explained. The evaluation of Iolus with

deployment as the core evaluation criteria is done and it indicates that this

architecture cannot co-exist with the already deployed multicast routing protocols

like PIM-SM.

4.2 Group Key Management Architecture (GKMA)

GKMA [6] intends to define a common architecture and design for different

Group Key Management Protocols (GKMPs) for internet, transport, and

application services. GKMP enables only the members (senders and receivers) of a

secure multicast group to gain access and authenticate the group data. This design

is based on a group controller model with a single group owner as the root of trust.

The group owner designates a group controller for member registration and re-key.

4.2.1 Overview

The GKMP provides the group members with an up-to-date Data Security

Protocol Security Association (SA) or Data SA, which contains the information

necessary to secure the group data. The contents of the Data SA is given in 4.2.2.

To achieve this goal, the GKMA consists of the following protocols:

Registration Protocol;

Re-key Protocol;

Data Security Protocol.

Registration protocol (RP). The RP is a two-way unicast protocol between the

Group Controller/Key Server (GCKS) and a joining member. The RP uses the

Registration Protocol SA to ensure that the transfer of information from GCKS to









member is done in an authenticated and confidential manner. The RP facilitates

mutual authentication between GCKS and a joining member, and allows verification

of authorization of a joining member.

Upon successful authentication and authorization verification, the GCKS

provides the joining member with sufficient information to initialize a Re-key

Protocol SA with the joining member if the Group Security Policy (GSP) calls for

it, and sufficient information to initialize a Data Security Protocol SA with the

joining member.

Re-key protocol (RKP). RKP is an optional protocol and is used by GCKS

periodically to send re-key information to the group members due to membership

changes or expiry of the Traffic Encrypting Keys (TEK). Re-key messages are

protected by the Re-key Protocol SA. The messages are either sent by multicast to

group members or are unicast to a particular group member. RKP is optional as

other means for managing the keys locally without interaction between the GCKS

and member may be used. The re-key messages are to be delivered in a timely

manner and should subjected to source authentication.

Data security protocol (DSP). DSP uses the TEK to secure the group data.

4.2.2 Detailed Description

Each group member uses the RP to obtain authorized, authenticated access to a

particular group, its policies, and its keys. The two types of group keys are:

Key Enc(, ,ft! '-i Key (KEK): this key is used by the re-key protocol, and is
used to encrypt the TEK;

Text Enci, ,;,it,!f Key (TEK): this key is used by the Data Security Protocol
(DSP) to protect the group data.

Group Security Association (GSA). The GCKS is a separate, logical entity that

performs member authentication and authorization according to the group policy

that is set by the group owner. The GCKS creates the KEK and TEK, and sends









































Figure 4.2: Group Security Association Model



them to the joining member. Upon receipt of a TEK from a re-key message or a

Registration Protocol exchange, the member's group key management will provide

a security association to a Data Security Protocol for the data sent from the sender

to the receiver. In Figure 4.2, the Security Protocol SA protects the data sent on

the arc labeled "DATA SECURITY PROTOCOL," the Re-key SA protects the

data sent on the arc labeled "RE-KEY PROTOCOL," and the Registration

Protocol SA protects the RP exchanges. These three SAs comprise the Group

Security Association.

The policy and authorization infrastructures indicated in Figure 4.2 are external

to GKMP. The group-policy will be distributed through both announcement and

key management protocols [7]. The group-policy contains at least the following:


POLICY AUTHORIZATION
INFRASTRUCTURE INFRASTRUCTURE





GCKS

REGIST RATION RESIST NATION
PROTOCOL i PROT COL
REKEY
PROTOCOL
S (OP TONAL) ,
SENDER(s) 1------ RECEIVER(s)




DATA SECURITY
PROTOCOL









group owner, authentication method, and delegation method for identifying a
GCKS for the group;

group GCKS, authentication method, and any method used for delegating
other GCKSs for the group;

group membership rules or list and authentication method.

It also contains two additional policy-related requirements external to group key

management:

authorization and authentication infrastructure such as Simple Public Key
Infrastructure (SPKI)[8]or pre-shared key scheme in accordance with the
group policy for a particular group;

an announcement mechanism for secure groups and events that operates
according to group policy for a particular group, (for example Session
Description Protocol (SDP)).

Contents of Re-key SA. The Re-key SA protects the Re-key protocol. It contains

the following:

Re-key SA policy: the membership management algorithm that enforces
forward and backward access control, the KEK encryption algorithm, the
authentication algorithm, the control group address, the re-key server address;

Group Identity: to identify the group if multiple groups can be initialized in a
single invocation of the RP or RKP;

KEKs and their lifetimes;

GCKS authentication key: a symmetric key or public key for authentication
of the re-key messages;

sequence numbers: for replay protection;

Security Parameter Index (SPI): the triple (Group Identity, SPI, an identifier
for "Re-key SA") that uniquely identifies an SA.

Contents of the Data SA. The Data SA protects the group data. It contains the

following:

Group Identity: to identify the group if multiple groups can be initialized in a
single invocation of the RP or RKP;









source identity: to identify the source for the group;

traffic encrypting key;

authentication key;

sequence numbers: for replay protection;

Security Parameter Index (SPI):the triple (Group identity, SPI, an identifier
for "Re-key SA") that uniquely identifies an SA;

Data SA policy.

The Data SA policy includes encryption algorithm and parameters, the source

authentication algorithm and parameters, the group authentication algorithm and

parameters, and/or replay protection information.

4.2.3 Merits of GKMA

The implementation of the protocols is not dependent on the architecture,

allowing the requirements of the application to dictate the protocol operation. For

example, a re-key protocol for a small group could use multiple unicast

transmissions with symmetric authentication, while that for a large group could use

IP Multicast with packet-level forward error correction and source authentication.

There is no need for a unicast exchange to provide data keys to existing members

of the group. Data keys can be pushed in the Re-key Protocol. This allows fast

rekeying for existing members. The authorization infrastructure can support

delegation, as does SPKI. This hierarchically-organized key distribution with

multiple GCKSs can handle "flash-crowds."

4.2.4 Limitations of GKMA

Handling departing members. The following points list the limitations of GKMA

in the way it handles departing members.

If the departing member fails to report to the GCKS that it is no longer in
the group, the GCKS must wait until the SAs time out before freeing up the
associated data structures and timers.









The timeouts for the SA expiry cannot be very small as this would pose
considerable overhead for the GCKS, since it usually handles SAs of
numerous members. If the group is for a paid service, the GCKS uses the
time of SA removal for billing information. If the member fails to report its
departure to GCKS the member will be expected to pay until the SA expires,
even though it was not a member for the intervening time.

In large-scale multicast applications, de-registration is an essential service
(e.g, for billing information), and thus has the potential to cause implosion at
the GCKS.

Handling flash crowds. Even though GKMA specification indicates that multiple

GCKSs can be used by delegation to handle flash crowds, it lacks the means to

handle a flood of departing members (discussed above) in a satisfactory way.

Moreover, additional protocols are required between the different GCKSs to

generate the same keys on member joins or leaves based on the group policy as the

source will be using a single key to encrypt group data.

Dynamic groups. Dynamic groups involve multiple join and leave requests over a

short period of time. A single GCKS cannot handle this as key generation requires

a considerable amount of time. This delay may result in more leave requests

worsening the situation. In the worst case scenario, the source ends up waiting for

the key from the GCKS rather than sending group data.

4.3 General Limitations of any GKMP

This section discusses the general limitations of any GKMP [6].

4.3.1 Group Secrets

Group members are trusted to preserve the group secrets. It is very difficult to

find if a legitimate member has disclosed the group secrets to an outsider, and if

such an outsider is listening to the group data. Moreover, authentication by

symmetric keys should be avoided unless all the group members can be trusted.

4.3.2 Policy Complexity

Unlike peer-to-peer security policy, which is an intersection of the policy of the

individual peers, a group owner sets the group policy externally. The choice of the







18

group policy poses new risks to the members of the group. The group owner and

members need to determine minimal acceptable levels of trust, authenticity and

confidentiality for the group.

4.4 Summary

GKMA defines a common architecture and design for different GKMPs. The

components and operation of GKMA is explained. The evaluation of GKMA with

deployment as the core evaluation criteria indicates that it does not handle bursty

and flash crowds for dynamic multicast groups. General limitations of any GKMP

with respect to group secrets and policy complexity is explained.















CHAPTER 5
MULTICAST KEY MANAGEMENT: EXISTING SOLUTIONS

In secure multicast, join and leave secrecy must be maintained, which involves

generating a new session key used for subsequent encryption of the group data, and

distributing the new session key securely to the remaining members. Secure key

management involves generating the session key and facilitating key updates in an

efficient manner. In this section a naive key management scheme is explained first

to emphasize the scalability requirements of the key management schemes. A

detailed explanation of the tree-based solution using Boolean function minimization

is given. Detailed explanations of other tree based solutions are covered in a

previous survey of security issues in multicast communications [3].

Member de-registration, as explained earlier, involves preserving leave secrecy.

Since most multicast applications involve bursty joins and leaves, it is essential to

provide cumulative member removal for scalability reasons. The tree-based

technique using Boolean function minimization provides such a solution. Other key

management solutions are explained in Wallner et al. [9].

5.1 Naive Key Management

Here, the GCKS stores n + 1 keys: the common session key and one for each of

the n members. For each join or leave, the GCKS securely unicasts the new group

key to each member, so the computation and communication complexity in GKC

are each O(n). Clearly, this scheme does not scale well for applications with

numerous members and involving bursty joins and leaves.

5.2 Tree Based Solution Using Boolean Function Minimization

In the tree-based solution using Boolean function minimization [10], the GCKS

maintains a complete balanced binary tree where the N leaves are attached to









another N nodes representing the N members of the group. Each of the N

members is given an unique UID represented by a binary string of length

n = [7.,.iN]. Each nonleaf node in the tree contains an auxiliary key. A member

with UID X,_-1X_-2...Xo, receives the common session key SK, and the set of n

auxialiary keys K,_1, Kn-2, ..., Ko, where K, is ki if X, = 1, and k' if X,=0. The

auxialiary keys are used to update the session key in secure fashion. For example,

in Figure 5.1, the member co with UID 000 will have SK, kV, k', k', and the

member c6 will have SK, k2, kl, k'. So the GCKS maintains 21/.,._N auxiliary keys,

and each member will maintain 1.,.IN auxiliary keys.

5.2.1 Individual Member Removal

For each member removal the GCKS sends log2N messages. For example, to

remove a member c5 with UID 101, the GCKS sends the new session key SKnew

encrypted with kV, kl, kV. C5 cannot decrypt any of these three messages as it has

only ko, k', and k2. Figure 5.1 shows a visual interpretation of this re-keying

scheme. In the figure, the keys corresponding to the solid round nodes correspond

to the keys possessed by the departing member c5. The hatched round nodes

represent the complementary set, that is, the keys not possessed by c5. Since the

leaving member could listen to future key updates, the auxiliary keys are also

updated. To update a key Ki, a one way hash function f is used that yields the

updated auxialiary key as follows K,,_ne = f(Ki, SKne.). Since the leaving

member does not have the new session key SK, it will not be able to compute the

new auxiliary key.

5.2.2 Removal of Multiple Members

An efficient way to remove multiple members uses Boolean function

minimization. For example, if members co and c4 with UIDs 000 and 100,

respectively, are to be removed from the group, the new key SK,,e has to be given

securely to c1, c2, c3, C5, c6, C7. It is enough if GCKS sends {SKne,}ko, {SKn,}kl.

























cO cl c2 c3 c4 c5 c6 c7
000 001 010 011 100 101 110 111

Figure 5.1: Key Update in a group of size 8 for departure of c5


The first message can be decrypted only by cl, c3, c5, and c7, and the second only

by members c2, c3, c6, and c7. Thus the remaining members can be updated with

the new key using only two messages instead of six messages. Figure 5.2 depicts

this scenario.
SK







kk k k


k-. k k k k, kZ k k/ k


cO cl c2 c3 c4 c5 c6 c7
000 001 010 011 100 101 110 111

Figure 5.2: Example of departure of multiple members




Boolean function minimization. Cumulative member removal is equivalent to

grouping the remaining members that share common bits in the UID, and hence

common keys, which are different from those possessed by the removed members.

This problem is equivalent to Boolean function minimization. Methods for









minimizing the Boolean function can be used to find the minimum number of

messages to be sent.

5.2.3 Collusion Attacks

In collusion attack, a set of removed members collude and by combining their

sets of keys, and may be able to obtain the currently valid set of keys. This will

enable them to listen to the group communication. It is impossible to eliminate the

risk of a collusion attack with less than O(N) auxiliary keys [10]. The risk of

collusion attack may be reduced with a large auxiliary key space and a sparse

distribution of UIDs.

5.2.4 Performance Analysis

Detailed proof for the following performance analysis results is given in Chang et

al. [10].

Worst case performance. Re-keying a secure multicast group of size 2" when two

group members are to be removed requires at most n messages, and when 2"-1

members are to be removed, it requires at most 2n-1 messages.

Average case performance. The average number of messages required for

aggregate removal of an arbitrary number of members from a multicast group is

equivalent to average number of products in the minimum sum-of-products

expressions of Boolean functions. Extensive proof of this is given in [10]

5.3 Summary

Secure key management involves in generating the session key and facilitating

key updates in an efficient manner. It also helps in maintaining join and leave

secrecy. A naive key management technique is explained to provide an insight on

the complexity requirements of secure key management. A tree based solution

using Boolean function minimization is explained as it solves the cumulative

member removal in an efficient manner. Cumulative member removal is the most

desirable feature for large dynamic groups in which the leaves are bursty. Other







23

operations are also done in logarithmic time complexity with fewer number of keys

to be maintained in the GCKS and the members compared to other key

management techniques.















CHAPTER 6
A PRAGMATIC FRAMEWORK FOR SCALABLE SECURE SOURCE
SPECIFIC MULTICAST

The previous discussions of key distribution and key management were focused

mainly on scalability. Given the merits and limitations of various schemes, and

with the multicast routing architecture in mind, this section proposes a framework

for scalable key distribution and management for secure multicast.

6.1 Design Features and Requirements

Scalability is the driving force behind this framework. Much emphasis is given

for the framework to be pragmatic by considering only the widely deployed

protocols for routing and membership. The design features and requirements are

given below.

Scalability. Core ideas from lolus and GKMP, discussed in section 4 have been

used in the proposed key distribution framework. The key management scheme

using Boolean function minimization discussed in section 5.2 is used as it has many

desirable features such as cumulative member removal, and better complexity

than other schemes.

Ease of deployment. The framework is designed considering the working modes of

widely deployed protocols such as PIM-SM and IGMPv3. The entire framework

becomes more scalable by using the messages of these protocols. The framework is

free of the limitations listed earlier in subsection 4.2.4.

Why source specific multicast? In source specific multicast [11] [12], there is only

one source S, for the entire group G. The group data sent by the source to the

group is said to form a stream/channel identified by the (S,G) pair. The other

group members can become subscribers of this channel by using IGMPv3 [2] for









IPv4 and MLDv2 [13] for IPv6 protocols. The multicast delivery tree will be built

by PIM-SM [1], the most widely deployed multicast routing protocol. Based on the

previous discussion of PIM-SM, SSM mostly results in using the source specific tree

created for each (S,G). Any source multicast (ASM) is not considered in this

proposal, where any member can be a source for the group. The semantics of

operation of secure ASM is very much different from that of secure SSM. The

presence of a single source to the group in SSM suits well with many of the

applications having a potential to have multiple receivers and requiring access

control.

6.2 Key Distribution

6.2.1 Framework

Large dynamic groups do not scale well if a single key server is used. Dynamic

here denotes that the there is no restriction for the group members to join at a

particular time of the group existence or to remain in the group for a period of

time. Dynamic groups usually have bursty joins and leaves. Multicast groups are

often denoted by a pair (*, G) or by (S, G). Here represents any source for the

multicast group G, and S represents a single source S for the multicast group G. A

member of a multicast group G listening to the messages sent by a source S is said

to be a subscriber of the (S, G) channel.

In this framework, a secure distribution tree like that of Iolus is used. The

central GCKS may be replicated, and in such a case an election algorithm is used

to select a primary GCKS. The election algorithm may be simple: the GCKS with

the smallest IP address value is selected as the primary. The local key servers

(LKSs) are sent the list of IP addresses of the GCKSs. Each LKS can pick a

random GCKS and communicate with it. The LKS has to be present in the

listening zone of IGMPv3. Listening zone here means that the LKS should be able

to listen to the IGMPv3 messages sent by the members, outsiders, and by the









multicast-aware routers. This enables an LKS to find the presence or absence of

group members subscribing to an (S, G) channel immediately. There can be

multiple LKSs within the listening zone, and an LKS can also be present as a part

of the multicast aware router. Since the LKSs are present in each of the listening

zones, the local changes in membership affect only the local session key and not the

global session key. The LKS here does the same operation as that of GSI in Iolus.

The list of LKSs is sent to the joining member after initial IGMPv3 join request,

then the joining member picks a random LKS from the list of LKSs sent by the

primary LKS and communicates with it. Figure 6.1 shows an example of the

proposed framework. In the figure, solid lines represent the group shared tree

created by PIM for a multicast group, the dashed lines represent the source-specific

tree created by PIM for a particular source S for a multicast group, and the dotted

lines represent the secure unicast connections established between the LKS and the

GCKS. The thatched circles represent the primary LKS/GCKS elected by an

election algorithm.

6.2.2 Operational Overview

The detailed description of the proposed framework is given below.

Startup. The framework requires the GCKS(s) to be available when the group is

started. The list of GCKSs, public key of GCKS (a single key is used by all the

GCKSs), the address of source, and the group address are distributed using a

Session Description Protocol (SDP). The GCKS maintains the ACL, which is used

to provide access control for the group data. Only those members who satisfy the

access control procedure will be provided the group key and hence will be able to

listen to the group data.

Joins. An outsider sends a IGMPv3 join message indicating the pair (S, G) to its

multicast-aware router. The router uses PIM-SM to join the distribution tree

corresponding to (S, G). The primary LKS listening to the IGMPv3 messages will









HOSTs
"s" HOSTs


S GCKSs










S HOSTs T T HOT












Figure 6.1: Pragmatic Framework for Scalable Secure Multicast
\ 0 DR HOSTs






















send the required information to satisfy the access control procedure dictated by




provide access to the group data. Since the LKS has no means to verify access
LKS 0

























control (dic stated by tlishe group polunicasty), channeld it is nothat realiKS usitic to expect GCKS tosuch as






provide such ACL related information to every LKS, the member encrypts this
information with the public key of the GCKS. This ensures that only the GCKS
information with the public key of the GCK(S. This ensures that only the GCK(S









can decrypt this information as it alone has its private key which can be used to

decrypt it.1

The LKS uses the list of GCKSs sent via SDP, picks a random GCKS, and

establishes a secure unicast channel using IPSEC. The LKS uses this secure channel

to send the encrypted information sent by the (possible) member. The GCKS

verifies and sends OK/NOK message to LKS. If the returned message is OK then

the LKS now starts key management service and provides the member with the

secure key. If not, the failure is indicated to the rejected member and the SAs

corresponding to this sender are removed.

The LKS need not send the information sent by the possible member to GCKS

immediately; rather it may collect many such requests to join, and send them as a

bulk request to the GCKS. In this case the LKS assigns a nonce2 as the packet ID,

and the GCKS replies with the same packet ID with OKs/NOKs in the same order

as that of the corresponding request, so that the LKS can match the position of the

requests it sent with that of the replies it has received and take appropriate actions.

Usually the joins are bursty and hence this technique reduces the burden on LKS

and GCKS. If the current request sent by the possible member is the first one, then

the LKS establishes a secure unicast channel with a randomly picked GCKS and

uses it for all future communication.

Leaves. When a member sends a IGMPv3 leave message indicating (S, G)

channel, the primary LKS listening to this message immediately removes the SA

corresponding to this member and sends a member leave request to the GCKS,



1 In the private, public cryptographic key pair, if one is used for encryption the
other one can be used for decryption
2 nonce denotes the non-repeating, random sequence used in secure communica-
tion to distinguish different messages









which in turn uses it for accounting purposes. The LKS also starts the key

management service to provide the remaining members with the new session key.

The router processing the IGMPv3 leave messages sends messages to find if there

are any other listeners for this (S, G) channel, and if there is no response, removes

itself from the global distribution tree using PIM-SM. The LKS listening to the

IGMPv3 messages removes any remaining SAs for this (S, G) channel, sends the list

of members it has not heard from, and also indicates to the GCKS that it is no

more in the key distribution tree as there are no more members it has to serve.

Thus this technique enables the GCKS to compile nearly accurate billing

information (it is mentioned as nearly accurate as IGMPv3 source- and

group-specific queries are sent, and the conclusion that no member is present

subscribing to this channel is deduced only after a timeout for getting a IGMPv3

report back from at least one member subscribing to this channel).

6.2.3 Data Transmission

The data transmission scheme is adopted from the Iolus scheme. The senders

send the messages in this format: {Krand}KLKS1{Data}Krand, where Krand is the

random key generated by the sender, and KLKS1 is the local session key. The LKS

decrypts and encrypts random key with next level of local session key. The message

now will be: {Kand}KLKS2{Data}K'and. This technique reduces the necessity of

decrypting and encrypting the whole message each time with the new key. The

group members will decrypt the data after getting the random key using the local

key.

The multicast-aware router does the decryption and encryption of the key if the

LKS is a part of the router itself. If the LKS is a separate entity, then the

multicast router sends the packet as a unicast to the primary LKS and the LKS

multicasts the packet after decrypting and re-encrypting the random key with the

local session key. The router, instead of sending the packet as multicast, uses the









link address of the primary LKS, so that LKS alone processes it before

remulticasting.

6.3 Key Management

Key Management for the entire multicast group is subdivided into local key

management tasks done by LKS to manage the actual members, and the key

management task done by GCKS to manage the global session key distributed to

the LKSs. The tree-based key management scheme using Boolean function

minimization technique (see section 5.2) may be used as it has the following

desirable features.

Cumulative member removal: this is the most desirable feature as member
de-registration in most dynamic multicast groups tends to be bursty.

Number of keys maintained in the LKS: this measure is (2log2N) + 1 where N
is the number of members within LKS's listening zone, which is comparatively
fewer than the number that have to be maintained in other techniques.

Number of keys maintained in the member: this measure is (l. I..IN) + 1 where
N is the number of members within LKS's listening zone, and is
comparatively fewer than the number that have to be maintained in other
techniques.

Better overall communication and computation complexities: For N members
in the listening zone of an LKS, the single member join or leave takes
O(1.',._N) computation and communication complexities, but cumulative
member removal uses Boolean function minimization and results in fewer
messages and hence fewer computations to be done by LKS and by the
members.

The GCKS also uses Boolean function minimization to maintain the global

session key, and distributes it to the LKSs. The GCKS need not be present along

the global data distribution tree built by the multicast routing protocol PIM-SM;

rather, it may be present as a separate entity visible to the LKSs. Thus the GCKS

maintains 2/. .,_N + 1 keys, where N is the number of LKSs. The LKSs have to

maintain 1'. .tN + 1 keys for this purpose, where N is the number of LKSs. This set









of keys is in addition to the set of keys maintained by each of the LKSs to manage

keys for the actual members in their listening zones.

The analysis of the key management technique using Boolean function

minimization indicates that the single member removal requires O(log2N)

computation and communication complexities for N members. A technique to

reduce this logarithmic complexity to a constant complexity is proposed and is

explained in section 6.3.1.

6.3.1 Detailed Description

The key management scheme proposed here is an improvement to the scheme

discussed in 5.2. Here also the LKS maintains a key distribution tree, with the N

members attached to N leaves. Each member is given an unique binary string

representing its UID. The members have the n = 1.',._N keys corresponding to the

bits in their UIDs.

All the messages sent by the LKS use IPSEC, so that they can be authenticated.

In this proposal, the LKS sends the new session key encrypted with an auxiliary

key, and the members send the new session key encrypted by other auxiliary keys

according to the algorithm given below. The auxiliary keys are updated locally by

each of the member as in section 5.2.

6.3.2 Member Join

When a new member is added, the new member is given the new session key, and

auxiliary keys are sent via secure unicast channel established between the LKS and

the member. The new session key with the UID of the new member is sent in a

single multicast packet encrypted with the old session key. All the existing

members will receive the new session keys and will update the auxiliary keys

according to the UID of the new member.









6.3.3 Individual Member deletion

In this proposal, responsibility of multicasting the new session key is shared with

the members. Thus in the best case, the LKS sends only one key update message,

and each of the members will send at most one key update message to the group.

For example in Figure 5.1, for the departure of c5, the LKS sends

{UID(c5){SKne}PrKLKs}k', where UID(cs) = 101 is the UID of the member cs,

SKw,, is the new session key, PrKLKS is the private key of LKS, and k' is the

auxiliary corresponding the bit X2 = 0 in the UID. Thus, with this message,

co, ci, C2, C3 can update their session and auxiliary keys. From the UID(cs) = 101,
it is known that one multicast with kl, where kl is the auxiliary corresponding the

bit X1 = 1 in the UID, another two members can receive the session key. Both

co, cl does not have kl, but c2, C3 have kl, so each of them picks a random time and

backs off and when the timer expires sends {UID(c5){SK,,w}PrKLKs}kl. If c2

sends this message, C3 does not send this message again. Since the new session key

is signed by the private key of LKS, it is authentic. With this message c6, c7

receives the new session key. Again from the UID(c) = 101, it is known that one

multicast with k1, where k1 is the auxiliary corresponding the bit Xo = 0 in the

UID, the remaining member can receive the session key. Co, c2, c6 already have the

new session key. Each of them picks a random time and backs off, and when the

timer expires sends {UID(c5){SKe,w}PrKLKs}k'. If Co sends first c2, c6 refrain

from sending the same message. Thus c4 receives the new session key. Each

member calculates the new auxiliary keys locally.

The key update messages are sent as multicast, so the LKS will also receive the

key update messages. If there are no messages sent by the members, then the LKS

has to traverse the tree and send the new session key encrypted with the key not

held by the member being removed. Thus in the worst case LKS will be sending

O(1.' ,IN) messages.









6.3.4 Cumulative Member Deletion

The technique using Boolean function minimization 5.2 results in minimal

number of messages to be sent for cumulative member deletion. Thus this

technique is used in the proposed framework.

6.3.5 Tree Growth

When a member join results in increase of the height of the KM tree in LKS by

one, the LKS sends the growth message to the existing members with the a new

auxiliary key which is common to all the members. The message is {Knewaux}SK,

where Knewaux is the new auxiliary key, and SK is the existing common session key.

This message will also cause all the members to change their UIDs by prefixing a

'0' to their existing UIDs. For example, if the UID of a member is X,,_X,_n2...Xo

will be changed to XX,_ Xn-2...Xo where X, = 0. Clearly, Knewau corresponds

to X, = 0.

6.3.6 Tree Shrinkage

When a member deletion results in only one half of the tree (either left or right)

to contain members, the height of the KM tree in LKS can be reduced by one. The

LKS sends the shrinkage message to the existing members indicating them to

discard the key corresponding to their MSB in UIDs. This also results in the

removal of the MSB from the UIDs of all the members. For example if the UID of

a member is XnX_1Xn-2...Xo, then after removal of the MSB the UID changes to

XnXn-2...Xo. The key corresponding to X, is also discarded.

If the tree is sparsely populated by members, the half of the tree (either left or

right) with fewer members is chosen to be removed from the tree. LKS sends rejoin

messages to those members and hence removes them from the tree and assigns

them new UIDs when they rejoin. If both the halves contain equal number of

members, one half is chosen randomly.









6.4 Properties

Early Detection of member absence. Since the LKS is present in the listening

zone of IGMPv3 messages, it can detect the absence of a member and hence the

corresponding SAs can be removed. This is impossible if LKS is outside the

listening zone, where the SAs are removed only after timeout. Here, SAs will be

removed even if the member crashes; IGMPv3 messages discover such absences.

No access control information leak. LKS cannot decrypt this information sent by

the member to be sent to the GCKS.

Multiple License made easy. Since the LKS can be placed locally, an organization

can obtain multiple licenses for the entire organization and the LKS need not

indulge in key management services for each member join or deletion. The local

key can be kept constant, or the LKS can decrypt the entire message and send to

the member.

Collusion Attacks. Collusion attacks by members still exist as the key

management technique using Boolean function minimization is used.

6.5 Summary

A pragmatic framework for scalable secure source specific multicast is proposed

with scalability, and ease of deployment as the core design requirements. The

proposed framework is designed to co-exist with the multicast routing architecture

with IGMPv3 and PIM-SM. The key distribution architecture is designed with

desirable features from lolus and GKMA. The proposed key distribution scheme

localizes the group changes and hence the global session key remains mostly

constant while the local session keys may change often. The key management

scheme follows the technique using Boolean function minimization. The operations

for individual member deletion has been modified so that in the best case, the LKS

sends only one key update message, and each of the members will send at most one

key update message to the group. Cumulative member deletion is possible as







35

Boolean function minimization is used. The features like early detection of member

absence, no access control information leak, and ease of providing multiple license

enable easy deployment. Collusion attacks remain as Boolean function

minimization technique is used.















CHAPTER 7
CONCLUSION AND FUTURE WORK

7.1 Conclusion

This thesis document started with a brief explanation of the multicast routing

architecture comprising multicast group management and multicast routing

protocols. IGMPv3 is the group management protocol for IPv4, and is used by the

routers and hosts to manage the group membership information. IGMPv3 queries

and reports were explained briefly. Multicast packets are delivered using a

multicast delivery tree formed by a multicast routing protocol. PIM-SM is the

most widely deployed multicast routing protocol. PIM-SM uses a group shared tree

for lower bit rate packet delivery, and a source specific tree for higher bit rate

packet delivery.

Secure multicast is the term used to indicate a multicast service providing group

access control, source authentication, and secrecy. Secure multicast is generally

achieved by providing a symmetric cryptographic key called a session key to the

group members, and by sending the group data encrypted using the session key.

Thus only the legitimate group members will be able to decipher the group data.

The task of providing secure multicast is divided into two major subtasks namely

secure key distribution, and secure key management.

Secure key distribution involves distributing the session key securely to legitimate

group members.Iolus is the multicast key distribution framework which is highly

scalable. The components and operation of Iolus is explained. The evaluation of

Iolus with deployment as the core evaluation criteria is done and it indicates that

this architecture cannot co-exist with the already deployed multicast routing

protocols like PIM-SM. GKMA defines a common architecture and design for









different GKMPs. The components and operation of GKMA is explained. The

evaluation of GKMA with deployment as the core evaluation criteria indicates that

it does not handle bursty and flash crowds for dynamic multicast groups. General

limitations of any GKMP with respect to group secrets and policy complexity is

explained.

Secure key management involves in generating the session key and facilitating

key updates in an efficient manner. It also helps in maintaining join and leave

secrecy. A naive key management technique is explained to provide an insight on

the complexity requirements of secure key management. A tree based solution

using Boolean function minimization is explained as it solves the cumulative

member removal in an efficient manner. Cumulative member removal is the most

desirable feature for large dynamic groups in which the leaves are bursty. Other

operations are also done in logarithmic time complexity with fewer number of keys

to be maintained in the GCKS and the members compared to other key

management techniques.

A pragmatic framework for scalable secure source specific multicast is proposed

with scalability, and ease of deployment as the core design requirements. The

proposed framework is designed to co-exist with the multicast routing architecture

with IGMPv3 and PIM-SM. The key distribution architecture is designed with

desirable features from lolus and GKMA. The proposed key distribution scheme

localizes the group changes and hence the global session key remains mostly

constant while the local session keys may change often. The key management

scheme follows the technique using Boolean function minimization. The operations

for individual member deletion has been modified so that in the best case, the LKS

sends only one key update message, and each of the members will send at most one

key update message to the group. Cumulative member deletion is possible as

Boolean function minimization is used. The features like early detection of member









absence, no access control information leak, and ease of providing multiple license

enable easy deployment. Collusion attacks remain as Boolean function

minimization technique is used.

In this thesis, various issues in secure multicast have been highlighted. Important

contributions in the area of secure key distribution and key management have been

explained and reviewed with deployment as the core evaluation criteria. The review

indicates that most of the solutions are not proposed with realistic implementations

in mind. A framework for secure multicast is proposed to alleviate these

shortcomings and with ease of deployment as the essential feature.

7.2 Future Work

Key management. The following is the list of improvements that can be done for

key management:

Improved tree growth and 1,1 inl. oq,- operations: It is benefitial to build the
tree before hand to a certain height, instead of increasing the height of the
tree incrementally. The advantages are twofold: it minimizes the threat of
collusion attacks as the incremental growth of the tree results in duals 1
more often as the LKS can assign UIDs randomly. This also reduces the
overhead on the LKS during normal operation when there are lot of joins. It
is also benefitial to maintain the KM tree at a certain height for a period of
time before shrinking it. The reason is that, for dynamic groups, this may
reduce the fluctuations of KM tree from growing and shrinking alternately.
This also results in fewer keys being discarded and generated, the latter being
a costly operation.

Early generation of keys: LKS can generate multiple SKs beforehand, thereby
improving the performance during normal operation of the LKS during key
distribution.









1 duals are a pair of members whose UIDs are one's complement of each other,
resulting in the pair of members having all the keys in the KM tree















REFERENCES


[1] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V.
Jacobson, C. Liu, P. Sharma, L. Wei "Protocol Independent
Multicast-Sparse Mode (P'Ii-S 1): Protocol Specification," RFC2362,
Internet Engineering Task Force, June 1998

[2] B. Cain, S. Deering, B. Fenner, I. Kouvelas, A. Thyagarajan, "Internet
Group Management Protocol, Version 3,"
http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-v3-09.txt, Work in
progress, January 2002

[3] M. J. Moyer, J. R. Rao, P. Rohatgi, "A Survey of Security Issues in
Multicast Communications," IEEE Network, November 1999

[4] R. Canetti, P. Rohatgi, P. Cheng, \Miiltr. .-t Data Security
Transformations: Requirements, Considerations, and Prominent Choices,"
http://search.ietf.org/internet-drafts/ draft-irtf-smug-data-transforms.txt,
Work in progress, January 2000

[5] S. Mittra, "Iolus: A Framework for Scalable Secure Multicasting,"
Proceedings of AC'i SIGCOMM 1997

[6] M. Baugher, R. Canetti, L. Dondeti, "Group Key Management
Architecture," http://www.ietf.org/ internet-drafts/
draft-ietf-msec-gkmarch-01.txt, Work in progress, October 2001

[7] T. Hardjono, H. Harney, P. McDaniel, A. Colegrove, P. Dinsmore, "Group
Security Policy Token," http://www.ietf.org/ internet-drafts/
draft-ietf-msec-gspt-00.txt, Work in Progress, September 2001

[8] S. Chokhani, W. Ford, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework," RFC2527, Internet
Engineering Task Force, March 1999

[9] D. Wallner, E. Harder, R. Agee, "Key Management for Multicast: Issues
and Architectures," RFC2627, Internet Engineering Task Force, June 1999

[10] I. Chang, R. Engel, D. Kandlur, D. Pendarakis, D. Saha, "Key
Management for Secure Internet Multicast using Boolean Function
Minimization Techniques," Proceedings of IEEE Infocom, pages 689-698, 1999







40

[11] H. Holbrook, B. Cain, "Source-Specific Multicast for IP,"
http://www.ietf.org/internet-drafts/draft-ietf-ssm-arch-00.txt, Work in
Progress, May 2002

[12] S. Bhattacharyya, C. Diot, L. Giuliano, R. Rockell, J. Meylor, D. Meyer,
G. Shepherd, B. Haberman, "An Overview of Source-Specific Multicast
(SSM)," http://www.ietf.org/internet-drafts/draft-ietf-ssm-overview-03.txt,
Work in progress, March 2002

[13] R. Vida, L. Costa, S. Fdida, S. Deering, B. Fenner, I. Kouvelas, B.
Haberman, \Mltr .,-i. Listener Discovery Version 2 (MLDv2) for IPv6,"
http://www.ietf.org/internet-drafts/draft-vida-mld-v2-03.txt, Work in
progress, June 2002















BIOGRAPHICAL SKETCH


Murali M. Brahmadesam was born in Tiruchirappalli, Tamil Nadu, India, on

July 5th, 1979. He earned his high school diploma from YWCA matriculation

higher secondary school. He graduated with a Bachelor of Engineer degree with

distinction in computer science and engineering in 2000 from Regional Engineering

College, Tiruchirappalli. He came to Gainesville, Florida, to pursue a Master of

Science in Computer and Information Science and Engineering Department,

University of Florida.