A Decentralised Architecture for Group Key Management

Transcription

1 A Decentralised Architecture for Group Key Management andro Rafaeli upervisor: Prof. David Hutchison Computing Department Lancaster University eptember, 2000

2 Abstract In recent years many different proposals have been presented to solve the problem of multicast communication security. There are proposals that employ a central entity, which is responsible for managing the whole group, and thus is not scalable for large groups. Other proposals distribute the group key generation among all members of the group. This also does not scale to large groups because every single member of a group participates in the key generation. Yet, other proposals divide large groups into smaller ones, employing a controller for each subgroup. Although these proposals solve the problem of scalability, other issues are raised. For example, some of these schemes employ a central controller for the subgroup controllers, and thus, if the central (subgroup) controller is compromised the whole group will be disrupted. On the other hand, the proposals, which have solved this issue by removing the subgroup central controller, have introduced new problems such as interference in the data path or leaving the key generation vulnerable to attacks. In this report, we analyse a large number of different approaches to group key management and present a distributed group key management scheme called Àydra. Àydra is based on the idea of subgroups, but it does not use a central controller in order to avoid one single point of failure. Also, Àydra employs a simple protocol to select the next key generator among the subgroup controllers, and in doing so, avoids the creation of other limitations to the group communication.

3 Contents 1 Introduction 2 2 Distributing Keys Over Multicast General Overview ecuring the Communication Group Key Management Group Key Distribution urvey Centralised Approaches Distributed ubgroup Approaches Distributed Approaches Description of the Work Description ubgrouping Àydra-Master À ynchronisation Group etup À Removal Comparative Analyses Work plan Conclusion 31 1

4 Chapter 1 Introduction With multicast communication, a message is transmitted to all members of a group. Efficiency is clearly achieved since only one transmission is needed to reach all members instead of Ò transmissions to Ò members as in the case of unicast based group communication. However, it is prone to many types of security threats. Current multicast standards lack mechanisms to protect against eavesdropping, impersonation and session hijacking, leaving multicast open to the severe threats of data manipulation and theft of service or content. A mechanism to protect group communication is encryption. An encryption algorithm takes input data (e.g. a group message) and performs some transformations on it using a key; the key is a randomly generated number chosen from a large range of values. This process generates a ciphered text. There is no easy way to recover the original message from the ciphered text other than by knowing the key [60]. Applying such a technique one can run secure multicast sessions. The messages are protected by encryption using the chosen key, which in the context of group communication is called group key. Only those who know the group key are able to recover the original message. The use of cryptography implies generation and distribution of the group-key to all valid members of a group. The literature presents us with several different approaches to group key management. We can divide them in basically three main classes: centralised approaches, distributed subgroup approaches and distributed approaches. In a centralised system, there is only one entity controlling the whole group. This central controller does not have to rely on any auxiliary entity to perform access control and key distribution. Moreover, it may achieve a more reliable and synchronised key distribution. Nevertheless, with only one managing entity, the central server is a crucial point of failure. The entire group will be affected if there is a problem with the controller. The group privacy is dependent on the successful functioning of the single group controller; when the controller is not working the group becomes vulnerable because the keys, which are the base for the group privacy, are not being generated/regenerated and distributed. Furthermore, the group may become too large to be managed for a single party, thus raising the issue of scalability. In the distributed subgroup approach, the large group is split into small subgroups. Different controllers are used to manage each subgroup, minimising the problem of concentrating the work on a single place. In this approach, more entities are allowed to fail before the whole group is affected. 2

5 CHAPTER 1. INTRODUCTION 3 ome proposals in the distributed subgroups class suggest the use of a central controller managing the subgroup controllers. Even though the management is distributed among several controllers, the system depends upon the central controller to generate and distribute new keys for the subgroup controllers. This central controller is a central point of failure. The other proposals placed in this class do not make use of a central entity, but they create different issues, such as interference in the data path or leaving the key generation vulnerable to attacks. Finally, there is the distributed approach that is characterised for having no group controller. All members can perform access control. The group key is generated in a contributory fashion where all members contribute its own share to computation of the group key. Although this achieves a high scalability and fault-tolerance, it may not be safe to leave to any member to generate new keys since key generation requires secure mechanisms, such as random number generators, that may not be available to all members. ection 2 presents security problems raised when IP multicast is used as the basis for multimedia conferencing and how it can be overcome. The survey of the group key management area is reported in section 3.

6 Chapter 2 Distributing Keys Over Multicast This chapter describes the group key distribution problem experienced with IP multicast. It identifies the main problems experienced when using multicast technology to perform key distribution. 2.1 General Overview With multicast communication, a group message is transmitted to all members of the group. Efficiency is clearly achieved as only one transmission is needed to reach all members instead of Ò transmissions for Ò members as in the case of unicast based group communication. The problems start because any machine can join a multicast group and begin receiving the messages sent to the group without the sender s knowledge. This characteristic, although making the delivery of information very efficient, raises concerns about privacy and security since not every sender wants to allow everyone to have access to his communication. An example of this is a company that sells TV programs transmitted over the Internet using multicast to send the images. The requirement for the service is that only those who pay for the images are able to receive and understand them (pay-per-view). Another example is a multimedia session, where several people are gathered together to discuss some important issues or relevant matters. In this scenario, it is possible that a misconfigured or badly behaved member of the group could badly affect the session and must be thrown out. The latter example can be extended to the case where a company is using a multimedia session for an international meeting among its branches. In this case, the company may not be willing to divulge the results of the meeting to a commercial competitor. All these examples present the same characteristics. They need their communication to be hidden from outsiders and they need to control the members willing to access the group communication. 4

