Analysis and Improvement of Key Distribution Scheme for Secure Group Communication

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.


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][2][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 log  keys and each member can join  − 1 subgroups.To have higher flexibility of data encryption, Attribute-Based Encryption (ABE) [6][7][8][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 (log ), 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 keyupdate 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.

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.With the attributes, the coordinator runs the encryption algorithm ENC(Params, MK,   , ) in detailed steps as follows: After group members receive the encrypted messages, they use their private key and the public parameter to run the decryption algorithm, DEC(Params, SK, CT   ): (1) The group member verifies whether CT   's   matches his own attribute  ID .If the two match, the member proceeds to the next step.If they do not match, the decryption algorithm ends.

Key-Update Stage.
When a new member joins a group, the group coordinator generates a new group key SEK  and uses the previous group key SEK to encrypt SEK  to the new member.Then, he sends ID,  ID , SK ID , and SEK 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   ∈  *  .
After receiving the ciphertext, the group members run the following steps: (1) Performing the decryption algorithm DEC(Params, SK, CT   ) and retrieving KU = .

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.
(3) He multiplies   by  3 and the result is Therefore, the malicious member can bypass the encryption algorithm ENC and sends a forged ciphertext CT    without the group coordinator's master key MK.After receiving CT    , the members run the decryption algorithm DEC.Detailed steps are as follows: (1) Calculating  = ∏  ID ∈      =   ∑  ID ∈     =  Sum   .
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.

Full Modification of Group Coordinator's Ciphertext.
A malicious member may modify the whole ciphertext, except   , in the following steps: (1) Calculating  1  = ( 1S  , ) = (  S  Sum   , After receiving CT    , the group members run the decryption algorithm DEC(Params, SK, CT   ): (1) The group members verify whether the received   matches their own  ID .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  = ∏  ID ∈S      =  ∑  ID ∈S     =  Sum S  .
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.  maps   .That is,   0 maps  0 ,   0 maps  0 , and so on.Further, a group coordinator generates his master key MK = {, ,   ,   , (, )  ,   ,   } and the public parameter Params = { 0 , , ,  pub ,  1 ,  2 }, where  pub =   .

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  ID .Then, the group coordinator runs KeyGen(MK,  ID ) to generate a key: (5) He generates a private key SK ID = { =  (+)/ , ∀  ∈  ID :   =     }.
At last, the group coordinator multicasts ID,  ID , SK ID , and current session key SEK to the new member through a secure channel.After receiving the ciphertext, group members verify whether their own  ID matches   's bitassignment.If verified, they run the decryption algorithm DEC(Params, SK, CT   ).Besides, during decryption, they have to check if the sender of  is their group coordinator.

Encryption and Decryption
Steps are as follows: (1) Conversion of the   -associated   into   .

Key-Update Stage.
If a new member joins a group, the group coordinator generates a new session key SEK  and uses the previous session key SEK to encrypt it to his group members.Also, through a secure channel, the coordinator multicasts ID, AID, SK ID , and SEK 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   ∈  *  .
Group members perform the following: (1) After receiving the ciphertext, each group member runs DEC(Params, SK, CT   ) and retrieves  = KU.

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, {Params, MK, SEK}.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 keyupdating 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 ( = 5000); each user is a group coordinator; each user is also a member of his friends' groups.Thus, each user has a master key, ( + 1) public parameters, and ( + 1) 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  0  ,  1  , and  2  (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.

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.

𝑞:
Alargeprimen umber  0 : A cyclic additive group of prime order  and generator   1 : Acyclicmultiplicativegroupofprime order  : Generator,  ∈  0 : A bilinear map ,  0 ×  0 →  1 : One-way hash function , , : Random values, , ,  ∈  *  ID: Identifier of group members, ID =    −1 ⋅ ⋅ ⋅  0   : A set of bit-assignments   = { 0 ,  0 ,  Session key  ID : An attribute that a group coordinator gives to a member of a specific ID (each attribute is the bit-assignment of the ID).

( 3 )
He generates a rekeying message KU =  (  −)/ .(4) He uses the Quine-McCluskey algorithm to minimize remaining members' IDs until there are  irreducible IDs and these IDs are taken as attributes   , 1 ≤  ≤ .

Table 1 :
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 CT   , the malicious member retrieves   ,  0  ,  1  , and  2  and calculates  1 ,  2 , and  3 .He tries to forge a message   0  =   ⋅  3 and sends the fake ciphertext CT    = {  ,   0  ,  1  ,  2  } to other members.Following the decryption algorithm, the members decrypt the fake ciphertext CT    and retrieve   .According to the 7th step of decryption, they calculate ℎ =  2 (  ).At the 8th step, they calculate (ℎ,  pub ) = (ℎ,   ), which does not match ( 2  , ), 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.CT   is the previous ciphertext from the group coordinator:CT   : {  ,  0S  =  (ℎ, ) Sum S  ,  1S  = ℎ Sum S  ,  2S  = ℎ  } ,  = KU =  (  +)/ .With CT   and , the group members have updated their private keys  =  (  +)/ .The malicious member forges a rekeying message   .Since he has had  2 , he uses it to calculate  2 (  ) and tries to generate   0  =   ( 2 (  ), )   Sum   .He has to use CT   to run the following steps:(1) Summing up the previous attributes   ; thus,  = ∏  ID ∈     =   ∑  ID ∈    =  Sum   .=( 2 (), )   Sum   .Sum   , it does not match ( 2 (  ), )   Sum   .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 KU to the remaining members.After receiving KU, the members update their private keys SK ⋅   = SK ⋅  ⋅ KU Comparison of computational load.

Table 2 :
Storage.and calculate a new session key SEK  =  2 (KU).Because the removed member does not have KU, 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 SEK  and uses the previous session key SEK to encrypt SEK  to his group members.Then, he sends SEK  to the new member through a secure channel.In doing so, the new member is unable to access previous messages.