A Privacy-Preserving Framework With Self-Governance and Permission Delegation in Online Social Networks

With the wide use of online social networks (OSNs), the problem of data privacy has attracted a lot of attention from not only the research community but also the general public. To meet the privacy needs of OSNs, we present a new framework for protecting information published through online social network websites through encryption by taking into account special features of OSNs. In this framework, autonomous private communities, called as zones, are set up by one or a set of mutually-trusted users collaboratively without any third party intervention. Sensitive information (i.e., posts, photos, etc.) within a zone can only be accessed by authorized members of the zone. A user joins a zone by obtaining a permission from an authorized zone member and uses it along with her private key to access contents inside the zone. One striking feature about our design of permission is that it is not secret information and thus can be left in the user’s account in the OSN. Compared with prior work, this design of public permission greatly reduces user-side overhead on secret key management as a user only needs to maintain one secret key and use as many public permissions as she wants to access contents in different zones. Furthermore, our framework allows efficient access permission delegation and revocation. We develop a prototype to evaluate its computation performance in an acceptable level. Meanwhile, we prove that our construction is semantically secure against chosen plaintext attack, existential forgery attack and key forgery attack.

INDEX TERMS Security, social network, privacy protection, self-governance, key management.
Online social networks (OSNs) such as Facebook, LinkedIn, and Twitter are becoming increasingly popular and accessing these sites has become part of the daily routine of millions of users. These sites provide various tools and services that allow people to share content (such as contact information, personal tastes, photos, or viewpoints) and build communities that reflect their private and/or professional relationships in the real world [1], [2]. For example, people keep contact with friends and even make new friends through Facebook (http://www.facebook.com) or MySpace (http://www.myspace.com), build professional network and The associate editor coordinating the review of this manuscript and approving it for publication was Zhaojun (Steven) Li . find job information from LinkedIn (http://www.linkedin. com), and so on.
As social network providers hold vast repositories of personal information, it raises great concern about potential user privacy violation. Although social network sites offer privacy controls that allow users to restrict whom their data can be viewed, they offer insufficient controls (both technically and legally) to restrict their own sharing of data with corporate affiliates or application developers [3]. User privacy still can be compromised in many possible ways such as users' poorly understanding of defaults or carelessness [4], accidental data release, intentional use of private data for marketing purposes [5], court order [6], and so on. Currently, OSN users have no control over their posted data. Also, it is unreasonable to expect OSN sites to provide any legal privacy protection for their users at time being [3].
The need for a mechanism to allow OSN users themselves to enforce access control of user-generated content has been identified by the research community [4], [7], [8]. Various techniques have been proposed to provide privacy protection against untrusted OSN providers. To avoid access by the OSN provider, Lockr [9] lets a user control its shared data by replacing the data with a link and storing the actual data at a third-party server. This approach shifts the requirement for trust on the OSN provider to the requirement of trust for the third-party sever. The work of [10] uses the concept of virtual private networks to build virtual OSNs which allow users to replace sensitive data with some pseudo information and store the real data on friends' machines. Since private data is stored in either a third-party server or friends' machines beyond the domain of the OSN, the OSN may not be able to access these data. However, in these schemes, users do not really have access control over their already posted data.
To protect user information and let users control the way how they want to share their data, one feasible solution would be for the user to encrypt the data she wants to share through the OSN platform, and give out the decryption keys only to authorized users. Unauthorized users, including the OSN providers, are not be able to decrypt since they do not have the decryption keys. This general idea actually have been widely adopted by many recent works [11]- [14]. However, existing solutions usually introduce a heavy overhead on OSN users for key distribution and management in order to meet some special needs required by the OSN setting, and thus do not scale well.
Some unique features of OSNs which require special handling in the design of an encryption-based access control scheme for the OSN setting include: • Dual User Roles. An OSN user plays two roles as both a content publisher and subscriber in the OSN setting. An OSN user usually would like to share data with her friends -which is the primary reason why she joins the OSN. Reciprocally, her friends also would like to share their data with her. When a user publishes a content through the OSN platform for sharing, she acts as a publisher. When a user retrieves data shared by her friends in the OSN, she becomes a subscriber of her friends.
• Unknown Recipients. OSN users are not in charge of OSN memberships. A publisher may not know the set of recipients, or the subscribers of her content, with whom her data will be shared beforehand. For example, Alice may post a message, in the encrypted form, on her friend Bob's wall. Alice's message could be accessed by Bob's friends if Bob allows his friends to see his wall. It is not possible or necessary for Alice to know the list of Bob's friends. Moreover, the number of subscribers a publisher may have might be a lot.
• Efficient Subscriber-side Key Management. A popular OSN user may have a lot of friends and thus needs to retrieve contents, as a subscriber, from many of her friends who publish and share data with her. That is, the number of publishers one may subscribe might be a lot. This requires efficient subscriber-side key management.
• Multiple Private Groups. The OSN platform usually provides a diversity of services including third-party applications such as Inbox, Wall, Blogs, Photos, the ''like'' page, etc., for users to share different contents. A user may want to share various contents with different sets of friends through different OSN services or applications.
To fit well into the OSN setting, an access control scheme should take into account the above special features of the OSN setting. Unfortunately, existing solutions often ignore one or more these special features. Moreover, they usually focus on designing access control schemes from the view point of the publisher and trying to minimize the overhead on the publisher side. They often ignore the fact that an OSN is also a subscriber who may subscribe to many publishers. Thus, they inherently incur a heavy computation overhead on the subscriber side.
Schemes based on traditional cryptographic techniques such as symmetric or public encryption have limitations when dealing with multiple groups in OSNs since a publisher either needs to prepare multiple copies of encrypted data for each user in the group, or needs to know the identities of everyone to whom they give access [15]- [17]. To allow flexible access control of data sharing in multiple groups and minimize the computation overhead on the publisher side, many types of multi-party access control schemes [18]- [22] have been proposed in recent years. Pang and Zhang [21] define a new OSN model based on user-to-user relationship and public information, and introduce a variant of hybrid logic for formulating access control policies. Hu and Ahn [22] propose a multi-party authorization framework with authorized policy evaluation mechanism to enable collaborative management of shared data in OSNs. Schemes [23]- [28] based on attributebased encryption (ABE) also have been posed in the OSN setting to provide the flexibility in controlling data sharing in multiple groups. Zhang proposes a privacy protection scheme [25] based on classified attribute encryption (PPSSN) to classify data owners and control access privilege with the mechanism of different close relationships accessing data with different degrees of accuracy. Luo [23] presents a hierarchical multi-authority and friend discovery scheme based on ciphertext-policy ABE (CP-ABE), which employs attribute subsets to achieve flexible fine-grained access control.
Although the use of ABE reduces the overhead of key management on the publisher side immediately when dealing with data sharing among multiple groups, it does no help on the subscriber-side key management. A subscriber essentially needs to maintain one (set of) decryption key for each publisher who shares data with her. A popular user may have hundreds or even thousands of OSN friends. Storing and managing hundreds or thousands of secret keys locally is by no means an easy job to end users. Especially, considering that more and more users will access the OSN sites through their smartphones -given the increasing popularity of smartphones, storing and managing secret information on the smartphone platform not only poses more challenges but also may bring additional security risks due to factors such as: a smartphone may easily get lost or stolen; users tend to upgrade their smartphones to the latest model more frequently than to upgrade their desktop/laptop computers; the content of a smartphone is usually synchronized with that stored in the remote server provided by its service provider.
To achieve privacy preservation and secure communication in OSNs, some key management schemes have been proposed [29]- [34] in recent works. Muhammad and Mizanur [29] present a new and efficient centralized key management protocol to prevent Sybil attack and provide a secure communication service among users in OSNs. The core idea of this method is the existence of a 'roadblock' that any user intending to join a group must go through. Li and Wu [30] propose a secure chaotic maps-based group key agreement scheme to enhance the trustworthiness of the OSN systems. Jung and Nam [31] suggest an efficient key management scheme using Dynamic Identity-Based Broadcast Encryption (DIBBE), which realizes secure communication among users in decentralized social network. Yeh and Huang [32] introduce a security key agreement framework for simultaneous authenticating multiple users to improve the efficiency and security of peer-to-peer (P2P)-based OSNs.
We believe that a practical and effective access control and key management scheme in the OSN setting should provide the following properties: Autonomy The security of a private OSN should be enforced by OSN users themselves without interventions from OSN providers or any other third parties. Efficiency There should be minimum overhead for both publisher-and subscriber-side key management. The less secret information one has to store and maintain, the better. Scalability There should be no restriction on the number of private groups that may form on the OSN, the number of users in a private group, and the number of groups one may subscribe to.

OUR CONTRIBUTIONS
To meet the privacy needs of OSN, we present AutoZone, a framework for protecting information published through OSN websites through encryption by taking into account the dual roles OSN users have and the special features of OSN communication. In AutoZone, autonomous private communities, called as autozones or simply zones, are set up by one or a set of mutually-trusted users collaboratively without any third party intervention. Sensitive information (i.e., posts, photos, etc.) within a zone can only be accessed by authorized members of the zone. A user joins a zone by obtaining a permission from an authorized zone member and uses the permission along with her secret key to decrypt content shared by other zone members. A permission is both user-and zone-dependent. Only the one who owns the permission can use it to decrypt contents in a specific zone. One user's permission is useless to the others. So a striking feature about our permission is that it is no longer secret information and thus can be stored remotely, for example, in the OSN, other than in the local storage on the user side. This novel design greatly reduces the overhead on secret key management on the subscriber side. In AutoZone, a user only needs to maintain one secret key. However, she can have as many public permissions as she can to access contents in different private zones. Moreover, AutoZone supports efficient permission delegation and provides a way to revoke the permissions of authorized members permanently or temporarily. We summarize the key contributions of our work in this paper as follows.
• We present AutoZone, a system architecture for a private OSN. In this architecture, zone creators can collaborate to manage and maintain the privacy of contents inside the zone. There is no need for a centralized management server to help on key distribution and management and to monitor the behavior of all users.
• We propose an efficient access control scheme on top of the AutoZone architecture. We achieve minimum overhead on key management for subscribers through the design of public permissions. Our design also allows efficient access permission delegation and revocation.
• To prove the feasibility of our architecture, a prototype of AutoZone is implemented. Experimental results show that our construction can achieve the identified design goals for protecting privacy in OSN with acceptable performance. We also prove that our AutoZone scheme is semantically secure against chosen plaintext attack, existential forgery attack and key forgery attack.

ORGANIZATION
The rest of this paper is organized as follows. We introduce the basic concepts and the architecture of AutoZone in Section I. We articulate the key management scheme of AutoZone in Section II. We present the constructions of AutoZone functional modules in Section III. We analyze the security of AutoZone in Section IV. We report a prototype implementation of AutoZone and its performance evaluation in Section V. Finally, we concludes the paper in Section VI.

I. OVERVIEW OF AutoZone ARCHITECTURE
In this section, we introduce AutoZone, a private OSN architecture which allows secure sharing of data among community members via group key management and message encryption. We start with basic concepts in the AutoZone architecture.

A. AUTONOMOUS ZONES
In our private OSN setting, a zone refers to an exclusive community where contents (i.e., posts, photos, etc.) published inside the zone are restricted to be accessed only by authorized zone members. By autonomous, we mean the security of the zone is governed exclusively by zone members without any intervention from the OSN provider or any other third party. By joining a zone, one gains the right to access contents posted by other members in this zone. The zone is an abstract concept which can support a variety of OSN applications/services: A message inbox which allows an owner to send a message to a group of her friends simultaneously. The owner usually only needs to prepare one copy of the message and send the message once. A blog which is a discussion or information site published on the World Wide Web consisting of discrete entries (''posts'') by the blog owner, usually a single individual. More recently ''multi-author blogs'' (MABs) have developed with posts written by large numbers of authors and professionally edited. Some sites, e.g., Twitter, allow bloggers to share thoughts and feelings instantaneously with friends and family. A usenet network or newsgroup which many users can join. This is essentially equivalent to control of a blog for the administrators (called dealers). A message whiteboard or bulletin board which allows the posting of messages. For example, the Facebook Wall is a peruser forum that features posts and comments from the user and her friends; the Facebook Photos application stores comments and tags for each picture and displays them to friends; and the Flickr photo management and sharing application allows each photograph has a page where members of the Flickr community can comment on photographs.
There is no restriction on the number of zones on can create, the number of applications/services a zone can support, and the number of zones one can join. A user (or a set of mutually trusted users) can set up different zones to meet different needs of data sharing. In the simplest case, a zone is set up to support data sharing of all content types among all friends. For example, in Alice's Facebook Account, Alice shares her posts, photos, videos, games, and so on with all her friends through various OSN services. A user can also set up a zone to specially support one single OSN service. For example, in Alice's Blog, Alice shares only her posts with her friends. Zones can also be set up for users to share different contents with different subsets of friends. For example, Alice can setup a zone to share photos taken in a group trip with a subset of her friends who were also in that trip.

B. AutoZone MEMBERSHIPS
For a specific zone, OSN users can be classified into four categories with different sets of privileges:

Kernel member (KM) A KM is an authorized zone member
who is the owner or creator of the zone. A zone can be created by one or several mutually trusted OSN users collaboratively. So a zone can have one or multiple KMs. A KM has the rights to publish, delete, access or update contents released by other members of the zone.

Full authorized member (FAM) A FAM is an authorized
zone member who has full rights to publish and access resources in the zone, but do not have permissions to delete or update contents. Authorized member (AM) An AM is an authorized zone member who can access resources in the zone with her access permission, but cannot publish any content. Unauthorized user (UU) A UU is not an authorized zone member and does not have any permission to access resources published in the zone.
Apparently, among the three authorized zone memberships, KM is the most privileged while AM is the least privileged. AutoZone supports privilege delegation which allows a more privileged member to transfer her privilege to another user through a process called permission delegation. For security purpose, permission delegation should satisfy monotonicity. That is, access privileges are spread only from highprivileged members to low-privileged members. We provide an example in Figure 1 to describe the privilege propagation model used in AutoZone, as well as the relationships among four types of users.
A KM is able to assign her good friends as FAMs (e.g., Node 3 → Node 6 and 7), and assign her common friends as AMs (e.g., Node 3 → Node 18). Similarly, a FAM is also able to transfer her privilege (FAM) to her good friends (e.g., Node 6 → Node 5), and to assign her common friends as AMs (e.g., Node 7 → Node 20 and 23). Moreover, an AM is able to transfer her privilege (AM) to her (good/common) friends (e.g., Node 18 → Node 19).
The scale of privilege propagation should not be limited by the total number of users in the zone. Specifically, we have no restriction on the total number of FAMs and AMs in the same zone. However, the number of KMs in a zone usually should be limited due to the actual management complexity requirements. A user can have different memberships in different zones. Different memberships (KM, FAM, or AM) of a user in different zones are unrelated with each other.
We also note, it is technically possible using the ''delete'' and ''update'' operations to compromise the security of a  zone. Hence, it is necessary to restrict maintenance operations of the zone only to KMs. So, it is critical to have an efficient authentication scheme to distinguish KMs from the others.

C. TYPES OF KEYS
In AutoZone, there are three types of keys used by authorized members of the zone.
• User private key sk. Every user in the OSN has a private key which is a user-specific secret. This key is generated and kept confidential by the user herself. The user registers the corresponding public key pk to the OSN.
• Zone Key gk. A zone key is a zone-wide secret. It is generated collaboratively by the zone KMs and built on the secrets of these KMs. The zone key is only given to KMs and FAMs.
• Permission key pm. Although we use the term ''key'', a permission key is not a secret. However, it is userand zone-specific. It is generated from the zone key of a specific zone and the user's public key registered with the OSN. Only the owner of the permission can use it along with her private key to decrypt contents in that specific zone. A permission key usually only allows one to decrypt content published by other zone members. To have the right to encrypt (or to publish), one needs the zone key. So for a specific zone, a FAM has both a zone key and a permission key while a normal AM only has a permission key. A KM does not need any permission to access contents in the zone. So a KM only has a zone key besides her own private key. We illustrate the ownerships of different keys among members in Figure 2 and Table 1. Figure 2 shows two zones: Zone 1 and Zone 2, as well as 11 users (indexed from 0 to 10, i.e., u i ). Each user u i has a private key sk i . In addition, each user u i has a zone key, or a permission, or both a zone key and a permission for each zone she belongs to depending on the membership type she has with that zone. In the example shown in Figure 2, u 0 and u 2 are two KMs in Zone 1 and Zone 2, respectively. They hold the zone-key gk 1 and gk 2 , respectively. As a KM, they do not need permission to access the zone, at the same time, their private keys, sk 0 and sk 2 , can guarantee that they pass the verification process for KMs. As a KM in Zone 1 and an AM in Zone 2, u 1 has a zone-key gk 1 and a permission pm 2(1) , where the subscript 2 and (1) of pm 2(1) denotes the zone ID and the user ID, respectively. gk 1 and pm 2(1) are independent to each other. As FAMs in both communities, u 3 has two key-pairs (gk 1 , pm 1(3) ) for Zone 1 and (gk 2 , pm 2(3) ) for Zone 2. Similarly, u 4 and u 5 have a keypair of zone-key and permission from Zone 1, respectively. Note their permissions, pm 1(4) and pm 1(5) , are different, and these permissions become valid only if they work together with the corresponding secret keys sk 4 and sk 5 , respectively. The assignments of keys for other users are given in Table 1. Since u 10 does not belong to any zone, she only has her private key.

D. OUR MODEL AND ARCHITECTURE
Our private OSN model could be built on existing social network platforms, such as Facebook, Orkut, etc, which usually allow developers to create ''applications'' to extend the types of information that can be stored, manipulated, and shared using social network interfaces. Fig. 3 depicts an OSN architecture based on existing Facebook. In this model, messages posted by end users are stored in database.
Client-side encryption is used to prevent unauthorized access of contents in a zone. As a middleware model, OSN platform is responsible for the interaction between end users and application providers. End users, consisting of KM, AM, FAM and UU, can easily establish contact with application providers by means of a URL on OSN platform. The platform firstly interprets the input data and related requests (HTTP Query) from the end users, then the interpreted input data and requests are transmitted to the application server through the network, the address of which is registered by the application developer on the platform in advance. Next, the application server performs the user input requests interpreted by the platform, perhaps containing operations on the database. The application server then provides the OSN platform with an output page containing of HTML and platform-specific markup (FBML), including scripts. After that, the OSN platform firstly interprets the output page, that is, converts platform-specific markup (FBML) into standard HTML and JavaScript. The interpreted user-recognizable output page (as HTML) is then handed over to the end users. In the above process, it is essential for client-side privacy to design a cryptographic module on ActiveX/JavaScript that is embedded into client's browser for decryption of output page. In this architecture, the content publisher enforces access control through encryption and key management provided by AutoZone at client side. Based on the above-mentioned dataflow, AutoZone adopts five cryptographic function modules: UserRegister, BuildZone, DelegatePermission, Pub-lishContent, and AccessContent, to control publishing and accessing contents in a zone as illustrated in Fig. 4.
• Each OSN user chooses a favorite label, generates her public/private key pair, and then use UserRegister module to register her label and public key on OSN platform.
• When a user or a set of mutually-trusted friends want to share data with others, an autonomous zone is setup through the BuildZone procedure. The creators (or KMs) get a zone key, which can be used to access, manage and maintain contents in this zone.
• When a user wishes to access a zone, her friends who has already been an authorized member of that zone, can delegate an access permission key (APK) to her by using the DelegatePermission module.
• When an authorized zone member wants to publish a content in the zone, she picks the zone key, invokes Publish-Content algorithm to encrypt the content, and then transmit the encrypted data to the storage server; and • Anytime a zone member can obtain the encrypted data from the sever and use the AccessContent module to retrieve the original data by using her private key and permission key.

II. AutoZone KEY MANAGEMENT
In this section, we articulate a concrete design for access control and key management based on the function modules in the AutoZone architecture. In our design, we intend to answer the following questions: How will a KM or several KMs define a zone and generate the zone key? How will authorized members delegate access privileges to others? How to encrypt a content for publishing and how to decrypt a content using permissions? And how does an untrusted third party (e.g. the OSN platform) can authenticate the KMs of the zone?
The UserRegister module is used for users to generate a private/public key pair without the intervention of the OSN. The security of AutoZone mainly relies on three modules, BuildZone, DelegatePermission and Revocation, to build a  zone and grant/revoke access permissions without the help of OSN. The two modules, PublishContent and AccessContent, are used for publishing and accessing contents. Each module may employ one or more algorithms. In addition, a zone maintains a community member list (CML). Kernel members may update the CML to revoke certain members by the revocation algorithm. Notations used in the rest of paper are summarized in Table 2.

A. USER REGISTER
The system manager firstly generates the system parameter param by invoking param ← Setup(κ), then makes it VOLUME 8, 2020 public. Based on param, each user u i of the OSN chooses a unique ID id i , generate its private sk i by invoking sk i ← KeyGen(param). Then, the user registers herself with the OSN by sending pk i ← Register(id i , sk i ) to the OSN. Here, the Setup(κ) algorithm only needs to be invoked once and any knowledge of the user's private key can't be learnt by the system manager on registration.

B. BUILD ZONE
This module allows a set of mutually trusted users to collaboratively build a zone, and the OSN platform provides users with Web services of the zone (similar to the existing group service). Once the zone is built, these initial users are considered as kernel members (KMs) of the zone. Each KM will make a contributory share and generate a convergence information based on the contributory shares of all KMs in the zone. Furthormore, each of KMs should verify the correctness of the generated convergence information. Finally, the OSN platform builds a zone key from the confirmed convergence information.
Specifically, for a set of KMs S = {u 1 , · · · , u m } in the zone, anyone in S, can build a zone key with the help of the OSN platform (this KM is called the initiator, the others are called the responsor). The Fig. 5 shows the workflow of zone key generation and distribution, and the detailed process is described as follows: Step 1. The initiator sends the request for the contributory shares to the OSN platform, then the OSN platform transmits the request to each KM u i in S. As a reply, each KM u i responds to the initiator with her contributory share c i via the OSN platform.
Step 2. The initiator uses Web script of the zone to generate a set of contributory shares = {c 1 , · · · , c m }, and then produces a convergence information * ← Converge(S, ) based on . Once this is done, the pair ( * , ) should be published to the Web page of the zone so that the responsors in the zone can obtain the result.
Step 3. After her contributory share c i is confirmed in , each responsor u i will generate her convergence information i in the same way as the initiator, and then verifies whether the value i is equal to the published * . If i = * , then the responsor votes 'Yes' to the zone page; Otherwise, it votes 'No'.
Step 4. The OSN platform collects and counts the votes, then checks whether the number of the approved responsors is up to 2/3 of the total votes. If it passes, the OSN platform generates the zone key gk by using the algorithm CKeyGen( * ) and publishes the zone key gk to the zone page; Otherwise, it reports the error to the page.
It is easy to see that the distribution process of zone key depends on the OSN platform as a result that the users do not need additional communication besides the OSN. So, malicious OSN platforms can interrupt the key distribution process, but the users need not to worry about their malicious behaviors since the mainstream OSNs are usually considered as honest-but-curious.

C. DELEGATE PERMISSION
Permission delegation refers to the concept that allows the permissions of a zone members to be transferred to her friends. By invoking Permission(sk i , pm j(i) , gk j , id k ), user u i , be a KM or FAM, can delegate the ''read'' right of a zone to an external user u k (who becomes an authorized member after getting the permission). In our scheme, only KMs and FAMs are required to have the right to perform permission delegation by using this algorithm for the sake of avoiding an unlimited delegation. If an external user wishes to get ''write'' permission of a zone, the user u i in KM or FAM only needs to gives the zone key and the permission pm j(i) to her.
Permission generation can be implemented by the script of zone page in the client (its computational complexity is (m 2 +m−1)[E] for m KMs, which is introduced in Section V-B). The permission shall be stored at client-side in the form of key-value pair, the storage location of which might be cookie, registry, simple key-value database (such as Mon-goDB), JSON format files, etc. Considering the decryption process depends on both the permission and the user's private key, any malicious attacker can not decrypt the ciphertext if he does not have the user's private key but has the permission. Therefore, the permission need not to be stored in the encrypted form, but the security mechanism should be considered to protect the user's private key.
A key-value pair is usually denoted as key : value. The unique zone name can be generally taken as the key, and the value is used to store the permission (for our scheme in Section V-C, each permission is only one element under the group G, and the size is approximately 3K bits). These keyvalue pairs will form a large array when a user joins too many zones. Fast retrieval technologies, such as Hash lookup table, can be applied to speed up the permission search.

D. PUBLISH CONTENT
The PublishContent is a process through which a KM or a FAM publishes a content to the zone. A member must hold a valid zone key gk j to execute this process. Thus, AMs are not allowed to publish contents in the zone.
To prevent unauthorized publishing, an authentication protocol FAthenticate (A, B) is introduced to validate the identity of members. This protocol can avoid unauthorized users from uploading illegal ciphertexts to the zone. Once the authentication process is successful, the user is allowed to encrypt the content and then upload it to the content service provider (CSP) for sharing. Using PublishContent(u i , M ), a user u i in KM or FAM publishes a content M to the zone as follows: first of all, the member u i performs FAuthenticate protocol to verify whether she is authorized through interactions with the OSN platform. If u i is an authorized member, that is, she passes the authentication from the protocol FAuthenticate, she is allowed to encrypt the content M and submit the corresponding ciphertext C to the OSN platform. At last, the OSN platform transmits the ciphertext C to CSP.

E. ACCESS CONTENT
The AccessContent module allows a member to access contents in a private OSN. Given an encrypted content C derived from the OSN, any member u i can use execute the algorithm CDecrypt(sk i , pm j(i) , C) to decrypt it by her access permission pm j(i) and private key sk i . This means anyone authorized in a private OSN can retrieve the encrypted content from the CSP. In this module, we provide an efficient mechanism for the integrity check of message. Specifically, we make use of cryptographic Hash function to construct a verification algorithm CVerify(M , C) on the ciphertext C. After the decryption process of ciphertext C is done, the member can utilize the verification algorithm to verify whether the decrypted message M is intact. If the message M is tampered or corrupted, then the process abort; otherwise, the message M is indeed intact for the integrity check, and then the message can be displayed on the Web browser.

F. REVOCATION
The Revocation is a process through which a set R of members in a private OSN are excluded from accessing zone con-tents. The basic steps involved in the revocation is as follows: for a set R of revoked members (who can be determined by their public labels), by using the zone key along with her private key, the users in KM or FAM can invoke the algorithm Revocation(sk i , pm j(i) , gk j , R, M ) to encrypt the message M . This is only a temporary revocation in the sense, a user is only revoked regarding to this specific message. The user still can access other contents. In case of permanent revocation for an authorized member, the KM or FAM needs to add this authorized member into the revoked users list (CML) in the zone, and makes it public. While uploading a content into the zone, she simply sets the CML as the set R to encrypt the content. In the AutoZone scheme, we require that the number of revoked users must be strictly less than a threshold value (see Section III for more details). For improving revocation's capacity, we can easily increase the number of revoked users by increasing the threshold value during the zone key generation, at the sacrifice of increased performance overhead. But this kind of overhead could be compensated by the fast algorithm in Section V-A.

III. ALGORITHMS FOR AutoZone
In this section, we present the concrete constructions of algorithms used by function modules in the AutoZone architecture. Our constructions are built over groups with bilinear maps. Let G and G T be two groups of order q for a large prime q. A bilinear map e : G × G → G T between these two groups must satisfy the following properties: 1) Bilinear: e(g a , h b ) = e(g, h) ab for all g, h ∈ G and a, b ∈ Z q . 2) Nondegenerate: e(g, h) = 1 unless g or h is the generator of G. 3) Computable: there is an efficient algorithm to compute e(g, h) for g, h ∈ G.
We first present some intuition on the security of our constructions for the AutoZone cryptosystem. One challenge in building the AutoZone cryptosystem is how to allow a set of users to build a zone key collaboratively. We make use of Lagrange interpolation polynomial to solve this problem: Let F q be a finite field. Given a set of m points and all x i are unique. Then there is a unique polynomial f (x) ∈ F q [X ] of degree at most m − 1, that passes through all these m points, i.e. f ( In AutoZone, a content is encrypted by a key derived from f (0). As long as one know m points in the curve, one can recover the polynomial and thus the value of f (0). In our design, the zone key provides m − 1 points on the curve. To decrypt, one needs to find another point on the curve. In our design, the private key of a KM is a point on the curve so a KM does not need a permission to access the content. For a FAM or and an AM, the remaining point is provided by her private-key and permission to access the content. In fact, the user's private-key is a random point on any two-dimensional space. The permission is defined as the y-axis distance from this random point to the curve (as shown in Figure 6). With both the private-key and permission, one can find the remaining point on the curve and thus recover f (0). Of course, to ensure security, we will not let anyone to actually recover f (0). However, such information is sufficient for an authorized user to perform decryption and access the content.
From the above description, it is easy to analyze the scalability which AutoZone can provide. For a large key space, e.g., suppose the key size is 320 bits, our scheme can support 2 320 users and unlimited number of zones when using different generators in G to generate zone key. More importantly, the total number of users is unlimited in each zone and the total number of zones that one user can join is unlimited in terms of polynomial interpolation. The number of KMs is at most m − 1 for a given polynomial with degree m − 1. The degree of the polynomial can be adjusted according to actual application needs. For example, the degree should be small (from 10 to 50) for a small zone, e.g., a personal Blog; and it should be large (from 50 to 200) for a large zone. By using the efficient algorithm in V-A to calculate polynomial interpolation, we can ensure the performance of AutoZone when using a polynomial of high degree.
A collection of polynomial-time algorithms (Setup, KeyGen, Converge, CKeyGen, CEncrypt, CDecrypt, CVerify, Permission, Revocation) and two authentication protocols (KAuthenticate, FAuthenticate) are used to realize the function modules in the AutoZone architecture. We divide these algorithms into four categories, described in more detail in supplemental document.

IV. SECURITY ANALYSIS
In this section, we analyze the security of AutoZone against attacks, including chosen plaintext attacks, existential forgery attacks, and key-forgery attacks. Moreover, we provide a complete security analysis of the authentication protocols based on the interactive proof system (IPS). The proofs of theorems are provided in supplemental document.

A. SEMANTIC SECURITY FOR PRIVACY
We define the semantic security of our scheme using the following IND-CPA game. We say that an scheme ε is semantically secure (IND-CPA) if no polynomially bounded adversary A has a non-negligible advantage against the Challenger defined in the following IND-CPA game: Setup The manager takes a security parameter κ to run the Setup algorithm, publish the system parameter param. The challenger and the adversary run Register algorithm respectively to get their private key sk c , sk a , then the challenger chooses a set of users, where the adversary is not included, runs the CKeyGen algorithm to generate the zone key gk and gives it to the adversary A. Phase 1 The adversary A issues encryption queries X 1 , . . . , X m to challenger. For each query X i , the challenger responds by running algorithm C i = CEncrypt(X i ) to generate the ciphertexts and sends C i to A. Challenge Once the adversary decides that Phase 1 is over, it outputs two equal length message M 0 , M 1 on which it wished to be challenged. The only constraint is that M 0 , M 1 don't appear in queries in Phase 1. The challenger picks a random bit t ∈ {0, 1} and sets C = CEncrypt(M t ). It sends C as the challenge to A. Phase 2 A issues more queries X m+1 , . . . , X n . The only constraint is that X i = M 0 ∧X i = M 1 . The challenger responds as in Phase 1. Guess A outputs its guess t ∈ {0, 1} and wins if t = t .
We refer to such an adversary A as an IND-CPA attacker. We define an adversary A's IND-CPA advantage in attacking our scheme ε as The presented scheme has the IND-CPA Security under the Decisional Bilinear Diffie-Hellman (BDH) assumption: Let a, b, c, z ∈ Z n be chosen at random and g be a generator of G, the decisional BDH Assumption is that no probabilistic polynomial-time algorithm A can distinguish the tuple (g a , g b , g c , e(g, g) abc ) from the tuple (g a , g b , g c , e(g, g) z ) with more than a negligible advantage, that is, Theorem 1: The proposed scheme is semantically secure against chosen plaintext attacks (IND-CPA) assuming the BDDH Assumption holds.

B. SECURITY AGAINST FORGERY ATTACKS
In the proposed scheme, an AM has only the read right and cannot publish a content into the zone, that is, she cannot forge a valid ciphertext to pass the member authentication process. We restrict that the forged ciphertext using the same random r as the one used in existing ciphertext. We prove the anti-forgery property by means of the following game Exp euf between the challenger and adversary: init The system manager takes a security parameter κ to run the Setup algorithm, publish the system parameter pm. The challenger and the adversary run Register algorithm respectively to get their private key sk c , id c ; sk a , id a .

Setup
The challenger generate a zone key gk, runs Permission(gk, id a , pm) to generate the access permission of A and give it to the adversary. Learning At any time A may issue queries to challenger. B responds to each query X i as follows: 1. if the query is a hash query for the random oracle H i , compute the hash value and sends it to A. 2. if the query is a encryption query for the challenger, B generates the ciphertext C i . Forge Once the adversary decides the above phase is over, it outputs a forged ciphertext C on which it wished to be challenged. The only constraint is that C don't appear in ciphertexts it received in above phase. If C is a valid ciphertext, which means it the encryption of some file F and can be correctly decrypted by the challenger, then the adversary win the game. The challenger outputs 1 if C is a valid forgery ciphertxet, output 0 otherwise. We define adversary A's advantage in forging ciphertext against scheme ε as Adv where the probability is taken over the random bits used by the challenger and the adversary.
The ciphertext of proposed scheme is secure under the hard assumption of computational Diffie-Hellman problem: Let G be a cyclic group of order p. Given g, g a , g b ∈ G, output g ab ∈ G. We say that algorithm A has advantage in solving CDH in G if Pr[A(g, g a , g b ) = g ab ] ≥ ε where the probability is over the random choice of generator g ∈ G, the random choice of a, b ∈ Z * p , and the random bits of A. Theorem 2: The proposed scheme is secure under Type-1 of forging ciphertext attacks for authorized members assuming the difficulty of Computational Diffie-Hellman (CDH) problem in G. In the attack, the forged ciphertext using the same random r as the one in original ciphertext.
One of related problems to forgery ciphertext is the security of the gk zone key against collusion attack. In our scheme, the zone key is generated collaboratively by KMs, and keeps public to KMs and FAMs. So, any malicious attacker can obtain the zone key as long as he colludes with one or more traitors of KMs or FAMs. However, the AMs don't know the zone key, so she has no right to publish a content. Thus, we only analyze the case that some of AMs participate in collusion.
According to the Permission algorithm, the permission is defined as pm = g f (x ) /g y , where (x , g y ) is the public key and g f (x ) = g s · m−1 i=1 (g a i ) x i . For more than m traitors of AMs with their own private keys and permissions, they can employ the Lagrange interpolation method to obtain the exponential coefficients {g s = g a 0 , g a 1 , · · · , g a m−1 } of g f (x) over {(x 1 , g f (x 1 ) ), · · · , (x m , g f (x m ) )}, which builds an unique exponential polynomial g f (x) = g s · m−1 i=1 (g a i ) x i . In the original scheme, these exponential coefficients (called the convergence information ) are derived from Converage algorithm taking the contributory shares = {(x, ), (l 1 , g f (l 1 ) ), · · · , (l m−1 , g f (l m−1 ) )} as input. However, the output of Converage algorithm depends on random choice of the integer l k (1 ≤ k ≤ m − 1). This means that it is impossible for g f (x) to build the zone key gk, if the random choice is unknown. Therefore, the zone key gk in our scheme is secure against collusion attack considering that more than m traitors of AMs can not figure out the zone key by sharing their private keys and permissions. This result is reached from the Theorem 2.

C. SECURITY AGAINST KEY ATTACKS
In our scheme the user's privacy key is the core secret which is used to perform all authorized behaviors. In order to ensure the security of communities, we require the unauthorized members can not forge the kernel member's privacy key in our scheme. To verify this requirement, we prove that an unauthorized user, whose have no right to access messages in a community, can't access resources by forging a kernel member's private key. The following game Exp fk captures this property. Setup The manager takes a security parameter κ to run the Setup algorithm, publish the system parameter pm.
The challenger and the adversary run Register algorithm respectively to get their private key sk c , sh a . Then, the challenger chooses a random set of users, where the adversary is not included, runs the CKeyGen algorithm to generate the zone key gk, and runs Permission to generate the access permission. Finally, the challenger gives the permission µ to the adversary A. Learning During this phase the adversary A makes the queries described below to the challenger. 1. Encryption query: A issues encryption queries X 1 , . . . , X m to challenger. For each query X i , the challenger responds by running algorithm CEncrypt to return the ciphertexts C i to A. 2. Decryption query: A issues decryption queries C 1 , . . . , C m to challenger. For each query C i , the challenger runs algorithm CDecrypt and response with the resulting plaintext F i . Forge Once the adversary decides the above phase is over, it outputs a forged key sk and sends it to the challenger. If the sk satisfies the following two conditions, then it is called a valid forgery: (1) The challenger chooses a random ciphertext C encrypted by sk, it correctly decrypts using sk ; (2) The challenger chooses a random file F, encrypts it by sk , and could correctly decrypts with sk. The challenger outputs 1 if sk is a valid forgery, output 0 otherwise. We define the adversary A's advantage in this attack as Adv The security definition of FAuthenticate (A, B), which includes completeness, soundness and zero-knowledge properties, is similar to that of KAuthenticate (A, B). We have the following theorem.
Theorem 5: The protocol FAuthenticate (A, B) is a secure authenticate protocol in our scheme.

V. PERFORMANCE EVALUATION OF PROTOTYPE A. EFFICIENT CALCULATION OF THE INVERSE OF VANDEMONDE MATRIX
In algorithm Converge, one needs to compute the inverse of Vandermonde matrix V , that is which is directly related to the efficiency of community-key generation and revocation mechanism. In our implementation, we use an efficient algorithm given by Mikkawy [35] to compute the inverse, with a time complexity of O(n 3 ). This algorithm is able to improve the efficiency of Converge for a high-degree polynomial (with a larger threshold value). Given Vandermonde matrix V , we define elementary symmetric function σ (n) i,j in x 1 , x 2 , · · · , x j−1 , x j+1 , · · · , x n . Let σ (n) 1,j = 1 for 1 ≤ j ≤ n and   for 2 ≤ i ≤ n and 1 ≤ j ≤ n. All of σ (n) i,j construct an n × n-dimension matrix σ n×n . The first column of σ n×n can be calculated by calling the Algorithm 3.
The elements in the remaining n − 1 columns of σ n×n can be obtained by using i.e., replacing x 1 by x k in the above algorithm to obtain the kth column σ .

B. COMPUTATIONAL COMPLEXITY ANALYSIS
We analyze the computational complexity of major algorithms in terms of basic cryptographic operations. We denote the cost of one exponentiation operation in group G (or G T ) as [E], i.e., the time of computing g x where x ∈ Z * q , g ∈ G or g ∈ G T . We simply omit the algebraic calculation in Z q and multiplication operations as they are very efficient. The cost of calculating bilinear map e(·, ·) is the most expensive one and we denote it as [B]. Let the number of kernel members is m and the number of revoked users in revocation is t. The cost of major algorithms in AutoZone is listed in Table 3.

C. SPACE COMPLEXITY ANALYSIS
We analyze the space complexity of major entities in our algorithms. Let |G| denote the size of elements in group G. Similarly, the size of elements in group G T and Z + q are denoted as |G T | and Z + q , respectively. The space complexity of five major entities, i.e., , gk, hdr, sk and pm, is showed in Table 4. It is obvious that the storage overheads of three entities, the converenge information , the zone key gk and the header of ciphertext hdr, are linear correlation  with the number of zone's KM members m. For example, the entity gk = g, (l 1 , g f (l 1 ) ), · · · , (l m−1 , g f (l m−1 ) ) consists of m elements in G and m − 1 elements in Z + q , such that their corresponding storage overheads are m |G| and (m − 1) Z + q , respectively. So, the space complexity of gk is m |G| + (m − 1) Z + q . In addition, the other entities, the private key sk and the permission pm, are of a fixed size shown in the Table 4.
In our scheme, we assume that the bilinear map e : G × G → G T is constructed on the curve y 2 = x 3 + x mod p over the field F p for some prime p = 3 mod 4, where G and G T are two multiplicative groups of order q and the integer q is a prime factor of p + 1. Under 128-bit security strength, it is required that the size of F p is 1536 bits, and the size of (uncompressed) elements in G is 3072 bits, i.e., |G| = 3072 bits. When the embedding degree k of the curve is 2, the size of (uncompressed) elements in G T is required for 6144 bits, i.e., |G T | = 6144 bits. Correspondingly, the prime q need only to be 256-bit integer, i.e., |Z + q | = 256 bits. According to the above settings, the storage overheads of five major entities are listed in Table 4 when m is 20. It is easy to see that the storage overheads of sk and pm are of a small and fixed size (32B and 384B, respectively), which are benefical to be stored at client-side. Meanwhile, the storage overheads of the other entities, , gk and hdr, are all less than 17KB. Therefore, our scheme has low storage overheads in practical application.

D. EXPERIMENTAL RESULTS
By developing the experimental AutoZone prototype, we evaluate the performance of the AutoZone scheme from several aspects, including the zone key generation and encryption-decryption operation. We have implemented our basic scheme in C++. The machine we used runs Window Server 2003, has 512M RAM and 3.40 GH Intel Pentium D CPU. The hash function and symmetric cryptosystem we used are standard SHA and AES algorithms. We measure the performance of the AutoZone scheme based on this implementation. We set up our cryptosystem using bilinear pairings based on elliptic curve. In our scheme, the security parameter κ is 80-bits. we need the elliptic curve domain parameters over F q with |q| = 160-bits.

1) ZONE KEY GENERATION
Firstly, we focus on the computation cost for the CKeyGen algorithm. Fig. 8 shows the relationship between computation time and the length of zone key, where the the length of zone key is decided by the number of kernel members (and the number of revoked users). As we see, the computation time is roughly a quadratic function for the length of zone key. When the length of zone key is less than 10, the runtime of CKeyGen algorithm is less than 1.5 seconds. When the length comes up to 60, the runtime grows to 64 seconds. Since the number of kernel members is usually not large in a community, the scheme is feasible in practice.