7 CHAPTER 2. DITRIBUTING KEY OVER MULTICAT ecuring the Communication The mechanism to protect group communication is known as an encryption algorithm. An encryption algorithm takes input data (e.g. a group message) and performs some transformations on it using a key, where the key is a randomly generated number chosen from a large range of values. This process generates a ciphered text. There is no easy way to recover the original message from the ciphered text other than by knowing the key [60]. Applying such a technique, companies from the first and third examples cited in section 2.1 can run secure multicast sessions. Their messages are protected by encryption using the chosen key. Only those who know the key will be able to recover the original message. Taking the second example, the troublesome member, expelled from the group for his misbehavior, can be kept out of the group by changing the key and not telling him the new one 1. There are some requirements that must be meet to correctly implement a key management scheme. These requirements are presented in the next section as policies to control the behaviour of the key manager. 2.3 Group Key Management This section raises and considers some important points when implementing an efficient group key management (GKM). First of all, it is important to identify the different types of relationship between sender and receiver that are most commonly found in a group communication. They are mainly separated into two classes of communication identified by the number of senders. In the first case, there is only one sender and many receivers. The so-called 1-to-n communication. A good example of this form of communication is a pay-per-view company, where only the company sends something to the group. The customers are just receivers. They are merely consumers of information. In the second case, there are many senders and many receivers. In other words, any sender may also be a receiver. This case can be visualised as an Æ-to-Æ communication. The relationship is based on equality among the members and anyone can send something to the rest of the group. A good example of Æ-to-Æ communication is a meeting using multimedia conference tools where all members may contribute to the discussion at any time. Independent of the type of communication, there are some basic functions that a group controller (GC) should perform to maintain the security of a group: 1. Authentication: Authentication mechanisms are used to allow an entity to verify whether another entity is really who it claims to be. Examples of authentication mechanisms are certificates [42] signed by trusted third parties (for example. a Certificate Authority (CA) [19]) or login 1 Note: Due to the openness of current multicast, encryption can not avoid a malicious element from flooding the group with meaningless or unwanted data. This is eventually going to change as there is a new draft for the Internet Group Management Protocol (IGMP) version 3 [11] that will enable a selection of source addresses to listen, hence eliminating the possibility of an annoying renegade member to continue to send data to the group

8 CHAPTER 2. DITRIBUTING KEY OVER MULTICAT 6 passwords [60]. It is important to avoid an intruder to impersonate a legitimate group member. 2. Access Control: The join request of a party that has been identified should be validated. Access control is performed in order to validate group members before giving them access to group communication 2 (in particular, the group key). o, the GC s first commitment is to control the group of individuals allowed to obtain a copy of the group key. This can be achieved using an Access Control List (ACL): a list of entities allowed to join the group. An individual that wants to join the group contacts and identifies himself to the GC. It then checks the individual on its ACL and if the check is positive then the new party becomes a member of the group, and will be sent a copy of the group key allowing the program to be decoded. Otherwise the join request is refused. 3. Keeping the Key ecret: If the same key is used to encrypt several messages it can be recovered by a cryptanalyst [60]. o, it is necessary to change the key at regular intervals to safeguard its secrecy. Additional care must be taken when choosing a new key to guarantee its Perfect Forward ecrecy (PF) [23]. Each key must be completely independent from any previous used and future keys, otherwise, compromised keys may reveal other keys. The key secrecy can be extended to membership changes. When a group requires backward and forward confidentiality, the key must be changed for every membership change. Backward confidentiality is used to prevent a new member to decoding messages exchanged before he joined the group. If a new key is distributed for the group when a new member joins, he is not able to decipher previous messages even if he has recorded earlier messages encrypted with the old key. Forward confidentiality is used to prevent a leaving or expelled group member to remain accessing the group s communication (if he keeps receiving the messages). If the key is changed as soon as a member leaves, that member will not be able to decipher group messages encrypted with the new key. 4. Key Distribution Algorithm: As multicast is being used for group transmission, it is generally assumed that multicast should also be used to re-key 3 the group. It is not reasonable to consider transmitting data using a scalable multicast communication and re-keying the members under a nonscalable peer-to-peer communication. If the group has thousands of members, sending them a new key one by one would not scale well. Although re-keying a group before the join of a new member is trivial 4, re-keying the group after a member leaves it is far more complicated. The old key cannot be used to distribute a new one, because the leaving member knows the old key. A group key distributor must therefore to provide other mechanisms to re-key the group using multicast messages while maintaining the highest level of security possible. 2 This is because hiding information is not the only matter. If anyone can obtain the key it does not make sense to encrypt the content at all. 3 The term re-key determines the action of distributing a new key in order to replace a previous one 4 end the new key to the group encrypted with the old one

9 CHAPTER 2. DITRIBUTING KEY OVER MULTICAT 7 5. Reliable Key Distribution: Reliability is another point toward the security offered by the GKM. Under a reliable service, the GC can guarantee key synchronisation between members. To visualise the importance of synchronisation, imagine a user at home watching a football game transmitted by an Internet TV company. uddenly one of the re-key messages is missed, the user will be unable to continue decoding and thus viewing the program. Or during a meeting, half of the group has one key and the other half another.

