Performance Analysis

In this chapter, we illustrate the communication, storage, and computational cost of our GKM scheme as follows.

Communication cost. When a member U leaves the subscription group of a program, the server needs to broadcast LEAVE(U) = hEncryptedGK(U), UpdatedToken(U)i as the rekey message for U leaving. The size of LEAVE(U) is |EncryptedGK(U)| + |UpdatedToken(U)| = (|SibKey(U)| − 1) + (|Key(U)| − 2) = 2 lg N − 3. The communication cost for each member joining is very efficient since the server does not need to broadcast any rekey messages (but a notification message) forU joining and only needs to unicast two keys (GK and K_z) to U.

Storage cost. For each program, the server needs to store 2N − 1 secret keys that consist of the group key and the auxiliary keys in a key tree T . Each member associated with the leaf node z is assigned lg N secret keys that are on the path from T ’s root node to z. To handle the key update for reconnected members, the storage cost of the bulletin is independent of

the number of group key updates since the bulletin only needs to keep the newest public token for each edge of T . Thus, the number of stored public tokens of the bulletin is only 2N − 2.

Computation cost. For each member leaving, an remaining member U decrypts the new group key from EncryptedGK(U) or computes the new group key by h. Thus, U only needs one decryption or one hash computation to update the group key. Then, U updates other auxiliary keys by using the function h or from the UpdatedToken(U). In worst cast, U needs to compute one hash value and |UpdatedToken(U)| = lg N − 2 decryptions. For each member joining, an old member only needs one hash computation to update the group key. To update the other auxiliary keys, an old member needs to compute lg N − 1 hash values.

Chapter 4 Simulation

In this chapter, we simulate LKH [24], SKD [13], and our GKM scheme and compare their communication and computation cost in Fig. ??. In these three schemes, we use crypto++ library to implement the encryption schemes as AES with 128-bit secret key and the hash functions as MD5 with 128-bit output. To simulate the real environment, we use boost library to implement the Poisson distribution with rate λ and Normal distribution with mean µ and variance σ². We simulate the number of joining requests by the Poisson distribution with rate λ. That is, in average, there are λ users join to a sub-scription group of a TV program in a unit time. For each joining user, the subscription time of a TV program is according to the Normal distribution with mean µ1 and variance σ₁². To simulate key update for the reconnected members, for each on-line member, he may become an off-line member with probability α and his off-line period of time is according to the Normal dis-tribution with mean µ₂and variance σ₂². We set the parameters (λ, µ₁, σ₁, α, µ₂, σ₂) as (10, 100, 30, 0.3, 10, 3) and our simulations are implemented with Windows 7 OS, C++ language, Intel Core (TM) 2 Due CPU U9400 (1.40

!"#$#%&'$#()'*+,'-.-$)(-'

Figure 4.1: System setup time of the server.

GHz), and 3 GB memory. Fig. 4.1 shows the initial time for systems. The performances of these three schemes are almost the same. When N = 2²0, the computation time is about 28 s.

Fig. 4.2 shows the computation time of updating keys for the server. The performances of these three schemes are almost the same. When N = 2²0, the computation time is about 1,750 ms.

Fig. 4.3 shows the communication cost in our simulation. The commu-nication cost of the SKD scheme is about half of the commucommu-nication cost of our scheme and the LKH scheme. In our scheme, when N = 2²⁰, there are about 38, 000 tokens (ciphertexts) in a unit time over the Internet and each token is 128-bit. That means, the server only needs 38, 000× 128 bit ≈ 0.58 MB bandwidth cost for maintaing a common group key to the dynamic sub-scription group of members.

!"#$%&'()*+*,&-+.$%&/*$0&1$*"#$/#12#1$

Figure 4.2: The computation time of updating keys for the server.

Fig. 4.4 shows the computation time of a member for updating his auxil-iary keys (in worst case) and the performance of these three GKM schemes are almost the same. When N = 2²⁰, in worst case, the computation time for updating the auxiliary keys of each member is only about 23 µs.

Fig. 4.5 shows the computation time of updating the group key for each member in the worst case. It is easy to see that the computation time of a member for updating the group key in our scheme is the lowest (about 2 µs) and is independent of the number of members. In our GKM scheme, each member only needs to decrypt one ciphertext or compute a hash value for updating the group key for each group key update. However, in the LKH and SKD schemes, since each member has to decrypt the auxiliary keys from his associated leaf node to the key tree root, the computation time of updating

!"##$%&'()&"%*'"+)*

Communication cost (# of tokens)

Exponent e (N = 2^e) SKD

Figure 4.3: The communication cost.

the group key for each member increases when the number of users increases.

Fig. 4.6 shows the computation time of updating keys for a reconnected member. Since the computation time is related to the height of key tree, the computation time of these three schemes increases as N increases. However, our scheme is the most efficient one since the computation time of updating keys for a reconnected member is independent of the number of group key updates in his off-line period of time. Thus, even if N = 2²⁰, the computation time of updating keys for a reconnected member is only about 20 µs.

!"#$%&'&(")'*+,"-&+".+%$/'&()0+&12+

Figure 4.4: The computation time of a member for updating his auxiliary keys (in the worst case.)

Figure 4.5: The computation time of updating the group key for a member (in the worst case.)

!"#$%&'&(")'*+,"-&+./0)+')+"112*()0+

%-03+30,"))0,&-+

4 544 644 744 844 9444 9544 9644

4 : 94 9: 54 5:

LKH OKD our scheme

Computation time (ߤs)

Exponent e (N = 2^e) SKD

Figure 4.6: The computation time of updating keys for a reconnected member

Chapter 5