2) ENCRYPTION AND DECRYPTION OPERATIONS
Secondly, we turn our attention to the performance of encryption algorithm. In order to improve the performance, our scheme uses a two-level encryption structure: the message is firstly encrypted by a session key via a symmetric encryption scheme, and then this session key is encrypted by our AutoZone scheme (called as the header of ciphertext). This structure solves the encryption problem of variable length message. VOLUME 8, 2020  In terms of this structure, the rumtime spent on encrypting a message can be divided into two parts: the runtime on generating the header and the runtime on encrypting the file by symmetric encryption. Here, we are only concerned about the former. In Fig. 7(a), we show the runtime of generating header under the different lengths of zone key, which is also denoted by the number of kernel members. It is easy to see that the computation time is approximately a linear function in the length of zone key. For a specific instance, when the file is 1KB, this figure shows that the runtime is less than one second, even when the length of zone key is grown to 50.
For the decryption operations, we are equally concerned about the decryption of the ciphertext header in the abovementioned structure. In Fig. 7(b), we observe that the performance grow linearly with the length of zone key. As we can see, the time is 0.46 second for the length of zone key 10; and it is nearly 2.2 seconds for a longer zone key with 50 members. Thus, the latter is approximately 5 times as much as the former. But the runtime is considerably short under the different lengths of zone key.