10 Chapter 3 Group Key Distribution urvey A simple scheme for re-keying a group with Ò members has the GC assigning a secret key to each member of the group. In order to distribute the group key, the GC encrypts it with each member s secret key. This operation generates a message Ç Òµ long which is then transmitted to the whole group via multicast. On receiving the message, a member can recover the group key from the appropriate segment of the message using its own secret key. In fact, this is not so simple. Generating one copy of the group key for each member means that the GC has to encrypt the group key Ò times and encryption is a highly time consuming operation [60]. If the group is very large (e.g. one million members), probably the GC would spend more time doing encryption than anything else. The size of the broadcast message has to be considered as well. For example, a message including all Ò copies of the encrypted group key, assuming Ò equal to one million and using the cryptographic algorithm DE [54] with a key 56 bit long, the message would have 7812Kb 1 size. A session where the membership changes very frequently becomes difficult to administrate. Even though the process is simple, the cost of using the simple scheme in large groups is very high. This leads us to search for a more scalable solution for the key distribution problem that would enable us to produce smaller messages utilising fewer resources on the GC s machine. In the following section we present several different approaches to group key distribution. They are divided in three main groups: - Centralised approaches: Only one Group Controller (GC); - Distributed subgroup approaches: The management of the group is divided among subgroup managers; - Distributed approaches: There is no explicit Group Controller and the key distribution is done by the members themselves. Each approach has its advantages and disadvantages. In a centralised system, there is only one entity controlling the whole group. This central controller does not have to rely on any auxiliary entity to perform access control and key distribution. Moreover, it may achieve a more reliable and synchronised key distribution. Nevertheless, with only one managing entity, the 1 Each encrypted group key has 8 bytes length, multiplied by one million results in 7812Kb. 8

11 CHAPTER 3. GROUP KEY DITRIBUTION URVEY 9 central server is a crucial point of failure. The entire group will be affected if there is a problem with the controller caused by mechanical malfunction or a malicious individual that hacks the system and forces the disruption of the service. Further more, the group may become too large to be managed for a single party. In the distributed subgroup approach, the large group is split into small subgroups. Different subgrop controllers are used to manage each subgroup, minimising the problem of concentrated work. The distributed control collaborates to avoid the central failure allowing more points of failure before the whole group being affected. However, this raises the question of trust relationships, where the group owner now must trust all controllers instead of just one. Finally, there is the distributed approach that is characterised for having no Group Controller. All members can perform access control, and all members contribute its share to generate the group key in a contributory fashion. 3.1 Centralised Approaches Group Key Management Protocol: The Group Key Management Protocol (GKMP) [41] [40] enables the creation and maintenance of a group key. In this approach the GC helped by the first member to join the group creates a Group Key Packet (GKP) that contains a group traffic encryption key 2 (GTEK) and a group key encryption key 3 (GKEK). When a new member wants to join the group the GC sends him a copy of the GKP. When a re-key is needed, the GC generates a new GKP and encrypts it with the current GKEK. However, as the GKEK is known by all members, there is no solution for keeping the forward confidentiality when a member leaves the group but re-creating an entirely new group without that member. Dunigan and Cao s Group Key Management: Dunigan and Cao proposed a group key management architecture [29] similar to GKMP. The architecture is composed by a group authority and a group controller. The group authority manages several groups and assigns a group controller for each group. If no group controller is previously assigned, then the first member to join the group becomes the group controller. The joined members receive two keys, namely GTEK and GKEK, just like in GKMP. The group messages are encrypted with GTEK, and when a new pair of key is generate they are distributed encrypted with the GKEK. This proposal presents the same limitation of GKMP. calable extension of Group Key Management Protocol: Poovendran et al raised [56] the problem of fault-tolerance of GKMP. Although GKMP allows any member to perform access control, only the Group Controller (GC) generates new keys. Thus, if the GC is compromised, then the group will be affect. Poovendran proposed substituting the unique GC for a panel of three GCs. It is necessary at least two of the GCs in the panel to generate the next group key. Furthermore, the same two GCs cannot participate in two consecutive key generations. Any group member can act as a GC, though at a certain time 2 The Group Key 3 Key used to encrypt future re-keying messages

12 CHAPTER 3. GROUP KEY DITRIBUTION URVEY 10 only three will be participating in the panel. Therefore, the approach with three GCs makes the group management more reliable, because the chance of two GCs failing simultaneously is smaller than just one GC failure. Nevertheless, this approach also does not solve the problem of having to create a new group after membership changes. ecure Lock: Chiou and Chen described an interesting method [18] based on the Chinese Remainder Theorem (CRT) [46] that uses a single transmission to broadcast a message to a selected set of members. In this scheme, a sender (group controller) broadcasts a message encrypted by a randomly chosen key. The key is locked and sent together with the encrypted message. Authorised members can unlock the key and decrypt the message. The lock is calculated with CRT, which is used to find a common solution for a set of congruent equations, such as: Ê ½ ÑÓ Æ ½ Ê ÑÓ Æ Ê Ò ÑÓ Æ Ò Where is the common solution, Æ ½,..., Æ Ò are positive integers that are pairwise relatively primes and Ê ½,..., Ê Ò are positive integers. Knowing and Æ, one can calculate Ê by applying ÑÓ Æ. To send a message to the group, the sender first must have assigned a different secret key ( ) and a positive integer (Æ ) to each member of the group. Now, when the sender wants to broadcast a message to the group, it chooses a randomly secret key (Ã) and uses it to encrypt the message. The sender then encrypts à with each getting the set of à encrypted keys (à =E(Ã), where E is an encryption function) and calculates the lock: Ä Ã ½ ÑÓ Æ ½ Ä Ã ÑÓ Æ Ä Ã Ò ÑÓ Æ Ò The sender finally broadcasts the encrypted message together with Ä. At receiving the message, users open the lock and recover the key ((Ã Ä ÑÓ Æ µ ), where is an decryption function) and, therefore, can recover the original message. Only members who had their secret keys ( ) and their respective Æ value included in the lock calculation can recover the original key (Ã). The length of time it takes to calculate the lock due to the heavy math operations involved in the calculation of the CRT and the large size of the lock make this approach even worse than the simple scheme described at the beginning of this chapter. Hierarchical Binary Tree: Other contributions (Wallner et al [66] and Caronni et al [16, 65]) propose the use of a Hierarchical Binary Tree (HBT). In this approach, there is a Group Controller which maintains

