Security in Multicast Networks
CMPT 408 – Project presentation – Matthew Baker
Applications of Multicast Security
-
Multicast security is important for any application in which you want only a select number of
nodes be able to read the data that you send them.
A few examples:
o Pay-per-view
o Teleconferencing
o Ect.
Broadcast vs. Multicast Security
In broadcast:
-
Since you are intending to send to everyone in a network, there is little or no need to
encrypt data since everyone is intended to be a receiver.
In Multicast, you may not want users who are not in your multicast group to be able to read
the multicast data. So, it would be unwise to send unencrypted data.
This means that you would have to at least encrypt the data.
Unicast vs. Multicast Security
In unicast:
-
You only ever need to worry about connecting with a single user.
Using traditional cryptographic algorithms, similar to the ones that we have discussed in
class, you can easily setup as session using a public/shared key cryptosystem.
Unlike unicast, you would want to avoid establishing individual sessions in order to send the
multicast data to each member of the group.
Setting up a number of sessions, encrypting the data for each one, and sending the
encrypted data for each is inefficient and not scalable.
It would be more efficient to only encrypt once and send everyone in your multicast group
the same data. Then, the issue becomes giving everyone in your Multicast group the ‘group
key’.
Problems in Multicast Security
-
All four of the traditional problems with security still arise.
o Those were privacy, authenticity, message integrity, access.
These problems can become more complicated in a Multicast network.
-
In addition to the four traditional problems, there is a fifth: Scalability
Group Key Management
-
In order to illustrate the issue of scalability, consider the following example.
This is an extension of the El-Gamal’s discrete log that we covered in class.
An algorithm for generating a secret shared key
-
Alice and Bob openly agree on a prime p and a primitive element g to use
Alice picks x 2 {1, … , p-1} at random and sends gx mod p to Bob
Bob picks y 2 {1, … , p-1} at random and sends gy mod p to Alice
Alice computes (gy)x mod p = gxy mod p
Bob computes (gx)y mod p = gxy mod p
Alice and Bob use gxy mod p as their secret shared key
Trudy knows gx mod p, gy mod p, g and p. In order to get the key, Trudy must invert either gx
mod p or gy mod p (to obtain x or y), but we assumed that this is computationally hard.
-
Suppose that Bob is in charge of the current network (Bob is a RAS: Registration and
Authentication Server)
Suppose a third person, Steve, also wants to share a key with Alice and Bob.
Steve starts by sending a join request to Bob.
After Bob authenticates Steve, then Bob sends a message to Alice saying that someone else
is joining the group and that they are going to have to make a new group key.
Bob picks a new random number s 2 {1, … , p-1},encrypts it using the current group key
and sends it to Alice.
Alice and Bob now have gs mod p and send it to Steve
Steve picks t 2 {1, … , p-1} at random and sends gt mod p to Bob and Alice.
Alice and Bob compute (gs)t mod p = gst mod p and Steve computes (gt)s mod p = gst mod p
gst mod p is now the new group key that Alice, Steve and Bob share!
Clearly, from the example, we can see that we can efficiently add users to our group.
Suppose our group is now large number of users
Suppose that we want to kick somebody out of our group or someone leaves the group.
After that user leaves, we would like to make sure that they cannot have access to multicast
data that is sent in the future.
So, once again, we are going to need to generate a new group key.
Unfortunately, we cannot use the existing key to securely setup a new key without having
the user that is leaving the group be able to determine the new key.
We have to rebuild the multicast group connection from scratch!
Problem: Leave operation is not scalable!
Key Hierarchy
-
Have your RAS assign an identity key to each member when they join the multicast group.
When a member leaves the group, the RAS can send the new group key, encrypted using
the identity keys, to each of the members that are still in the group.
So, the leave operation will require n-1 messages.
Still, scalability is a problem.
Solution: Logical Key Hierarchy!
Logical Key Hierarchy
-
Each member of the group has their own identity key
Subgroups of the multicast group are given subgroup keys
This can be structured in a tree-like fashion
When a member leaves, only users that belong to the same subgroup as that user will have
to be assigned new subgroup keys
The RAS can send the new group key, encrypted with the subgroup keys, to all of the
remaining members.
Advantage: Only a subgroup of the members will need to be reconnected to the group (and
given the new group key) while the rest can receive the new group key by having it
encrypted by their subgroup key!
Notes:
-
I constructed the particular example using Discrete Log as outlined in lectures. The
generalization of the algorithm for group key generation is outlined in:
SECURITY ISSUES AND SOLUTIONS IN MULTICAST CONTENT DISTRIBUTION: A SURVEY
Paul Judge and Mostafa Ammar, Georgia Institute of Technology
From IEEE Network – January/February 2003 (P.7)
-
The outline for Logical Key Hierarchy can be found in:
HIGH PERFORMANCE REKEYING PROCESSOR ARCHITECTURE FOR GROUP KEY MANAGEMENT
Abduladi Shoufan and Sorin A. Huss, Member, IEEE
From IEEE Transactions on Computers, Vol. 58, No. 10, October 2009