Balanced LKH for Secure Multicast Josep Pegueroles and Francisco Rico-Novella

1. Balanced LKH for Secure Multicast Josep Pegueroles and Francisco Rico-Novella Telematics Engineering Department. Technical University of Catalonia Barcelona, Spain

2. Introduction • Key Management (KM) for multicast • Logical Key Hierarchy. LKH • Problems with LKH • Balanced LKH • Ongoing work • Conclusions

3. Introduction • Many commercial applications need security (also military applications) • Video/audio-conference (many-many) • WebTV (1-many) • news, on-line stock information (1-many) • All these have a common feature: Group Communication • Security for Group Communication means • Confidenciality • Authentication of the communication • Policy management

4. Security for Group Communication • Confidentiality • Cipher data sent to the group. • Distribution of keys to the participants. • Update keys when necessary. • Authentication of the communication. • Be sure the data comes from the group. • Be sure the data comes from the source • Policy Management • Who dictates the rules • How we distribute them

5. Introduction • Key Management (KM) for multicast • Logical Key Hierarchy. LKH • Problems with LKH • Balanced LKH • Ongoing work • Conclusions

6. Key Management (KM) for multicast • A secret shared by all the group members (Group Key) provides confidentiality and group authentication. • Open challenges: • Key distribution for huge groups. • Usual group size: 100, 1K, 10K, 100K and more • Re-distribution of keys for dynamic groups • The behavior of one member affects the whole group. • Reliable transmission of rekeying messages. • Confidentiality level - Perfect Forward & Backward Secrecy • No member has to be able to access group communication data... • …before joining the group. Perfect Backward Secrecy (PBS) • …after leaving the group. Perfect Forward Secrecy (PFS) The only solution:Change the group key every time membership in the group changes.

7. Naïve solution: Trivial Key Distribution • First stage • Open a secure channel with each of the members. • Send the group key • Complexity order = N [O(N)] • Rekeying when membership changes • Send the new group key, separately to each of the remaining members. • complexity O(N)

8. 6 1 1 1 1 1 1 3 3 6 Multicast Multicast 2 2 Multicast GKCs KD applied to Multicast Environment Unicast behavior Multicast behavior M5 M6 M7 Router Contradictions /Challenges Centralized Server BW usage inefficient M1 M2 Router Router Advantages Distributed scenario Bandwidth efficiency using Multicast channel M3 M4

9. Group key Group Controller Logical entities N number of members d tree degree ln ( N ) depth + 1 ln ( d ) members Tree Based algorithms • 2 types of keys • SEKs (Session Encryption Key) • KEKs (Key Encryption Key) • A Group Controller constructs a tree based hierarchy of KEKs

10. Introduction • Key Management (GKM) for multicast • Logical Key Hierarchy. LKH • Problems with LKH • Balanced LKH • Ongoing work • Conclusions

11. Logical Key Hierarchy (LKH) • Wallner, Harder, Agee NSA 1999 • Updates the group key and the key encryption key by means of the ciphering of key-nodes in a hierarchical tree where members are located at the leaves. • Achieve rekeying with only O(logN) messages instead of O(N) showed by trivial approach. • Very simple cryptographic properties. Keys are generated independently. • Different ciphering algorithms can be used (DESede, AES…)

12. KEKs stored in GKCs - d ( N 1 ) - + 1 d KEKs storedin Ms ln ( N ) + 1 ln ( d ) K0 GKCs N secure channels K11 K12 K21 K22 K23 K24 K31 K32 K33 K34 K35 K36 K37 K38 M1 M2 M3 M4 M5 M6 M7 M8 Logical Key Hierarchy (LKH) • Initialization

13. K0 K’0 K34 { K0’} K34 { K11’} K34 { K22’} K21 { K0’} K21 { K11’} GKCs K12 { K0’} K11 K’11 K12 K21 K22 K’22 K23 K24 K31 K32 K34 K35 K36 K37 K38 M1 M2 M3 M4 M5 M6 M7 M8 Logical Key Hierarchy (LKH) • Leaving Member Rekeying Messages ln ( N ) ln ( d )

14. Rekeying messages ln ( N ) ln ( d ) K0 K’0 K31 { K21’} K31 { K11’} K31 { K0’} K21 { K21’} K11 { K11’} K0 { K0’} GKCs K11 K’11 K12 K21 K’21 K22 K23 K24 K31 K32 K33 K34 K35 K36 K37 K38 M1 M2 M3 M4 M5 M6 M7 M8 Logical Key Hierarchy (LKH) • Joining Member