13 CHAPTER 3. GROUP KEY DITRIBUTION URVEY 11 k k14 k58 k12 k34 k56 k78 k1 k2 k3 k4 k5 k6 k7 k8 u1 u2 u3 u4 u5 u6 u7 u8 Figure 3.1: KEKs affected when a member joins the tree. k' {k'} k'14 {k'} k58 {k'14} k12 {k'14} k'34 k' 14 k58 k12 k' 34 {k'34} k3 {k'34} k4 k3 k4 u3 u4 {x}k, means x has been encrypted with k Figure 3.2: Necessary encryptions when a member joins the tree in the basic HBT. a tree of keys. The nodes of the tree hold KEKs. The leaves of the tree correspond to group members and each leaf holds a KEK associated to that one member. Each member receives and maintains a copy of the KEK associated to its leaf and the KEKs correspondent to each node in the path from its parent leaf to the root. The key held by the root of the tree is the group key. For a balanced tree, each member stores ÐÓ ¾ Ò keys (ÐÓ ¾ Ò is the height of the tree), where Ò is the number of members. For example, see figure 3.1, member Í ½ knows à ½, à ½¾, à ½ and Ã. A joining member is associated with a leaf and the leaf is included in the tree. All KEKs in the nodes from the new leaf s parent in the path to the root are compromised (backward confidentiality) and have to be changed. A re-key message is generated containing each of the new KEKs encrypted with its respective node s children KEK. The size of the message produced will be at most O( 2 ÐÓ ¾ Ò ). The figure 3.1 shows an example of the KEKs being affected. The new member Í received a secret key à and its leaf was attached to the node Ã. The KEKs held by nodes Ã, à ½ and Ã, which are the nodes in the path from à to Ã, are compromised. New KEKs (à ¼, à ¼ and ½ à ¼ ) were generated for the affected nodes as shown in Figure 3.2. Finally, the KEKs are encrypted with each of its respective node s children KEK (à ¼ is encrypted with à and à ; à ¼ is encrypted with ½ à ½¾ and à ¼ ; and à is encrypted with à ¼ and ½ à ¼, see Figure 3.2). The size of a re-keying message for a balanced tree has at most O(2 ÐÓ ¾ Ò) keys. Removing a member follows a similar process. When a member leaves the group, its parent node s KEK and all KEKs held by nodes in the path to the root are compromised (Forward

14 CHAPTER 3. GROUP KEY DITRIBUTION URVEY 12 k' {k'} k'14 {k'} k58 {k'14} k12 {k'14} k'34 k' 14 k58 k12 k' 34 {k'34} k3 k3 k4 u3 u4 {x}k, means x has been encrypted with k Figure 3.3: Necessary encryptions when a member is removed from the basic HBT. confidentiality), hence have to be changed. A re-key message is generated containing each of the new KEKs encrypted with its respective node s children KEK. The exception is the parent node of the leaving member s leaf. The KEK held by this node should be encrypted only with the KEK held by the remaining member s leaf. As the key held by the leaving member was not used to encrypt any new KEK, and all its known KEKs were changed, it is no longer able to access the group messages. Figure 3.3 presents what happens when a member leaves. Member Í is leaving the group and the KEKs Ã, à ½ and à are compromised. KEKs à ¼, à ¼ ½ and à ¼ are generated and encrypted with each of its respective children s KEKs. An exception was made for the à ¼. This KEK was encrypted only with à which is the remaining member s key of Æ. One-way Function Tree: An improvement in the hierarchical binary tree approach was proposed by McGrew and herman [47, 5]. Their scheme reduces the size of the re-keying message from O(¾ ÐÓ ¾ Ò) to only O(ÐÓ ¾ Ò). Here a node s KEKs is generated rather than just attributed. The KEKs held by a node s children are blinded using a one-way function and then mixed together using a mixing function. The result of this mixing function is the KEK held by the node. This is represented by the following formula: Ð Ø µ µ Ö Ø µ µµ (3.1) Where left(i) and right(i) denote respectively the left and right children of node. The function is one-way, and is a mixing function: In this approach, a member holds its KEK and the blinded KEKs of the sibling nodes of the nodes in its path to the root. Applying this information to the formula 3.1, a member is able to generate all KEKs needed. The reduction is achieved because in the original scheme when a node s KEK changed, the new KEK must be encrypted with both its children s KEKs, and in this scheme, the blinded KEK changed in a node has to be encrypted only with the KEK of its sibling node. Figure 3.4 shows an example of this scheme. Í joins the group at node Æ, which holds Ã. It forces

