Information Technology Reference
In-Depth Information
schemes assume that only a few key updates are lost, or that members will always
be able to take an immediate recovery action. Extreme examples of this approach
are key distribution mechanisms that assume a reliable group communication
middleware underneath, e.g., extended virtual synchrony semantics, in order to
update the keys reliably [8].
In the context of secure distribution of copyright protected material, it has
been carefully studied how to encrypt broadcast content so that only a dynami-
cally changing group can decrypt it (see broadcast encryption [9]), and how to
trace and exclude possible “traitors” that leak information [10]. Typically, these
schemes assume a single source and do not deal with an arbitrary number of
“traitors” colluding. Moreover, in some cases they also assume that clients cannot
update state dynamically, and this can make growing revocation information
unmanageable. On the contrary, in our approach we assume that clients update
state regularly when they are online, so we can bound the amount of revocation
information needed by making educated guesses of their state.
The closest work to our approach is discussed by Pinkas in [11]. The focus
of that paper is how to minimize the amount of information needed to recover
a client that is back on-line after missing some LKH key updates. However,
it is assumed that this information is optimized for a particular client, and
downloaded directly from the KM. Instead, we make this information client
agnostic, so that it can be multicast, and always derived from “public” infor-
mation, so that the KM does not need to get directly involved.
3
Key History Tree (KHT)
3.1
Overview
LKH is a tree based group rekeying algorithm proposed by Wallner et al. [1].
There is a single KM, i.e., LKH-KM, that creates a hierarchy of keys, associates
each member with a leaf of that tree, and communicates to each of them, within
an authenticated session, all the keys in the path from that leaf to the root.
Therefore, the root key is known by all the group members and can be used to
guarantee integrity and confidentiality of group communications. Whenever the
KM adds a new member, keys disclosed to that member preserve backward confi-
dentiality by hashing them, i.e., we assume LKH+ as described in [3]. Whenever
the KM evicts a member, forward confidentiality is guaranteed by changing all
the keys this member knows, and getting all the relevant members (but him)
to know them. For this task LKH proceeds bottom up, changing one key at a
time, and using this new key to encrypt the new key in the next level up. For
the nodes whose keys are changed, we must also encrypt the new keys with the
keys of their siblings, so that all the valid group members can decrypt them. All
these encrypted key updates are then multicast by the KM to the group.
Fig. 1 shows how KHT uses LKH. Requests to add or remove members
of a group are still directly handled by the LKH-KM. However, key update
information triggered by these interactions is first pre-processed by the KHT
Cache Manager (KHT-CM), instead of being directly broadcast to the group
Search WWH ::




Custom Search