1 / 20

SOT: Secure Overlay Tree for Application Layer Multicast

SOT: Secure Overlay Tree for Application Layer Multicast. Ken Yiu HKUST. Outline. Introduction Related Work Issues on ALM security Two basic approaches Secure Overlay Tree (SOT) Simulation & Results Conclusion. Introduction. Lack of widely deployed multicast-capable network

ormanda
Télécharger la présentation

SOT: Secure Overlay Tree for Application Layer Multicast

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SOT: Secure Overlay Tree for Application Layer Multicast Ken Yiu HKUST

  2. Outline • Introduction • Related Work • Issues on ALM security • Two basic approaches • Secure Overlay Tree (SOT) • Simulation & Results • Conclusion

  3. Introduction • Lack of widely deployed multicast-capable network • Application Layer Multicast (ALM) • No data confidentiality provided in ALM • Applications that require secure multicast cannot apply ALM directly • SOT – a simple and efficient approach to provide data confidentiality

  4. Introduction : Multicast Security • Multicast data is encrypted by a shared symmetric key • Forward Secrecy : user cannot decrypt future multicast data after he leaves • Backward Secrecy : user cannot decrypt past multicast data before he joins • Change keys (re-key) whenever there is a membership change s a e b d c

  5. Related Work • Security on IP multicast: • Logical Key Hierarchy (LKH) • Iolus • Assume multicast-capable network (IGMP, DVRMP, CBT, PIM-DM, etc.) • Multicasting one re-key message takes only one communication overhead

  6. Related Work : LKH Group key kg • Each user holds the keys on the path from its user key to the group key • Re-key : change all keys on the path • Re-key message overhead (multicast): • O(2 logk N) for join • O(k logk N) for leave Key-encryption key (KEK) k0 k1 User key k00 k01 k10 k11 k000 k001 k010 k011 k100 k101 k110 k111 u0 u1 u2 u3 u4 u5 u6 u7 Re-key when u2 joins: Ek’010[k’01], Ek01[k’01], Ek0[k’0], Ek’01[k’0], Ek’0[k’g], Ekg[k’g] Re-key when u6 leaves: Ek111[k’11], Ek10[k’1], Ek’11[k’1], Ek0[k’g], Ek’1[k’g]

  7. Related Work : Iolus • Multicast group is divided into subgroups (each governed by a GSA and has its own subgroup key) • Re-encryption required at GSIs • Join/Leave only affects one subgroup (change subgroup key only) • GSAs (special entities) are chosen a priori and statically configured • No size bound on subgroups GSI GSI GSC GSI GSI GSI Decryption and re-encryption required GSC : Group Security Controller GSI : Group Security Intermediary

  8. Issues on ALM security • Multicast is accomplished by unicast connections between peers • O(N) for each multicast re-key message • O(N logk N) for each re-keying in LKH • No GSAs in ALM • Can their functionalities be moved to peers? • How about large subgroups? • Minimizing average nodal processing overhead on peers for data confidentiality

  9. Two basic approaches Re-encryption: EBC[DAB[k]] • Host-to-host encryption • Large re-encryption overhead • Whole group encryption • Large re-keying overhead A D Ek[data]||EAB[k] Ek[data]||ECD[k] B C Ek[data]||EBC[k] k : random key generated by source XY : secret key shared by X and Y A D EAB[g’] ECD[g’] Eg[data] EBC[g’] B Eg[data] C Eg[data] Re-keying: EBC[DAB[g’]] g : group key shared by all users

  10. Secure Overlay Tree (SOT) • Clustering peers into subgroups • “host-to-host” between clusters • “whole group” within clusters • Balance two kinds of overhead and obtain the minimum total overhead by choosing appropriate optimal cluster size A B Source Ingress f Ek[data]||EB[k] b a h Ek[data]||Ede[k] e d Ek[data]||EA[k] c g Egress

  11. SOT (cont’d) • Split/Merge mechanism is used to maintain cluster size within the bound (m/2 < c < 2m) • Join/Leave only affects one cluster instead of the whole group • Leaders are elected from each cluster to coordinate joining, merging and splitting • Apply Internet coordinate system like GNP to obtain coordinates for clustering purpose • SOT is a framework, existing ALM protocols can be used for implementation

  12. SOT – architecture S I L E

  13. Simulation • Setup • GT-ITM TS topology : 1024 routers • Member Join: Poisson process (avg. rate λ) • Holding Time: Exponential (mean T sec.) • Random chosen data source (constant data rate R bps)

  14. Simulation (cont’d) • Typical applications:

  15. Results – optimal cluster size

  16. Results – avg. nodal processing overhead

  17. Results – relative delay penalty

  18. Results – physical link stress

  19. Conclusion • Security schemes for IP multicast are not suitable for ALM • SOT provides data confidentiality • Based on clustering of peers • Optimal cluster size • Lower nodal processing overhead • Comparable network performance

  20. Thank You !!

More Related