15 CHAPTER 3. GROUP KEY DITRIBUTION URVEY 13 g(k'14) k' {g(k'14)} k58 {g(k'34)} k12 k12 k' 14 g(k'34) k' {g(k3} k4 34 g(k3) k58 k3 k4 u3 u4 {x} k, means x has been encrypted with k g(x), means x was hash with hash function g Figure 3.4: Necessary encryptions when Í joins the tree in the improved HBT. Ã, à ½ and à to be changed. The only values that must be transmitted are the blinded KEKs Ã, à ¼ and à ¼. Each is respectively encrypted by ½ Ã, à ½¾ and Ã. The new KEKs can be calculated by every group member: à ¼ à µ à µµ, à ¼ ½ à ½¾µ à ¼ µµ and à ¼ à ¼ ½ µ à µµ. Pseudo-random Generator Tree: Canetti et al [13] proposed a slightly different approach that achieves the same communication overhead. Their scheme uses a pseudo-random generator to generate the new KEKs rather than a one-way function and is applied only on users removal. The pseudo-random generator, ܵ, doubles the size of its input (Ü), and there are two functions, Ä Üµ and Ê Üµ, that represent the left and right halves of the output of ܵ (i.e. ܵ Ä ÜµÊ Üµ, where Ä Üµ Ê Üµ Ü ). When a user Ù leaves the group, the algorithm to re-key the tree goes as follows: A new value Ö Ú is associated to every node Ú from Ù to the root of the tree using Ö Ô Ùµ Ö for the first node and Ö Ô Úµ Ê Ö Ú µ for all other Ú (where Ô Úµ denotes the parent of Ú). The new keys are generated as ¼ Ú Ä Ö Úµ. Each Ö Ô Úµ is encrypted with key Úµ (where Úµ denotes the sibling of Ú) and sent off. From Ö Ú, one can compute all keys Ú ¼, ¼, Ô Úµ ¼ up to the root node key. Ô Ô Úµµ Taking into account the example of figure 3.1, if Í ½ leaves the group (figure 3.5), nodes Æ ½¾, Æ ½ and Æ ¼ will be associate respectively with Ö, Ê Öµ and Ê Ê Öµµ and these values will be encrypted for Æ ¾, Æ and Æ, with their respective KEKs (à ¾, à and à ). Finally, the new KEKs à ½¾, à ½ and à will be Ä Öµ, Ä Ê Öµµ and Ä Ê Ê Öµµµ. Hierarchical -ary Tree: Wong et al [68] and Canetti et al [14] extended the binary tree to a -ary tree. A tree with a larger degree reduces the number of keys kept by members and GC (because the depth of the tree is diminished).

16 CHAPTER 3. GROUP KEY DITRIBUTION URVEY 14 k' = L(R(R(r))) k'14 = L(R(r)) k k'58 = R(R(r)) k'12 = L(r) k14 k'34 = R(r) k58 k12 k2 = r k34 k1 u1 k2 u2 u3 u4 u5 u6 u7 u8 Figure 3.5: New key Ö is attributed to leaf K2. Centralised Flat Table: Table 3.1: Flat ID assignment. TEK ID Bit #0 KEK 0.0 KEK 0.1 ID Bit #1 KEK 1.0 KEK 1.1 ID Bit #2 KEK 2.0 KEK 2.1 ID Bit #3 KEK 3.0 KEK 3.1 Bit 0 Bit 1 Table 3.2: Message to exclude member TEK (KEK 0.0 Ò Û ) Ì Ã Ò Û (TEK Ò Û ) KEK 0.1 ID Bit #0 (TEK Ò Û ) KEK 1.0 (KEK 1.1 Ò Û ) Ì Ã Ò Û ID Bit #1 (KEK 2.0 Ò Û ) Ì Ã Ò Û (TEK Ò Û ) KEK 2.1 ID Bit #2 (TEK Ò Û ) KEK 3.0 (KEK 3.1 Ò Û ) Ì Ã Ò Û ID Bit #3 Bit 0 Bit 1 The ETH group [65] extends their own solution proposing to change the hierarchical tree for a flat table with the effect of decreasing the number of keys held by the Group Controller. The table has one entry for the Traffic Encryption Key (TEK) and 2Û more entries for KEKs, where Û is the number of bits in the member ID. There are two keys available for each bit in the member ID. One associated with each possible value of the bit (table 3.1 shows an example with Û ). A member knows only the one associated to the state of its bit. In total, each member holds Û ½ keys. For example, a member with ¼½¼½ knows à à ¼ ¼, à à ½ ½, à à ¾ ¼ and à à ¼ (see table 3.1). When a member leaves the group, all keys known by him are changed and the GC sends out a re-key message containing two parts: The first part has the new TEK encrypted with each unchanged KEK (any member with an ID with at least one single bit of difference from the leaving member s ID can recover TEK). In the second part, each of the new KEKs is encrypted with its old KEK and with the new TEK (see table 3.2). This way, every remaining member can update their old KEKs without gaining further knowledge about the KEKs other members had.

