A Survey of Key Management for Secure Group Communications

Celia Li

2

Outline

Group Communications Security Issues Requirements Classification Group Key Management Protocols

3

Group Communications

InternetInternet

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

4

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

5

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

6

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.

7

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

8

Group Key Management ClassificationThe 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

9

Naïve Solution 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 k4

K1-4

m1 m2 m3 m4

k1 k2 k3

K1-3

m1 m2 m3

Group key

Individual keys

m4 leavesm4 joins

Member

{K1-4}k1-3 {K1-4}k4

{K1-4}k1 {K1-4}k3{K1-4}k2

10

Key Tree-Based Approach

K1-8

K7-8K5-6K3-4K1-2

K1-4

Group key

Individual keys

Member

Intermediate keys

GCCentral Group Controller 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}m8m7m6m5m4m3m2m1

k8k7k6k5k4k3k2k1

K5-8

11

Key Tree-Based Approach: Join

K1-8

K7-8K3-6

Group key

Individual keys

Member

Intermediate keys

GCCentral Group Controller

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

K1-3

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)

m8m7m6m5m4m3m2m1 m9

k8k7K6k5k4k3k2k1

K1-8 K1-9 {K1-9}K1-8

{K7-9}K7-8

K7-8 K7-9

K1-9

K7-9

{K7-9}K9

{K1-9}K9

k9

12

Key Tree-Based Approach: Leave

K1-9

K7-9K3-6

Group key

Individual keys

Member

Intermediate keys

GCCentral Group

Controller

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

K1-3

m8m7m6m5m4m3m2m1 m9

k8k7K6k5k4k3k2k1

K1-9 K1-8 {K1-8}K1-3

K1-8

K7-8

k9 {K7-8}K8

{K7-8}K7

{K1-8}K3-6

{K1-8}K7-8

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)

m9 leaves the group: K7-8 K7-9, K1-8 K1-9

K7-9 K7-8

13

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

14

Subgroup Control: Iolus FrameworkSender

SGC1

m m

SK1

SGC2

m m m

SGC3

m m

SK2 SK3

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

{Data}Rand # |{Rand #}k3

SGC31

m m mSK31

SGC11

m m mSK11

{Data}Rand # |{Rand #}SK3

{Data}Rand # |{Rand #}SK31

K3K2K1

new member joins/leaves local subgroup

Subgroup controller changes its subgroup key

Other subgroup keys do not need to be changed

15

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

16

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

17

Diffie-Hellman

A = ga mod p

K= Ba mod p

K= Ab mod p

B = gb mod p

A

B

Alice Bob

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

p: large prime

(e.g. 512 or 1024 bits)

g: base generator

a: Alice’s secret integer

b: Bob’s secret integer

18

Member Control: CliquesStage 1: m1 m2 m3 m4

gs1 gs1s2

Stage 2:

Stage 3:

Stage 4:

m1

m2m3 m4

gs1s2s3

gs1s2s3

m1

m2

gs2s3

gs1s3

m3

m4

gs1s2

m1

m2

gs2s3s4

gs1s3s4

m3

m4

gs1s2s4

Group Key m1 m2 m3 m4

gs1s2s3s4 =g(s2s3s4)s1 =g(s1s3s4)s2 =g(s1s2s4)s3 =g(s1s2s3)s4

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

19

Cliques: Join

Stage 1: m4 m5{gs1s2s3, gs1s2s4’, gs1s3s4’, gs2s3s4’}

Stage 2:

m1

m2

gs2s3s4’s5

gs1s3s4’s5

m3m5

gs1s2s4’s5

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

m4 gs1s2s3s5

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

m1

m2

gs2s3s4

gs1s3s4

m3

m4

gs1s2s4

m5

joins

Old Group Key

gs1s2s3s4

s4 s4’

20

Cliques: Leave

m1

m2

gs2s3s4

gs1s3s4

m3

m4

gs1s2s4

New Group Key m1 m3 m4 m2

gs1s3s4’ = g(s3s4’)s1 = g(s1s4’)s3 = g(s1s3)s4’ ?

m1 gs3s4’

m3

m4

gs1s4’

m2 leaves

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

Old Group Key

gs1s2s3s4

s4 s4’

21

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

22

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