Tree Data Structure

Key trees differ from search trees in several points, which affect their management mode. The most significant difference relates to the fact that key trees are unordered, i.e. there is no relation between data saved in the different nodes of the tree. Recall that data stored in LKH trees represent keys, which are generated randomly. Therefore, the access to some node or leaf in the tree can not rely on the key data. This matter raises some special management issues of the key tree during joining, disjoining, or resynchronizing a member: 1. Finding a position to add a leaf in the join case is independent of the data to be stored at this leaf, i.e. the identity key of the member. Therefore, additional information must be provided to indicate the addition position. In the case of the HiFlexRP, each node saves information on both the shallowest left leaf and the shallowest right leaf in the subtree with the corresponding node as a root. By Using this information, a rekeying algorithm decides on the join point of a new leaf by looking for the shallowest leaf in the tree

Rekeying

Security Functions Key Tree

Management

Security Module Drivers _Driver FIFO

FIFO Driver KTM Driver KSM Driver Inst.

k0 k1 k2 k3 k0-1 k2-3 k0-3 Index = MEMID 0 1 2 3 Pointer to corresponding leaf MLMA

Figure 7.4. Member Leaf Map Array (MLMA)

starting at the root. In addition, the HiFlexRP employs a tree management strategy, which expands the tree from the root side to join a member in the case of full trees. By this means, the new group key must be encrypted only with the old group key and with the identity key of the new member. Not only the relating join request profits from this strategy, which is denoted as bottom-up tree growing in this work, but also following join and disjoin requests. An in-depth investigation of the advantage of this tree management strategy was provided in a student thesis under the author’s supervision [Ab05]. This strategy, however, demands a means to check the tree for fullness. For this purpose, each node contains additional information on both the deepest left leaf and deepest right leaf in the subtree with the corresponding node as a root. Accordingly, each node of the key tree is specified as depicted in Figure 7.3. Note that tree leaves are special nodes with a zero value for DSLL, DDLL, DSRL and DDRL. In addition the pointers LS and RS are initialized with NULL all the time. In contrast to static tree management, a tree leaf is not associated with a member identity MEMID. Otherwise, complex search operations must be performed to find tree leaves in the case of member disjoin or resynchronization. To avoid this, another solution is proposed as illustrated in the next point.

Figure 7.3. Key node structure in dynamic tree management

2. In the case of disjoin or resynchronize requests, the HiFlexRP receives the related member identity MEMID. To update keys, the corresponding member leaf must be found first. For this purpose, an array of pointers to tree leaves is deployed, which is indexed by the member identity MEMID. This array is denoted as Member Leaf Map Array (MLMA) in this work. Thus, a join request causes, besides setting up a new leaf, the creation of a pointer to this leaf, which is inserted into the MLMA at the array position indexed by the MEMID of the new member. By this means, an efficient access to the leaf is possible, if the related member has to be disjoined or resynchronized in future. To avoid data rearranging, the length of MLMA is assumed to be equal to the maximal group size. Figure 7.4 illustrates a MLMA for a group of 4 members.

Key

Pointer to father (F)

Pointer to

left son (LS) right son (RS) Pointer to Depth of deepest left leaf (DDLL) Depth of shallowest left leaf (DSLL) Depth of deepest right leaf (DDRL) Depth of shallowest right leaf (DSRL)

7.4

R

A

108

Obviously, dynamic tree management demands larger memory space to store auxiliary data in comparison to the static tree management, which uses only two bits (LR word) to describe the state of a help-key, whereas for identity keys no auxiliary data are required. This sparing characteristic of static tree management is attributed to using the physical structure of the key memory to keep information on the logical tree topology, as was illustrated in Chapter 5. To support a group of 131,072 members, a total of 32 KB is required to save the needed LR words. In contrast, a memory size of 4.5 MB is demanded to support the same member number using dynamic tree management. This memory size can be estimated as follows. A binary LKH tree with 131,072 members includes 131,072 identity keys and 131,071 help-keys. According to the previous analysis, each key is associated with three pointers and four auxiliary data. Furthermore, a MLMA of the size 131,072 must be created to store pointers to all identity keys. Based on the PowerPC architecture, all the pointers have a length of 32 bits. For the tree topology information such as the DSLL, a character type of the length 8 bits is used. Thus, the following memory size is estimated for the tree auxiliary data:

131,072 * 32 (for the MLMA) + 262,143 [ 3*32 (for pointers to father, left and right sons) + 4*8 (for the DSLL, DDLL, DSRL, and DDRL) ]= 4.5 MB.

However, the low memory usage is not the only advantage of static tree management. This mode enables, furthermore, higher rekeying performance compared to dynamic tree management, as will be depicted by the measurement results in Section 7.5.