17 CHAPTER 3. GROUP KEY DITRIBUTION URVEY 15 K4 GA 4 K3 GA 3 K1 GA 1 K6 GA 6 K5 GA 5 K2 GA 2 Figure 3.6: Iolus hierarchy. Boolean Function Minimisation: Recently, a group from IBM proposed a similar scheme [17] to the one from the ETH group. Although the IBM proposal has the same properties as the flat table, they presented an optimisation for the number of messages needed for re-keying the group based on boolean function minimisation techniques [67]. In this case, rather than always sending a message containing the new TEK encrypted by each unchanged KEK, they apply the techniques and find the smallest set of KEKs needed to re-key all remaining members. ecure Multicast Protocol: Chu et al suggest a secure multicast protocol [20]. The protocol works as follows: A member sends a package to the group including a message encrypted by a Message Key (MK) and this key encrypted with the Group Controller s public key. Thus, the GC is the only one that can decrypt the message. Therefore, when all other members receive the package, they extract the encrypted message and store it for later decryption. When the Group Controller receives the package, it decrypts the MK using its private key and sends out a new package including Ò copies of the MK, each one encrypted with a member public key. Finally, all members receive the package sent by the Group Controller and extract the MK using their respective private keys. The stored message is retrieved, decrypted and used. 3.2 Distributed ubgroup Approaches Iolus: uvo Mittra proposes Iolus [50], a framework with a hierarchy of agents that also split the large group in small subgroups. Each subgroup is managed by a Group ecurity Agent (GA). The GAs are also grouped in a top-level group that is managed by a Group ecurity Controller (see figure 3.6). Iolus uses independent keys for each subgroup and the absence of a general group-key makes membership changes in a subgroup to be treated locally. It means that changes that affect a subgroup are not reflected to other subgroups. Also, the absence of a central controller contributes to the fault-tolerance of the system. If a subgroup controller (namely, for instance, GA) fails only its subgroup is affected. The drawback is that Iolus affects the data path. It occurs in the sense that there is a need for translating the data that goes from one

18 CHAPTER 3. GROUP KEY DITRIBUTION URVEY 16 a 3 a 4 H 0,3 0 a 1 1 a 2 a 5 H 0,3 a 6 2 a 7 3 H 0,3 N 1 N 2 L 3 root node leaf Figure 3.7: An RP tree. subgroup, and thereby one key, to another. This becomes even more problematic when it is taken into account that it is the GA itself that has to manage the subgroup and perform the translations. The GA may become a bottleneck. Reversible Parametric equences: Molva presented a framework for multicast security [51] that is based on Reversible Parametric equences (RP). A function (Ý Ü µ) is called RP if it has the following characteristics: there is a sequence of n elements, such as ½ Ò ; and there is a sequence of Ò ½ elements, such as Ë ¼ Ò, where Ë Ë ½ µ, for ¼ and Ë ¼ is the initial value, and for every couple (, ), where, there exists a function such as Ë µ. The multicast group is placed in a tree, where the root of the tree is the multicast source, the leaves of the tree are group members and the internal nodes of the tree are intermediate elements in the multicast communication. Now let Ë ¼ be the information to be multicasted and let every node Æ be assigned a value ½. Every node Æ can perform function, so that when Æ receives a value Ë from its parent Æ, it computes Ë Ë µ and sends Ë to its children in the tree (note that the children can be other nodes or leaves). The leaves were assigned the function ¼ Ò, which enables them to compute Ë ¼ from Ë Ò, since Ë ¼ ¼ Ò Ë Ò µ, and therefore recovers the original data. Figure 3.7 shows an example of the Molva s scheme that is described as: 1. The root calculates Ë ½ Ë ¼ ½ µ and sends Ë ½ to Æ ½ ; 2. Node Æ ½ calculates Ë ¾ Ë ½ µ and sends Ë ¾ to Æ ¾ ; 3. Node Æ ¾ calculates Ë Ë ¾ µ and sends Ë to leaf Ä ; 4. Ä calculates Ë ¼ ¼ Ë µ and recovers the original data (Ë ¼ ). A leaf may be composed by several group members and all members in the same leaf share the same function ¼ Ò. When a membership change occurs in a leaf, the node Æ Ò receives a new value ¼ Ò and all members in the leaf receive a new function ¼ ¼ Ò. Naturally, if the membership change occurred because of member removal, the removed member will not receive the new ¼ ¼ Ò and, thus, will not be able to recover Ë ¼.

19 CHAPTER 3. GROUP KEY DITRIBUTION URVEY 17 LEAF m m KT m m BKM m m KT m m BKM BKM m m m KT LEAF TRUNCK LEAF Figure 3.8: Group Key Management Framework. K all-kd-group DKD K AKD 1 K AKD 2 K AKD 3 m m m K1 local area group m m m K2 local area group m m m K3 local area group Figure 3.9: Intra-Domain Group Key Management Elements. Hierarchical Group Key Management Framework: Hardjono et al [34] suggest a hierarchical framework for group key management. This framework follows Iolus very closely. There are two region levels, namely one trunk region and one or more leaf regions, also called intra-regions. Group members are placed inside leaf regions.the trunk region contains only Border Key Managers (BKMs), which connect leaf regions to trunk region. imple Key Managers (KMs) do not participate in the definition of the boundary between the trunk region and leaf regions The regions have their own group key and may have different group key management protocols. The messages passing from a region to another are translate from one key to the other by Key Translators (KTs) (see figure 3.8). Intra-domain Group Key Management: Hardjono et al present an intra-region group key management protocol [35]. The intradomain (leaf area) is further divided in administratively scoped areas [48]. There is a Domain Key Distributor (DKD) and many Area Key Distributors (AKD). Each AKD is responsible for one area. The group key is generated by the DKD and is propagated to the members through the AKDs. The key managers (DKD and AKD) are placed in a extra multicast group, named All-KD-group (see figure 3.9). The All-KD-group is used by the DKD to transmit the re-key messages to the AKDs. All areas in the domain use the same group key. Therefore, data packets do not need to be translated when passing from one area to another. Also, the DKD does not need to keep track of all group members, it only has to keep track of the AKDs. Nevertheless, since Intra-domain protocol employs a central controller (namely DKD) for controlling the subgroup controllers (namely AKDs). It presents the undesirable feature of allowing the whole group to be disrupted if the DKD is compromised. Also, if an AKD is unavailable all members in that area are not able to access the group communication, since they will not be able to access

