Abstract
In a secure group communication, messages between a group coordinator and members are protected by session keys. If a group’s membership changes, the session keys should be updated to insure forward secrecy and backward secrecy. Zhou and Huang proposed a key-updated scheme based on ciphertext-policy attribute encryption algorithm to improve the security of key-update mechanism, but their scheme is vulnerable: a malicious group member may send forged key-update messages to control the group. In this paper, we analyze the vulnerability in Zhou and Huang’s scheme and propose an enhanced scheme. In our scheme, only the group initiator can update group keys and the verification of key-update mechanism is improved to prevent malicious insiders from controlling the group. We also give a security and performance analysis of our scheme.
1. Introduction
In recent years, social networks such as Google+, Facebook, and Twitter are receiving wide popularity and provide much convenience in people’s daily life. In a social network, people can maintain their own social circles freely, such as adding or removing their friends and sharing messages to specific members within a group.
Social networks are based on cloud computing technology. In a cloud service, users’ data and documents are not stored in their computers, but on cloud servers. In most cases, users’ data is not encrypted and, therefore, is vulnerable to system vulnerabilities, unauthorized access, and privacy leak under government’s censorship [1–3].
The secure multicast technique can be used to enhance users’ privacy in social networks [4]. For secure multicast, the confidentiality of group communication is secured because group members share a session key to de/encrypt their communications. Once a group member leaves a group or a new member joins a group, their group key must be renewed. A group coordinator has to rekey the group. He needs to ensure that a new group key is delivered to every new member through a secure channel and that every old member’s key is updated simultaneously. By this, new members are not able to access previous messages, and those who have left a group cannot access the group’s new messages. This guarantees the forward and backward secrecy in group communication and has made key updating an important issue for secure multicast.
Chang et al. [5] propose Flat Table (FT) for key management in a binary tree. A group coordinator only needs to store keys and each member can join subgroups. To have higher flexibility of data encryption, Attribute-Based Encryption (ABE) [6–9] and Ciphertext-Policy Attribute-Based Encryption (CP-ABE) [10] are proposed. Bethencourt et al. [11] propose CP-ABE for multicast key management. It features complex access control on encrypted data. Zhou and Huang [12] combine FT and CP-ABE to present Efficient Group Keying (EGK). EGK is more efficient for a group coordinator to rekey his group, and the size of its ciphertext is fixed. No matter how its membership changes, the size of its ciphertext remains the same. EGK is also able to keep its storage within , where denotes the maximum members. Huang et al. also come up with secure virtual trust routing and multicasting, aiming to apply EGK to networking routing [13]. Jia et al. propose a layered EGK architecture [14]. Huang et al. proposed a cloud solution of EGK [15]. As each mobile device is seen as a service node, they propose to process mobile cloud data through trust management and private data isolation.
However, we have discovered certain security issues in the EGK model. For example, a malicious group member may launch the following attacks within EGK. (1) He may perform Man-in-the-Middle (MITM) attacks to intercept group communications and modify the group coordinator’s messages. (2) He may masquerade as the coordinator and forge the key-update message and become the new coordinator. In Jia et al.’s EGK-based scheme [14], we have also found the threat of desynchronization because the group members cannot verify whether the messages are sent from the coordinator.
In this paper, we analyze the security issues in EGK and propose a new secure key management scheme. Our scheme resists the MITM attack and masquerade attack. The rest of this paper is organized as follows. In Section 2, we analyze the vulnerability of EGK. We describe our scheme in Section 3 and give a performance analysis in Section 4. A conclusion is drawn in Section 5.
2. EGK Scheme
Zhou and Huang [12] propose an Efficient Group Keying (EGK) method that is based on Ciphertext-Policy Attribute-Based Encryption (CP-ABE). Following CP-ABE’s policy, EGK takes each bit of group members’ ID as an attribute. The group key is calculated by using the combination of specific group members.
When a new member joins a specific group, the coordinator generates a new group key and sends it to the new member by a secure channel and uses the old group key to encrypt the new one and sends it to the members. When a member leaves the group, the coordinator uses the Quine-McCluskey algorithm [16] to update the new group key.
The notations used in EGK are listed in Notations.
2.1. Initial Stage
At this stage, a group coordinator creates a group and the maximum membership of the group is . The length of an is designed as The total number of ’s is , and the total number of ’s is too. Consider ; denotes that the th bit of is 1; denotes that the th bit of ID is 0. Consider ; consider , ; maps , maps , maps , and so on. Then, the coordinator generates a master key and sets the parameters of a bilinear map function, such as , , , , and . At last, he generates a hash function and defines the public parameter .
2.2. Assign Private Key to Group Member
When a new member joins a group, the group coordinator gives to the member a unique and associates the member with an attribute . For example, there is a group whose maximum membership is 64, and the length of the is . The coordinator assigns to the new member and accordingly associates the member with the attribute . Then, he runs the algorithm KeyGen(MK, ) to generate a private key for the new member:(1)He generates a random value .(2)He calculates .(3)According to , he calculates .(4)He performs the mapping of and , .(5)He generates a private key for the new member.(6)At last, the coordinator sends , , , and current session key to the new member through a secure channel.
2.3. Encryption/Decryption Algorithms
When a group coordinator is going to multicast a message, he can use a different bit-assignment to assign specific members to decrypt the message. Then, he has to run the Quine-McCluskey algorithm to minimize all group members’ IDs. The IDs are compared in pairs and reduced until there is no pair with only one bit different. The irreducible IDs are taken as attributes for encryption: , where and denotes the number of irreducible IDs. After the coordinator runs the encryption algorithm for each attribute, he generates the encrypted messages for multicast: , . For example, a group coordinator is going to multicast three members whose IDs are 001001, 001011, and 111000, respectively. After minimization through Quine-McCluskey algorithm, the IDs are reduced as 111000 and 0010x1, where denotes a negligible bit. Next, the coordinator maps the reduced IDs with as attributes and . Consider and .
With the attributes, the coordinator runs the encryption algorithm in detailed steps as follows:(1)converting ’s into ,(2)calculating ,(3)generating a random value ,(4)calculating ,(5)calculating ,(6)calculating ,(7)generating a ciphertext .
After group members receive the encrypted messages, they use their private key and the public parameter to run the decryption algorithm, DEC():(1)The group member verifies whether ’s matches his own attribute . If the two match, the member proceeds to the next step. If they do not match, the decryption algorithm ends.(2)He converts ’s into and calculates the sum: .(3)He calculates .(4)He calculates .(5)He calculates . = .
2.4. Key-Update Stage
When a new member joins a group, the group coordinator generates a new group key and uses the previous group key to encrypt to the new member. Then, he sends , , , and to the new member through a secure channel. If a member leaves a group, the rekeying process will be divided into two parts: the group coordinator and the group member.
The group coordinator has to run the following steps:(1)Generating a random value .(2)Updating his master key .(3)Generating a rekeying message .(4)Running Quine-McCluskey algorithm to minimize the remaining members’ IDs until there are irreducible IDs; these IDs are taken as attributes , .(5)Using each attribute to run the encryption algorithm ENC.
After receiving the ciphertext, the group members run the following steps:(1)Performing the decryption algorithm DEC(Params, SK, ) and retrieving .(2)Multiplying by his private key’s and obtaining , .(3)Updating his session key .
3. Security Issues in EGK
3.1. Malicious Member and Man-in-the-Middle Attack
In EGK, a malicious member may decrypt the group coordinator’s message and send the forged message to the members who are associated with the same attributes. The victim members may update their keys and consequently cause desynchronization with the coordinator. Thus, the group coordinator is replaced and the malicious member plays the man in the middle. He takes control of the group. Detailed steps are as follows.
A malicious member decrypts , a valid ciphertext of earlier sessions. He calculates , , , and :(1)He retrieves from as ; that is, .(2)He generates a random value and requires , so that ; that is, . He also forges a rekeying message .(3)He multiplies by and the result is .(4)He sends a forged ciphertext .
Therefore, the malicious member can bypass the encryption algorithm ENC and sends a forged ciphertext without the group coordinator’s master key MK. After receiving , the members run the decryption algorithm DEC. Detailed steps are as follows:(1)Calculating .(2)Calculating .(3)Calculating .(4)Calculating .(5)Calculating = .
After decryption, they retrieve the rekeying message and process to rekey themselves. They calculate and then calculate the current session key .
Under such MITM attacks, the compromised members’ private keys become , which is desynchronous with their group coordinator’s in his master key MK. Here, we assume that the group coordinator sends a new rekeying message , uses Quine-McCluskey algorithm to minimize the members’ IDs until there are irreducible IDs and their attributes are , , and multicasts the ciphertext to each member , . The compromised members receive their ciphertext and run the following steps for decryption:(1)Calculation of .(2)Calculation of .(3)Calculation of .(4)Calculation of .(5)Calculation of = .
After the division in step (5), the compromised members are unable to retrieve the key-update message . However, the malicious member can repeat the same rekeying process and successfully update the group’s private keys and session key. Then, the malicious member is able to replace the coordinator and take control of the group.
3.2. Full Modification of Group Coordinator’s Ciphertext
A malicious member may modify the whole ciphertext, except , in the following steps:(1)Calculating .(2)Calculating .(3)Calculating .(4)Multiplying by to forge .(5)Calculating .(6)Calculating .(7)Sending the forged message : .
After receiving , the group members run the decryption algorithm DEC():(1)The group members verify whether the received matches their own . If the two are verified, they proceed to the next step. Otherwise, they end the algorithm.(2)They convert the -associated into and then calculate the sum .(3)They calculate .(4)They calculate .(5)They calculate .(6)They calculate .(7)They calculate = = .
After the decryption procedure, they retrieve , calculate , and update their current session key .
In EGK, even though a malicious member is unable to decrypt his group coordinator’s ciphertext, he can forge a message and then try the steps of Sections 3.1 and 3.2. Maybe some members are able to decrypt two ciphertexts, for example, and , but they can still receive the forged message. Since they do not verify the sender, they just retrieve and update their keys and hence the desynchronization between them and their group coordinator.
4. Secure Key Distribution Scheme for Multicast Communication
4.1. Initial Stage
At this stage a group coordinator creates a multicast group with maximum members, generates system parameters , defines two hash functions and , generates three random values , requires , sets the length of ID as , creates bit-assignment sets , where denotes that the th bit of ID is 1 and denotes that the th bit of ID is 0, and creates sets of bit-assignment secrets , where , . maps . That is, maps , maps , and so on. Further, a group coordinator generates his master key and the public parameter , where .
4.2. Key Distribution
When a new member joins the group, the group coordinator assigns a unique ID to the member and associates him with an attribute . Then, the group coordinator runs KeyGen() to generate a key:(1)He generates a random value .(2)He calculates .(3)He uses to compute .(4)He maps with , .(5)He generates a private key .At last, the group coordinator multicasts ID, , , and current session key SEK to the new member through a secure channel.
4.3. Encryption and Decryption Algorithm
When a group coordinator needs to multicast his group, he assigns a unique set of bit-assignment to each group member, so that each member is able to decrypt their ciphertext. Also, the coordinator uses the Quine-McCluskey algorithm to minimize remaining members’ IDs and then calculates attributes . He runs ENC to encrypt and members run DEC to decrypt it.
The group coordinator runs ENC() that(1)calculates ,(2)converts the -associated into ,(3)calculates ,(4)calculates ,(5)calculates ,(6)calculates ,(7)generates : .
After receiving the ciphertext, group members verify whether their own matches ’s bit-assignment. If verified, they run the decryption algorithm DEC(). Besides, during decryption, they have to check if the sender of is their group coordinator. Steps are as follows:(1)Conversion of the -associated into .(2)Calculating .(3)Calculating .(4)Calculating .(5)Calculating .(6)Dividing by and the result is = .(7)Calculating .(8)Verifying if .
4.4. Key-Update Stage
If a new member joins a group, the group coordinator generates a new session key and uses the previous session key to encrypt it to his group members. Also, through a secure channel, the coordinator multicasts ID, , , and to the members. If a member leaves a group, the coordinator and his members proceed to different steps.
Group coordinator performs the following:(1)He generates a random value .(2)He updates his master key .(3)He generates a rekeying message .(4)He uses the Quine-McCluskey algorithm to minimize remaining members’ IDs until there are irreducible IDs and these IDs are taken as attributes , .(5)He runs ENC() for each attribute.
Group members perform the following:(1)After receiving the ciphertext, each group member runs DEC() and retrieves .(2)They multiply by and the result is .(3)They update their session key .
5. Security Analysis
5.1. Malicious Member and MITM Attack
We assume a malicious member is in a group coordinator’s communication group. He receives the latest rekeying message and then forges a fake one to other group members. The forged message may arrive before the group coordinator’s rekeying message and successfully rekey the members. By this, the malicious member can cause asynchrony between group members and their coordinator.
After receiving group coordinator’s , the malicious member retrieves , , , and and calculates , , and . He tries to forge a message and sends the fake ciphertext to other members. Following the decryption algorithm, the members decrypt the fake ciphertext and retrieve . According to the 7th step of decryption, they calculate . At the 8th step, they calculate , which does not match , hence an unsuccessful attack.
5.2. Malicious Member and Asynchrony
We assume a malicious member belongs to a group coordinator’s communication group. He is able to decrypt and retrieve the coordinator’s rekeying message. He forges a rekeying message and sends it to other group members. is the previous ciphertext from the group coordinator:
With and , the group members have updated their private keys . The malicious member forges a rekeying message . Since he has had , he uses it to calculate and tries to generate . He has to use to run the following steps:(1)Summing up the previous attributes ; thus, .(2)Calculating .(3)Calculating .(4)Calculating .
Since , it does not match .
5.3. Backward Secrecy
If a group coordinator removes a member from the group, he updates his own master key and runs the encryption algorithm ENC to generate a rekeying message to the remaining members. After receiving , the members update their private keys and calculate a new session key . Because the removed member does not have , he cannot calculate a new private key and session key.
5.4. Forward Secrecy
When a new member joins a group, the group coordinator generates a new session key and uses the previous session key to encrypt to his group members. Then, he sends to the new member through a secure channel. In doing so, the new member is unable to access previous messages.
6. Performance Evaluation
In our secure multicast group communication protocol, a group coordinator has to store a set of a public parameter, a master key, and a session key, that is, . It consists of five real numbers, two hash functions, one mapping function, and two sets of bit-assignments.
As for our computational load, a group coordinator calculates one hash function, one mapping, and three exponentials when running the encryption algorithm. When a group member decrypts a ciphertext, the decryption algorithm requires four mappings and one hash. As listed in Table 1, if there are attributes after the minimization, our key-updating requires times of encryption, that is, hash functions, mappings, and 3m exponentials.
Compared with EGK, our encryption algorithm requires sender verification; therefore, it needs to compute one more hash. And our decryption algorithm requires group members to verify messages, so it needs to compute one more hash and one more mapping.
Take Facebook as an example. We assume that it uses our scheme; its member limit is 5000 (); each user is a group coordinator; each user is also a member of his friends’ groups. Thus, each user has a master key, () public parameters, and () session keys, as shown in Table 2.
In our scheme, a group coordinator’s communication load is in linear increase with the minimized attributes. If there are attributes after minimization, he has to generate rekeying messages. Each message consists of one and three variables , , and (see Table 3).
Despite having one more hash and one more public parameter compared to EGK, our system’s storage requirement is the same as EGK’s. And the two schemes’ communication loads are also the same.
7. Conclusion
In this paper, we analyze Zhou and Huang’s key distribution scheme for multicast group communication and find it prone to MITM and desynchronization attacks. These security issues can cause a group coordinator to lose the control over his group and fail to rekey his members. We propose a scheme to enhance the security of EGK. Our scheme guarantees forward and backward secrecy, prevents message modification and forgery during rekeying, requires sender verification, and therefore prevents MITM attacks in group communication.
We hope our secure multicast group communication scheme can be applied to cloud services and social networking sites, so that users can enjoy these services in a secure environment without further loads. And users’ privacy and data integrity can also be secured.
Notations
| : | A large prime number |
| : | A cyclic additive group of prime order and generator |
| : | A cyclic multiplicative group of prime order |
| : | Generator, |
| : | A bilinear map , |
| : | One-way hash function |
| : | Random values, |
| : | Identifier of group members, |
| : | A set of bit-assignments ; : the th bit of ID is 1; : the th bit of ID is 0. |
| : | A set of bit-assignments secrets ; , ; maps |
| : | Public parameter |
| : | Group coordinator’s master key |
| : | Private keys that a group coordinator multicasts to members of specific ID, |
| : | Session key |
| : | An attribute that a group coordinator gives to a member of a specific ID (each attribute is the bit-assignment of the ID). |
Competing Interests
The authors declare that they have no competing interests.
Acknowledgments
This research was supported by the National Science Council of Taiwan under Grant no. MOST104-2221-E-130-009.