Chapter 3 A Channel-based Key Management Protocol for IPTV Services
3.5 Balance Tree: A Problem of the Proposed Protocol and its solutions
The possible problem is that a tree easily becomes unbalanced, when lots of group members join and leave the group. Key management is inefficient when a tree is unbalance.
Service manager also transmits more multicasting messages when the tree is unbalance.
Therefore, keep trees in balance is needed. In this section, there are two operations to solve a possible problem of this proposed protocol: Multi-LeaveNode Operation and Multi-JoinNode Operation.
For efficiently key management in tree structure, binary searching tree is implemented in this thesis. There is more efficient in searching, adding, and deleting certain node, when implement a binary searching tree. Besides, there are two operations to manage keys and
38
maintain a tree‟s balance: Multi-LeaveNode Operation and Multi-JoinNode Operation.
Multi-LeaveNode Operation is used when more than half of tree‟s leaf nodes are vacant.
Multi-JoinNode Operation is used when the number of group subscribers is more than the number of tree‟s leaf nodes. Following sections are going to describe in detail.
3.5.1 Multi-LeaveNode Operation
When numbers of vacant leaf nodes are half more than all tree‟s leaf node, Multi-LeaveNode Operation is trigger by service providers for efficient key management. Multi-LeaveNode Operation also reconstructs a smaller tree and minimizes the service manager‟s loading as much as possible. Service manager‟s computation and transmitting messages are increasing, when service manager reconstruct a tree and new keys. Hence, minimize the service manager‟s loading also is a key issue. For those issues have described, there are two parts in this section: first is maintaining a tree‟s balance and second is key updated when a tree‟s structure is changed.
In Multi-LeaveNode Operation, there are processes to determine the method deleting nodes. A new tree then needs to be constructed and add leaf nodes depending on the tree‟s key structure. In other word, those processes are:
1. A Service manager checks that is there a sibling node of the tree‟s each vacant leaf nodes, when choosing the deleted nodes.
2. Service manager updates keys.
3. Service manager checks each interior node.
4. Reconstruct a new tree and move the old tree to a new tree. Add new leaf nodes if necessary.
5. Update keys again.
In the first and second procedures, if there is a sibling node of the vacant leaf node, service provider deletes the vacant leaf node and its upper level interior node. The
39
steps are described as following, Figure 27:
1. Delete NLeaving,NLeaving -1
2. Do “Leave Operation”:
Update KEKLeaving-2 and RLeaving-2
3. Service provider sends MPKs_Leaving {KEKLeaving-2, RLeaving-2}
Figure 27: Multi-LeaveNode Operation (1)
There is an example clearly explained in Figure 27: When delete the leaving node (NLeaving) corresponding to MPK 8, delete upper level node of leaving node (NLeaving-1) corresponding to KEK78, too. Then Leave Operation is triggered, then the two upper level node of leaving node (NLeaving-2) corresponding to KEK58 is updated through KEK58‟=H (KEK58, R56), and R58 is also updated along with KEK58, R58‟=H (KEK58‟, R58). However, NLeaving-1 don‟t need to be updated, and it already was deleted before. Service provider needs to send new messages to the sibling node of leaving node (Ns_Leaving) corresponding to MPK7. The message includes the KEK and R value of two upper level node of leaving node (KEK58‟ and R58‟).
If the sibling node of vacant leaf node is also vacant, service provider deletes four nodes: the vacant leaf node, its sibling node and its upper levels‟ two interior nodes.
The steps are described as following, Figure 28:
1. Delete NLeaving, Ns_Leaving,NLeaving -1, ,and NLeaving-2 2. Do “Leave Operation”:
Update upper levels KEKand Rvalue if there is necessary.
3. Service provider sends KEKs_Leaving-1 {KEKupper_levels, Rupper_levels}
40
Figure 28: Multi-LeaveNode Operation (2)
As shown in Figure 27. When delete the leaving node (NLeaving) corresponding to MPK 8, its sibling node (Ns_Leaving) corresponding to MPK7, and upper levels‟ two nodes of leaving node (NLeaving-1, NLeaving-2) corresponding to KEK78 and KEK58, too. Then Leave Operation is triggered, if it is a subtree in Figure 28. Then the processes of Leave Operation are same with that there is a sibling node of vacant leaf node.
After first and second steps, service manager will check each interior node. If there is/isn‟t branches the way to update key and delete node are same with above. If there are two branches, there are no actions. If there is only a branch, the interior node needs to be deleted. Its upper node‟s key needs to be updated by the R value of the interior node‟s branch node. If there is no branches, service manager needs to delete the interior node, and check upper two level nodes. This process will keep in loop until the node is root.
In the fourth procedure, the new tree needs to be reconstructed. After deleting nodes, the tree easily become unbalance, and construct a new tree is needed. A full balanced tree is supposed to build, and the size of the tree is according to the rest member in group. For example, the numbers of group member are five, then the height of full balanced tree is 4, ceil (log25)+1. The tree is binary searching tree and each node‟s number is arranged in order as described before. Service manager moves old tree to the new tree in order. However, there is a circumstance that two leaf nodes are arranged together. Service manager adds a new interior node between those two leaf nodes, and keep the tree from disorder.
41
In the last process, keys are updated more frequently if the original tree„s order is in a mess. After a balance tree constructed, the key structure will check by service manager. The ways to update keys are measuring each interior nodes‟ parents are the same with in original tree. If each interior node from leaf node to root is not same after rebalance, those interior nodes update by one of its branch‟s R values. Then service provider transmits those new keys to users who should hold those keys.
3.5.2 Multi-JoinNode Operation
When numbers of joiners are more than the tree‟s vacant leaf node, Multi-JoinNode Operation is used to construct a bigger tree. Another goal of Multi-JoinNode Operation is maintaining keys still usable in the group, and cutting down the service loading as much as possible. There are also two parts in this section:
first is maintaining a tree‟s balance and second is key updated when a tree‟s key structure is extended.
In Multi-JoinNode Operation, a full balanced binary searching tree is supposed to build. The way to build a new tree is similar with the new tree reconstruction in Multi-LeaceNode Operation. The size of the new tree depends on the all numbers of group members. After a new tree built, the original tree supposes to be the subtree of the new tree. The processes are:
1. Make a new tree whose height is ceil (log2 NAll_members ). The NAll_members is the total numbers of group member, and those numbers are summation from the original group members and new joiner, NAll_members = Noriginal_members + Njoiner. 2. Move old tree to a new tree in order. Old tree becomes the left subtree of new
tree.
3. The keys are managed and changed:
Service provider transmits KEKOldRoot {KEK NewRoot, R NewRoot}, and updates keys in the original key structure.
42
Service provider unicasts keys and relations to each joined nodes.
Take Figure 29 as an example. Assume that the height of original tree is three and the tree contains at most four members. Multi-JoinNode Operation is triggered, when the original tree is full of members and there are still more than two members need to join in the group. The original tree is shown as the left part in Figure 29 in red color.
According to those processes have described above, NAll_members are six. And the height of new tree is four, ceil (log2 6). In step two, the old tree structure is moved to new tree as a left subtree in Figure 29. The original keys in red don‟t be updated. Each old tree‟s members have another new keys and service provider transmits KEK14{KEK1-8, R1-8} to them. The rest two members are placed in the right subtree‟s vacant leaf nodes in order. The KEKs and R values in black color are generated by service provider. Service provider unicasts each new tree member keys and R values encrypted by his/her MPK.
Figure 29: Multi-JoinNode Operation
In this way, service provider doesn‟t need to generate all new keys for a new tree and unicast all members. Service provider only needs to transmit three packages and generate three keys (KEK1-8, KEK58, and KEK56) and corresponding relations.