20 CHAPTER 3. GROUP KEY DITRIBUTION URVEY 18 AKDs from other areas. Kronos: etia, Koussih and Jajodia proposed Kronos [61]. It is an approach driven by periodic re-keys rather than membership changes, which means, a new group key is generated after a certain period of time, disregarding whether any member has joined, left or been ejected from the group. Although Kronos can be used within a distributed framework such as IGKMP, it works differently because the DKD does not directly generate the group key. Instead, each AKD independently generates the same group key and transmits it to its members at the end of the predetermined period. For this scheme to work, the AKDs firstly have to have their clocks synchronised and they have to agree on a re-key period. The authors suggest using the Network Time Protocol (NTP) [49] for clock synchronisation. econdly, the AKDs also have to agree on two secret factors, namely à and Ê ¼, where Ê ¼ is an initial value and à is a master key. The AKDs can receive the secret factors from DKD via a secure channel. To generate the group key, name it Ê ½, the AKDs apply an encryption algorithm,, to Ê ¼ using à as the secret key (Ê ½ Ã Ê ¼ µ). The same algorithm applies for the next key generations: Ê ½ Ã Ê µ ¼. Although Kronos does not use a central controller and the subgroup controllers can generate the new keys independently, which makes the system fault-tolerant, it compromises the group security because it generates the new key based on the previous one. If one key is disclosed then it compromises all following keys. Dual Encryption Protocol: In order to solve the problem of trusting third parties, Dondeti et al proposed a dual encryption protocol [24, 27]. In their work, they suggest a hierarchical subgrouping of the members where a subgroup manager (GM) controls each subgroup. There are basically three kinds of KEKs and one Data Encryption Key (DEK). KEK ½ is shared between a GM and its subgroup members. KEK ¾ is shared between the Group Controller (GC) and the members of subgroup, excluding the GM. Finally, GC shares KEK with GM. In order to distribute the DEK to the members, the GC generates and transmits a package containing the DEK encrypted with KEK ¾ and encrypted again with KEK (GMs KEK). On receiving the package, GM decrypts its part of the message using KEK and recovers the DEK encrypted with its subgroup KEK (KEK ¾ ), which is not known by the GM. GM encrypts this encrypted DEK using KEK ½ shared with its subgroup members and sends it out to subgroup. Each member of subgroup decrypts the message using KEK ½ and then, decrypting the message using KEK ¾ (shared with GC), recovers DEK. The DEK cannot be recovered for any entity that does not know both keys. Hence, although there are third parties involved in the management (GMs), they do not have access to the group key (DEK). calable Multicast Key Distribution: RFC1949 [6], written by Ballardie, proposes a scheme to use the trees built by the Core Based Tree (CBT) multicast routing protocol to deliver keys to a multicast group. Any router in the path of a joining member from its location to the primary core can authenticate the member since the router is authenticated with the primary core. This scheme requires some modifica-

21 CHAPTER 3. GROUP KEY DITRIBUTION URVEY 19 0,0 1,0 1,1 2,0 2,1 2,2 2,3 3,0 3,1 3,2 3,3 3,4 3,5 3,6 3,7 4,0 4,1 4,2 4,3 4,4 4,5 4,6 4,7 4,8 4,9 4,10 4,11 4,12 4,13 4,14 4,15 k 0 k 1 k 2 k 3 k 4 k 5 k 6 k 7 k 8 k 9 k 10 k 11 k 12 k 13 k 14 k 15 Figure 3.10: Binary hash tree. tions to the IGMP protocol 4 [30] and assumes that CBT is deployed. Furthermore, there is no solution for forward confidentiality but re-creating an entirely new group without the leaving members. Marks: In Marks [10], Briscoe suggests slicing the time-length to be protected (such as the transmission time of a TV program) in small portions of time and use a different key for encrypting each slice. The encryption keys are leaves in a binary hash tree that is generated from a single seed. The internal nodes of the tree are also called seeds. A blinding function, such as MD5 [58], is used on the seed to create the tree in the following way: - first, the depth of the tree is chosen. The depth,, defines the total number (N) of keys (N = ¾ ). - then, the root seed, Ë ¼ ¼, is randomly chosen. In Ë, represents the depth of the seed in the tree, and is the number of that key in level. - after that, two intermediate seeds (Ð Ø and Ö Ø) are generated. The Ð Ø node is generated by Ø Ò Ë ¼ ¼ one bit to the left and applying the blinding function on it (˽ ¼ = b(ls(ë ¼ ¼ ))). The Ö Ø node is generated by Ø Ò Ë ¼ ¼ one bit to the right and applying the blinding function on it (˽ ½ = b(rs(ë ¼ ¼ ))). - the same algorithm is applied to the following levels until the expected depth is reached. Users willing to access the group communication receive the seeds need to generate the keys required. For example, figure 3.10 shows a binary hash tree of depth 4. if a user wants to participate in the group from slice time 3 to 9, it would be necessary only three seeds: Ë, as K3, Ë ¾ ½, to generate from à till Ã, and Ë, in order to generate à and Ã. This system cannot be used in situations when a membership change requires change of the group key. It works very closely to Kronos, where the keys are changes in function of the time. 4 The description of the modifications required can be found in the appendix B of the RFC1449