15. Introduction • Key Management (GKM) for multicast • Logical Key Hierarchy. LKH • Problems with LKH • Balanced LKH • Ongoing work • Conclusions

16. Join/Leave pattern for multiparty games benchmark scenario Problems with LKH • Length of rekeying messages (computation of effective bandwidth) • Latency for rekeying messages • When can the KS actually change the ciphering key • Suitability to real environments • If many changes happen suddenly, some updated keys will never be used

17. K’0 K’’0 K0 K’11 K11 K12 K’’11 K’21 K21 K’22 K22 K23 K24 K31 K32 K33 K34 K35 K36 K37 K38 M1 M2 M3 M4 M5 M6 M7 M8 Updated keys not used • M2 Leaves de group • Before the rekeying messages reach the destination members M4 leaves the group • K´11 and K’0 have not been used • The same if now M’2 and M’4 join the group Number of messages 4 Log2N

18. Lam-Gouda Proposal – Batch-LKH • Batch rekeying introduced by Lam and Gouda in 2001 • Process all joinings and leavings periodicallyinstead of individually • New joinings are located substituting leavings • If number of joinings exceeds leavings a subtree is constructed and placed under the shallowest leaf • The algorithm is efficient if and only if the tree is kept balanced all the time -> Not realistic approach.

19. 3,4 3,8 M4 M8 Lam-Gouda Proposal not balanced • Member 4 and Member 8 leave the group 0,0 1,1 1,2 2,1 2,2 2,3 2,4 3,1 3,2 3,3 3,5 3,6 3,7 M1 M2 M3 M5 M6 M7

20. 2,2 3,3 3,4 4,5 4,6 3,3 M3 M8 M3 M8 Lam-Gouda Proposal not balanced • 2 joinings and no leaving 0,0 1,1 1,2 2,1 2,3 3,7 M7 3,1 3,2 3,5 3,6 M1 M2 M5 M6

21. 2,2 3,3 3,4 4,5 4,6 2,3 3,3 3,7 M7 3,5 3,6 M8 M3 M5 M6 M8 Lam-Gouda Proposal not balanced • M5 and M6 leave the group 0,0 1,1 1,2 2,1 3,1 3,2 M1 M2

22. Introduction • Key Management (GKM) for multicast • Logical Key Hierarchy. LKH • Problems with LKH • Balanced LKH • Ongoing work • Conclusions

23. K0 K11 K21 K22 K32 K34 M2 M4 Balanced LKH • We allow members to change their position in the tree • Treat siblings of departed members as new joinings K12 K23 K24 K31 K33 K35 K36 K37 K38 M1 M3 M5 M6 M7 M8

24. Balanced LKH • Prune the tree • Regroup remaining members with new joinings following a balanced algorithm K12 K23 K24 K31 K33 K33 K35 K36 K37 K38 M1 M3 M3 M5 M6 M7 M8

25. Balanced LKH (performance evaluation) • Every batch ends with a balanced tree • Members can change their position in the tree (a modification of the GDOI is required) Tree depth evolution for different batch periods in multiparty games environments

26. Introduction • Key Management (GKM) for multicast • Logical Key Hierarchy. LKH • Problems with LKH • Balanced LKH • Ongoing work • Conclusions

27. Ongoing work • Development of a Key Server for multicast streaming servers • Development of a JAVA library for tree based key management algorithms • Simulation of rekeying algorithms for multicast using NS-2 • LKH support for GDOI • Human behavior modeling for multicast environments

28. Introduction • Key Management (GKM) for multicast • Logical Key Hierarchy. LKH • Problems with LKH • Balanced LKH • Ongoing work • Conclusions

29. Conclusions • Group communications have increasingly importance • The use of a common secret key provides data confidentiality and group authentication • The key must be updated every time membership changes (Perfect Forward and Backward Secrecy) • LKH algorithm is one of the most accepted for key management in group communications • LKH leaks some functionalities • LKH with batch rekeying does not lead to balanced trees • A new proposal have been presented

30. Contact Information Josep Pegueroles Telematics Engineering Dept. Technical University of Catalonia josep.pegueroles@entel.upc.es