230 likes | 477 Views
A Survey of Key Management for Secure Group Communications. Celia Li. Outline. Group Communications Security Issues Requirements Classification Group Key Management Protocols. Group Communications. Group Communications One-to-many Many-to-many Advantages Scalability Efficiency
E N D
A Survey of Key Management for Secure Group Communications Celia Li
Outline • Group Communications • Security Issues • Requirements • Classification • Group Key Management Protocols
Group Communications • Group Communications • One-to-many • Many-to-many • Advantages • Scalability • Efficiency • Applications: Pay-per-view video, distant education, multiplayer games, online chat group NOTE: Broadcast: one-to-all Internet Internet
Security Issues • Authentication: Identifies the members of the group (senders & receivers) • Confidentiality: Content of a message must be shared only by authorized users • Integrity: Data cannot be modified without being detected • Access control: Ensures that only authorized actions can be performed (e.g., restricting membership, restricting who can send data) • Non-repudiation: Ensures that an originator cannot deny sending a message. • Availability: Ensures that authorized actions can in fact take place Security Mechanism: Group Key Management
Group Key Management • To provide secure distributions & handling of cryptographic keying materials • Group Key • A piece of secret information that is known only to the current group members • Used to encrypt message • Membership changes trigger rekeying process • Join: a new group key must prevent the new member from decoding previous messages • Leave: a new group key must prevent former group members from decoding future messages • Group Key Management Problem: • How to ensure that only legitimate users have access to the group key
Requirements for Group Key Management (1) • Group key secrecy • Computationally infeasible for a passive adversary to discover a group key • Forward secrecy • Evicted users cannot learn any future keys • Backward secrecy • New users should not have access to any old keys • Key independency • Disclosure of a key does not compromise other keys.
Requirements for Group Key Management (2) • Scalability (1-affects-n) • A membership change should affect only a small subset of members • Reliability • Providing a recovery mechanism for missing rekeying messages • Resistance to attacks • From both inside and outside the group • Low bandwidth overhead • Rekeying should not induce a high number of messages
Group Key Management Classification The entity who exercises the group control • Centralized Group Control • A single entity is the group controller who is … • Responsible for key generation, key distribution and key refreshment • Ex: Naïve Solution, Key tree-based Approach • Subgroup Control • The group is divided into subgroups • Each subgroup is managed by its own controller • Ex: Iolus Framework • Member control • No group controller • Each member contributes its share toward group key generation • Ex: Contributory key agreement supported by the Diffie-Hellman algorithm: Cliques
Naïve Solution K1-3 Group key • Group Key vs Individual Key • Used to encrypt messages • Used to verify each member’s identity • Rekeying Message • Used to notify all members of any key change and the new key information • Join • Encrypt new group key with the old group key and multicast to group • Encrypt new group key with new user’s individual key and unicast to the joining user • Number of rekeying messages: O(1) • Leave • Encrypt new group key with each user’s individual key and Send it to remaining users one by one • Number of rekeying messages: O(n) • Problem • Not scalable when users leave k1 k2 k3 Individual keys m1 m2 m3 Member {K1-4}k1 {K1-4}k2 {K1-4}k3 m4 joins m4 leaves K1-4 k1 k2 k3 k4 m1 m2 m3 m4 {K1-4}k1-3 {K1-4}k4
Key Tree-Based Approach Central Group Controller GC • Key Tree • Root: group key, encrypt/decrypt multicast data packets • Leaf: member’s individual key • Nodes between leaves and root: intermediate keys, that are used to encrypt other keys instead of actual data • Each member stores the keys from leaf to the root • m1: {k1, k1-2, k1-4, k1-8} • m6: {k6, k5-6, k5-8, k1-8} K1-8 Group key K1-4 K5-8 Intermediate keys K1-2 K3-4 K5-6 K7-8 Individual keys k1 k2 k3 k4 k5 k6 k7 k8 m1 m2 m3 m4 m5 m6 m7 m8 Member
Key Tree-Based Approach: Join K1-8 K1-9 Central Group Controller GC {K1-9}K1-8 K1-9 K1-8 Group key {K1-9}K9 K7-8 K7-9 Intermediate keys K1-3 K3-6 K7-8 K7-9 {K7-9}K7-8 {K7-9}K9 Individual keys k1 k2 k3 k4 k5 K6 k7 k8 k9 m1 m2 m3 m4 m5 m6 m7 m8 m9 Member • Keys along the path need to be changed • Every changed key is encrypted with old keys, multicast to the group except newly join member • New member gets keys through unicast • Number of rekeying messages: O(logkn) • m9 joins the group: K7-8 K7-9, K1-8 K1-9 • GC {m7, m8}: {K7-9}K7-8 • GC {m1, …, m8}: {K1-9}K1-8 • GC {m9}: {K7-9, K1-9}K9 • # of rekeying: At most 2logkn
Key Tree-Based Approach: Leave K1-9 K1-8 GC Central Group Controller {K1-8}K1-3 K1-9 K1-8 {K1-8}K3-6 Group key {K1-8}K7-8 Intermediate keys K1-3 K3-6 K7-9 K7-8 K7-9 K7-8 {K7-8}K7 Individual keys {K7-8}K8 k1 k2 k3 k4 k5 K6 k7 k8 k9 m1 m2 m3 m4 m5 m6 m7 m8 m9 Member K7-8 K7-9, K1-8 K1-9 m9 leaves the group: • Keys along the path need to be changed • Every changed key is encrypted with each of its children’s keys • Number of rekeying messages: O(logkn) • GC {m7}: {K7-8}K7 • GC {m7}: {K7-8}K8 • GC {m1, m2, m3}: {K1-8}K1-3 • GC {m4, m5, m6}: {K1-8}K3-6 • GC {m7, m8}: {K1-8}K7-8 • # of rekeying: At most klogkn
Centralized Group Control • Advantages • Key tree structure reduces the number of rekey message to O(logkn) • Suitable for general multicast sessions having small to medium sizes such as Internet radio and stock quote services • Disadvantages • Single point of failure at the central controller • Not scalable for very large groups
Subgroup Control: Iolus Framework Sender {Data}Rand # |{Rand #}k3 K1 K2 K3 SGC1 SGC2 SGC3 {Data}Rand # |{Rand #}SK3 m m m m m SGC11 m m SGC31 {Data}Rand # |{Rand #}SK31 SK1 SK2 SK3 m m m m m m SK11 SK31 • SGC: subgroup controller • Ki: subgroup controller’s individual key • SKi: subgroup key • Sender generates a random number to encrypt actual data • The random number is encrypted by each subgroup controller’s individual key • new member joins/leaves local subgroup • Subgroup controller changes its subgroup key • Other subgroup keys do not need to be changed
Subgroup Control: Iolus Framework • Advantages • Easier group management as a large multicast group is organized into smaller subgroups • Eliminating the problem of concentrating the workload on a single group controller • Suitable for general multicast sessions with globally distributed members such as pay-per view international news and movie systems • Disadvantages • Members cannot access group communications if their subgroup controller fails • Introducing message delivery delay as subgroup controllers have to perform key translation • Not suitable for real-time multicast applications such as video-conferencing
Member Control • No group controller • Every member contributes a share towards the group key • Requires knowledge of group membership • Example protocol: Contributory key agreement supported by the Diffie-Hellman algorithm: Cliques
Diffie-Hellman Alice Bob • p: large prime (e.g. 512 or 1024 bits) • g: base generator • a: Alice’s secret integer • b: Bob’s secret integer A = ga mod p K= Ba mod p K= Ab mod p B = gb mod p A B K=Ab mod p = Ba mod p = gab mod p • DH allows two individuals to agree on a common symmetric key • It has been proved that nobody else can compute the shared key gab in a reasonable amount of time even though they know ga and gb • ga is used to represent ga mod p
Member Control: Cliques gs1 gs1s2 m4 Stage 1: m1 m2 m3 • Cliques arranges the group member in a logical liner structure and passes key information sequentially • Group members are indexed • The last two members (having the highest indices) are responsible for taking part in key distribution • The last member does the key distribution m1 gs1s2s3 Stage 2: m4 m3 m2 gs1s2s3 m1 gs2s3 gs1s3 Stage 3: m2 m4 m3 gs1s2 m1 gs2s3s4 gs1s3s4 Stage 4: m2 m4 m3 gs1s2s4 Group Key m1 m2 m3 m4 gs1s2s3s4=g(s2s3s4)s1 =g(s1s3s4)s2 =g(s1s2s4)s3 =g(s1s2s3)s4
Cliques: Join m5 m1 s4 s4’ {gs1s2s3, gs1s2s4’, gs1s3s4’, gs2s3s4’} gs2s3s4 m4 m5 Stage 1: gs1s3s4 joins m2 m4 m1 m3 gs1s2s4 gs2s3s4’s5 gs1s3s4’s5 m2 Stage 2: m5 Old Group Key m3 gs1s2s4’s5 gs1s2s3s4 gs1s2s3s5 m4 New Group Key m1 m2 m3 m4 m5 gs1s2s3s4’s5 = g(s2s3s4’s5)s1 =g(s1s3s4’s5)s2 =g(s1s2s4’s5)s3 =g(s1s2s3s5)s4’=g(s1s2s3s4’)s5 • new member mn+1 replaces member mn to distribute partial keys • mn factorizes out his secret number from all factorized partial keys; adds a newly generated secret number sn’; sends it to mn+1 • mn+1 adds his own secret number and sends the new partial keys back to the corresponding members
Cliques: Leave s4 s4’ m1 gs2s3s4 m1 gs3s4’ m2 leaves gs1s3s4 m2 m4 m4 m3 gs1s2s4 m3 gs1s4’ Old Group Key New Group Key m1 m3 m4 m2 gs1s2s3s4 gs1s3s4’ = g(s3s4’)s1 = g(s1s4’)s3 = g(s1s3)s4’ ? • mn generates a new secret number sn’ • mn computes new partial keys excluding departure member’s secret number; sends them to the other members • Departure member has no information to compute the new group key
Member Control: Cliques • Advantages • No single point of failure (no central controller) • Robust due to self-stabilization • Single function handles join and leave • Suitable for a multicast system having a small size and a less powerful server or no centralized server, such as video conferencing • Disadvantages • Heavy workload on the member who does key distribution • Not scalable: number of rekeying messages is O(n) • Requires knowledge of group membership
Conclusion Key Management for Secure Group Communications • Centralized Control • Easy to implement; concentrated high overhead on a single entity; not scalable • Subgroup Control • Membership changes in a subgroup does not affect other subgroups more scalable • Member Control • Member-driven design; higher workload on the member who does key distribution