22 CHAPTER 3. GROUP KEY DITRIBUTION URVEY Distributed Approaches Cliques: Cliques [63, 62, 2, 3, 64] is an extension for the Diffie-Hellman (DH) key agreement protocol [22] that supports group operations. The DH protocol is used for two parties to agree on a common key. The protocol between two entities, namely and, goes as follows: 1. and agree on two common prime numbers Õ and «, such that «is primitive ÑÓ Õ. 2. and choose secret numbers Ü and Ý, respectively. 3. calculates = «Ü ÑÓ Õ. 4. calculates = «Ý ÑÓ Õ. 5. and exchange and. 6. calculates Ü ÑÓ Õ 7. calculates Ü Ý ÑÓ Õ Where Ü and Ý are secret numbers, and are intermediate values and is the common key. In Cliques, instead of two entities, the group may have Ò members. The group agrees on the pair of primes (Õ and «) described above and starts calculating distributively the intermediate values. The first member calculates the first value («Ü ½ ) and passes it to the next member. Each subsequent member receives the set of intermediary values and raises them to its own secret number generating a new set. A set generated by the Ø member will have intermediate values with ½ exponents and a cardinal value containing all exponents. For example, the fourth member receives the set: «Ü ¾Ü, «Ü ½Ü, «Ü ½Ü ¾, «Ü ½Ü ¾ Ü and generates the set «Ü ¾Ü Ü, «Ü ½Ü Ü, «Ü ½Ü ¾ Ü, «Ü ½Ü ¾ Ü, «Ü ½Ü ¾ Ü Ü. The cardinal value in this example is «Ü ½Ü ¾ Ü Ü. The last member (Ò) can easily calculate from the cardinal value ( «Ü ½ Ü Ò ÑÓ Õ). The member Ò raises all intermediate values to its secret value and multicasts the whole set. Each group member extracts its respective intermediate value and calculates. The setup time is linear since all members must contribute to generation the group key. Therefore the size of the message increases as the sequence is reaching the last members and more intermediate values are necessary. With that, the number of exponential operations also increases. Cliques API: Ateniese et al [1] discuss the design of an Application Programming Interface (API) for the scheme described above. The API, which is called CLQ API. provides simple functions that can be used by communication systems willing to provide secure group communication. The

23 CHAPTER 3. GROUP KEY DITRIBUTION URVEY 21 functions provided by CLQ API enable member to join, leave, merge and to refresh the group key. Octopus Protocol: Becker and Wille [8] proposed the octopus protocol. This protocol is also based on DH key exchange protocol. Octopus runs similarly to Cliques, although with a big difference: the large group (composed by Ò members) is split into four subgroups (Ò members each). Each subgroup agrees internally on an intermediary DH value (Á Ù ÖÓÙÔ «Ù ½ Ù Ò, where Ù is the contribution from user ) and them the subgroups exchange their intermediary values and all group members can calculate the group key. The leader member in each subgroup is responsible for collecting contributions from all its subgroup members and calculating the intermediary DH value (Á Ù ÖÓÙÔ ). Lets call the subgroup leaders,, and. First and, using DH, exchange their intermediary values (Á and Á ) creating «Á Á. Also, and do the same and create «Á Á. Then, and exchange «Á Á and «Á Á, and also and do the same. Now, all of them can calculate «Á Á Á Á. After that,,, and send to their respective Á Á Á Á Ù subgroups «, where ½ Ò µ, and all member of the group are capable of calculating the group key. Conference Key Agreement: Boyd [9] proposed yet another protocol where all group member contribute for generating the group key. The group key is generated with a combining function: Ã Æ ½ Æ Ò µ, where is the combining function, Ò is the group size and Æ is the contribution from each group member. The protocol defines that Ò ½ members broadcast their contributions (Æ ) on the clear. The group leader, for example Í ½, encrypts its contribution (Æ ½ ) with the public key of each Ò ½ group member and broadcast it. All group members who had their public key used to encrypt Æ ½ can decrypt it and generate the group key. Distributed Hierarchical Binary Tree: A distributed approach based on the hierarchical binary tree is suggested by Rodeh [59]. In this approach, the GC is completely abolished and the binary tree of keys is generated among the members. Each member knows just ÐÓ ¾ Ò keys, where Ò is the number of group members, therefore there is no entity which knows all the keys at the same time. Distributed One-way Function Tree: Another approach using hierarchical binary trees in a distributed fashion was proposed by Dondeti [25]. This protocol uses the one-way function tree proposed by McGrew and herman. The difference is that there is no centralised controlling, moreover every group member is trusted with access control and key generation. A member is responsible for generating its own key and send the blinded version of this key to its sibling. As in the centralised one-way function tree, every member knows all keys in the path from its node to the root node and all blinded keys from the sibling node to the nodes in the path to the root. DH Binary Tree:

24 CHAPTER 3. GROUP KEY DITRIBUTION URVEY 22 Perrig [55] and Kim [44] also used a hierarchical binary tree to minimise the number of key held by group members. The difference here is that group members generate the keys in the upper levels using the Diffie-Hellman algorithm rather than using a one-way function. Distributed Flat Table: The ETH group [65] extends yet its solution proposing to use the flat table in a distributed fashion with no Group Controller. In this scheme, no member knows all the keys at any time. Each member knows only the KEKs that it is entitle to. The distributed management has an inconvenience, namely that a joining member is obliged to contact a group of members to get all the keys needed. Furthermore, since many members could be changing the same key at the same time, there could be serious delays in synchronising the keys.