3) PERFORMANCE COMPARISON WITH RELATED WORKS
Finally, Table 5 summarizes the comparison results between flyByNight [36], Persona [37], and our scheme. We can observe that our approach have following advantages: autonomy, collaboration, anonymous authentication, revocation, and integrity checking. These features could significantly mitigate privacy risks in using OSNs.

VI. CONCLUSION
In this paper, we presented AutoZone, a framework to secure social network data against untrusted OSN providers to meet the privacy needs of OSNs. AutoZone allows a set of mutually trusted uses to set up and manage a private zone where contents within the zone can only be accessed by authorized zone members. Its access permission delegation and revocation mechanisms provide flexibility in membership management. The concept of public permission greatly reduce the overhead for secret management for OSN users. Our proof-of-concept prototype clearly demonstrated practicality of AutoZone with manageable computation overheads. He has edited several books and authored or coauthored more than 100 refereed articles and book chapters, as well as participated in many international activities, including organizing international conferences, serving as the Steering Committee for the IEEE Computer Society Signature Conference on Computers, Software and Applications, the Asia-Pacific Software Engineering Conference, the IEEE International Conference on Software Quality, Reliability and Security, the International Symposium on System and Software Reliability, and the program committee of more than 70 international conferences. His current research interests include software engineering, artificial intelligence, and big data analytics. He was a recipient of special contribution awards in both 1992 and 1993 and a PIP Award in 1993 at Lockheed Missiles and Space Company, Inc. He is an Associate Editor of the IEEE TRANSACTIONS ON