Flexible Data Access Control based on Trust and Reputation in Cloud ...

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT)
REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < evaluation on different system entities, e.g., according to social networking experiences. The CSP offers data storage services. But it could be curious to seek the privacy of other parties based on stored data and may disclose it. CSP provides stored data to a requester according to the instruction of RC and/or the data owner due to business incentive. RC is always available for registration and authorization of data access rights. But RC is not allowed to access the stored data by CSPs. RCs and CSPs don’t collude with each other due to business reasons since collusion may make both of them lose profits. This is assumed based on a game theoretic study. Concretely, if a collusion strategy is applied, CSP cannot earn revenue due to loss of data storage users and RC will lose its business since finally it cannot collect data insurance fee.  The communications between the system entities are secured by applying an existing security protocol. Each cloud user registers at its delegating RCs with a unique identifier and personal data access policies. Our scheme follows existing regulations, e.g., relevant identities and qualification certificates (e.g., health physician certifications) should be registered and verified before executing our scheme. We further assume context-aware trust evaluation is applied to support our scheme. We only consider the trust or reputation required in the context of data access. Notably, the trust level sufficient for different data access could be different. In different contexts, different trust evaluation algorithms could be applied for supporting access control. The data owner can choose RCs based on their reputations, which can be evaluated based on data owner feedback, the QoS of RC services, and so on.  

5

A. Notations/Preliminaries and Definitions

• Non-degenerate: ℯ(𝑔, 𝑔) ≠ 1 for the generator 𝑔. • Computable: there is an efficient algorithm to compute ℯ(𝑢, 𝑣) for any 𝑢, 𝑣 ∈ 𝔾. Definition: Individual Trust Level (TL) is the trust evaluated by a data owner based on personal interaction and experiences (e.g., in social networking activities). Herein, we divide trust into discrete levels according to its value, e.g., 𝑇𝐿! represents the i-th level of TL, 𝑖 ∈ (0, 𝐼!" , where 𝐼!" is the maximum level of TL. To effectively secure private data over the cloud, we resort to controlling the data access based on trust levels assessed by the data owner by applying ABE. The advance is the owner can issue to a number of eligible users by performing encryption computation only once. But different users cannot collude with each other because their decryption keys are personalized. Herein, we illustrate our scheme with CP-ABE. Notably, KP-ABE can also be applied to implement our scheme. Adopting CP-ABE saves efforts of key management, while applying KP-ABE can save the computation cost of data encryption. Definition: Reputation Value (RV) is the trust evaluated by a reputation center based on public feedback and extensive performance monitoring and reporting. 𝑅! (𝑡) denotes the reputation value of entity e at time t. 𝑅! (𝑡) ∈ [0, 1 , scaling from fully disreputable to fully reputable. Proxy Re-Encryption: A PRE scheme is represented as a tuple of (possibly probabilistic) polynomial time algorithms (KG; RG; E; R; D) [25]: • (KG; E; D) are the standard key generation, encryption, and decryption algorithms for an underlying public key encryption scheme. On input of a security parameter 1! , KG outputs a public and private key pair (𝑝𝑘! , 𝑠𝑘! ) for entity A. On input 𝑝𝑘! and data M, E outputs a ciphertext C_A = E(𝑝𝑘! ; M). On input 𝑠𝑘! and ciphertext C_A, D outputs the plain data M = D(𝑠𝑘! ; C_A). • On input ( 𝑝𝑘! ; 𝑠𝑘! ; 𝑝𝑘! ), the re-encryption key generation algorithm, RG, outputs a re-encryption key rk_A→B for entity B. • On input rk_A→B and ciphertext C_A, the re-encryption function R, outputs R(rk_A→B; C_A) = E(𝑝𝑘! ; M) = C_B, which can be decrypted with private key 𝑠𝑘! . We further resort to controlling data access based on the reputation evaluated by one or more RCs by applying PRE to convert encrypted data to the form that can be decrypted by eligible and reputable requesters according to the pre-defined policy of the data owner. Introducing RCs can ensure the control availability even though the data owner is not available or has no idea how to control the access. Meanwhile, RCs cannot get the plaintext of data in PRE.

Bilinear pairing: Let  𝔾  and 𝔾 ! be two cyclic multiplicative groups with the same prime order 𝑝, that is, 𝔾 = |𝔾 ! | = 𝑝. Let 𝑔 be a generator of 𝔾 . Let us have a bilinear map ℯ ∶  𝔾  ×  𝔾   →   𝔾 ! , with the following properties: • Bilinear: for all 𝑢, 𝑣 ∈ 𝔾 and 𝑎, 𝑏 ∈ 𝑍! , ℯ(𝑢 ! , 𝑣 ! ) = ℯ(𝑢, 𝑣)!" .

B. Scheme Summary We propose multi-dimensional data access control based on individual trust evaluated by the data owner and/or public reputation evaluated by one or more RCs during the fulfillment of a cloud service. Taking two-dimensional control as an example, the data owner encrypts its data with a

B. Design Goals To achieve trustworthy data access and avoid potential risks in cloud storage services, our design should achieve the following security and performance goals: 1) security and safety: the data stored in CSP can only be accessed by eligible system entities that are trustworthy enough; the control of data access is based on trust and reputation with a minimum risk; 2) heterogeneity: the proposed scheme can support various data access demands. It can support data access directly controlled by the data owner and/or by one or more RCs in an indirect way when the data owner is not available or cannot make an access decision; 3) flexibility: the proposed scheme can be flexibly applied to satisfy different access control scenarios, strategies and policies; 4) lightweight: the scheme controls cloud data access with minimum computation and communication overhead. IV. THE PROPOSED SCHEME

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < symmetric secret key 𝐾. It divides 𝐾 into two parts: 𝐾! and 𝐾! . It respectively encrypts 𝐾! with RC’s public key 𝑝𝑘_𝑅𝐶 and 𝐾! with a public attribute key 𝑝𝑘_𝑇𝐿 with regard to an individual trust attribute. It uploads the encrypted data and the above two encrypted partial keys to CSP. When a user requests accessing the data, the CSP checks if the user (i.e., a requestor) is in a greylist. If the check is negative, CSP forwards its request to RC and the data owner based on the owner’s access policy. RC checks the user’s reputation and generates a re-encryption key for the user to decrypt 𝐾! if it is eligible based on the policy defined by the data owner (e.g., the reputation of user 𝑒 is over a pre-defined threshold 𝑡ℎ𝑟 at the checking time 𝑡 , 𝑅! 𝑡 > 𝑡ℎ𝑟 ). Meanwhile, the owner issues a personalized secret key to the requestor to allow it to get 𝐾! if its trust level satisfies the access policy. By achieving both 𝐾! and 𝐾! , the requestor can access the encrypted data. In case that the requestor is not eligible to access the data (e.g., the reputation/trust level of the requestor is below a threshold), RC and/or the data owner will inform CSP to put it into a greylist. Thus CSP will block this requestor’s access in the future. If the requestor later on becomes eligible, RC and/or the data owner inform CSP to remove it from the greylist. We will discuss how to ensure CSP to process as expectation in Section IV. 𝐾! and 𝐾! can be flexibly set based on different application scenarios and access strategies of the data owner. If the data owner would like to control data access only by itself, 𝐾! is 𝑛𝑢𝑙𝑙 and 𝐾! = 𝐾. If it would like to control data access only by RC, 𝐾! = 𝐾 and 𝐾! = 𝑛𝑢𝑙𝑙. If the data owner would like to control its data access by both individual trust and public reputation (i.e., by both the data owner and RC), neither 𝐾! nor 𝐾! is null, and aggregating 𝐾! and 𝐾! can get 𝐾. If the data owner would like to control its data access by either individual trust or public reputation (i.e., by either the data owner or RC), 𝐾! = 𝐾! = 𝐾 ≠ 𝑛𝑢𝑙𝑙. If the data owner doesn’t want to control its data access, 𝐾! = 𝐾! = 𝐾 = 𝑛𝑢𝑙𝑙. That means plain data are stored at the data center of CSP. Notably, the data encryption key 𝐾 can be divided into multiple parts in order to really support multi-dimensional data access control. For example, the data owner can set the access control strategy such as controlling its data access based on the reputations evaluated by multiple RCs in order to highly ensure data security and privacy, especially when it is off-line. In this case 𝐾 is separated into multiple parts 𝐾! , 𝐾! , …, 𝐾! (𝑛 ≥ 2). The data owner encrypts different parts of 𝐾 with different RC’s public keys 𝑝𝑘_𝑅𝐶! . Later on, the data access can be controlled by all RCs (e.g., with regard to different reputation properties or contexts) by issuing re-encryption keys to decrypt different parts of 𝐾. Obviously, our scheme can flexibly support controlling cloud data access by not only the data owner, but also a number of RCs. The data owner manages the policy of data access control. It decides who has rights to control the data access. Our scheme is very flexible to handle many cases: data is controlled by the owner itself, or only one RC, or multiple RCs or all above at the same time. Their control relationship

6

could be “or”, not only “and”, in order to ensure control availability. In case some control party is not always online, another party can delegate the duty. We achieve this by issuing the same partial key to multiple parties (e.g., RCs). C. Required Keys Table I summaries the keys related to the proposed scheme. TABLE I. SUMMARY OF APPLIED KEYS Keys 𝐾 𝐾! , 𝐾! , …

Description The data encryption key The different parts of 𝐾

𝑃𝐾 𝑀𝐾 𝑝𝑘_𝑢

The global public key The master key The public key of user 𝑢 w.r.t. ABE

𝑠𝑘_𝑢

The secret key of user 𝑢 w.r.t. ABE

𝑝𝑘_(𝑇𝐿, 𝑢)

The public key of attribute TL generated by user 𝑢 The secret key of attribute TL for user 𝑢′ issued by 𝑢 The public key of RC w.r.t. PRE The secret key of RC w.r.t. PRE The public key of entity u w.r.t. PRE The private key of entity u w.r.t. PRE

𝑠𝑘_(𝑇𝐿, 𝑢, 𝑢′) 𝑝𝑘!" 𝑠𝑘!" 𝑝𝑘! 𝑠𝑘! 𝑟𝑘_𝑅𝐶 → 𝑢

Re-encryption key to re-encrypt a ciphertext computed under RC’s public key into one that can be decrypted using 𝑢’s privacy key.

Usage Encrypting data Aggregating all parts of 𝐾 can get a complete 𝐾 Input for ABE operations Creation of user keys Unique ID of user and the key for verification of the user’s attributes; used for personalized secret attribute key generation for 𝑢 Generation of public key of TL for 𝑢 and used for issuing secret attribute keys to 𝑢′ based on TL eligibility Encryption of 𝐾! generated by user 𝑢 Decryption of 𝐾! generated by user 𝑢 for 𝑢′ Encryption of partial 𝐾 Generation of re-encryption key at RC Generation of a re-encryption key for u Decryption of re-encrypted partial key for u Re-encryption of partial symmetric key 𝐾

D. Scheme The proposed scheme consists of a number of fundamental algorithms as described below. Setup. The Setup algorithm takes as input the implicit security parameter 1! . It chooses a bilinear multiplicative group 𝔾 of prime order 𝑝 with generator 𝑔 and a pairing ℯ ∶  𝔾  ×  𝔾   →   𝔾 ! . Next it chooses a random point 𝑃   ∈  𝔾, and a random exponent 𝑦 ∈   ℤ! . Then it outputs the public key 𝑃𝐾 =   𝔾, 𝔾 ! , 𝑒, 𝑔, 𝑃, 𝑒 𝑔, 𝑔 ! , and the master key 𝑀𝐾 = 𝑔 ! . This process is conducted at the user device or a trustworthy user agent. Meanwhile, each RC generates its public and private keys 𝑝𝑘!" and 𝑠𝑘!" for the purpose of PRE. ABEUserKeyGeneration(PK, MK, u). This algorithm takes as input the public key 𝑃𝐾, the master key 𝑀𝐾, and a unique user identity 𝑢 . It chooses a random secret 𝑚𝑘! ∈ ℤ! and outputs a public user key 𝑝𝑘_𝑢 = 𝑔!"! , that will be used to issue secret attribute keys for 𝑢 , and a secret user key

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 𝑠𝑘_𝑢 =  𝑀𝐾 ∙ 𝑃 !"!   = 𝑔 ! ∙ 𝑃 !"! , used for the decryption of ciphertexts. It also uniformly and randomly chooses a hash function 𝐻!"_! ∶ 0,1 ∗   →   ℤ! from the finite family of hash functions. This process is also conducted at the user device or a trustworthy user agent. PREUserKeyGeneration(u). This algorithm generates pubic key 𝑝𝑘! and private key 𝑠𝑘! for PRE [26]. 𝑝𝑘!   = 𝑍 !! , 𝑔′!! , 𝑠𝑘! = 𝑎! , 𝑎! . The system parameters are random generators 𝑔′   ∈  𝔾 , 𝑍 = 𝑒(𝑔, 𝑔)   ∈   𝔾 ! , and 𝑎! , 𝑎!   ∈   ℤ! . 𝑝𝑘! is used for generating the re-encryption key at RC for 𝑢. This algorithm is still conducted at the user device or a trustworthy user agent. CreateEncryptionKey(). The algorithm generates a symmetric key 𝐾 for data encryption and is performed by the data owner. In our implementation, Advanced Encryption Standard (AES) is applied. DivideKey(K, n). The DivideKey algorithm divides input 𝐾 into 𝑛 + 1 parts, where 𝑛 ≥ 0. CombineKey( 𝐾! , 𝐾! , …, 𝐾! ). The CombineKey algorithm aggregates partial keys (𝐾! , 𝐾! , … , 𝐾! ) to get a complete key 𝐾. CreateIndividualTrustPK(PK, TL, sk_u). The algorithm is executed by the user device whenever user 𝑢 would like to control the access of its data based on individual trust evaluation. The algorithm checks the TL related policies. If this is the case, the algorithm outputs a public attribute key of the TL for user 𝑢, denoted 𝑝𝑘_(𝑇𝐿, 𝑢), which consists two parts: 𝑝𝑘_(𝑇𝐿! , 𝑢) =  < 𝑝𝑘_(𝑇𝐿! , 𝑢)′ =   𝑔!sk_u !"! , 𝑝𝑘_(𝑇𝐿! , 𝑢)′′   =  𝑒 𝑔, 𝑔 !!sk_u(!"!) >, otherwise outputs NULL. Note that  pk_ 𝑇𝐿, 𝑢) = 𝑝𝑘_ 𝑇𝐿! , 𝑢 , (𝑖 ∈ 0, I!" , where I!" is the maximum level of TL. IssueIndividualTrustSK(PK, TL, sk_u, pk_u’). The algorithm is executed at the user device by checking the eligibility of 𝑢′. The algorithm checks whether 𝑢′ with public key 𝑝𝑘_𝑢′ is eligible of the attribute TL (i.e., it checks in which trust level 𝑢′ is located). If 𝑢′ is located in the trust level 𝑉!" (𝑉!" is an integer and 𝑉!" ∈[0, I!" ]), we said 𝑢′ is eligible for attribute 𝑇𝐿! , (𝑖 ≤ 𝑉!" ). Then the algorithm outputs a secret TL key 𝑠𝑘_(𝑇𝐿, 𝑢, 𝑢′) for user 𝑢': 𝑠𝑘_ 𝑇𝐿! , 𝑢, 𝑢′ = 𝑝𝑘_𝑢′!!"_!(!"!) = 𝑔!"!!!!"_!(!"!) , (𝑖 = 𝑉!" ). Otherwise, the algorithm outputs NULL. Encrypt0(𝑃𝐾, 𝐾! ,𝐴𝐴,𝑝𝑘_(𝑇𝐿, 𝑢)). This algorithm takes as input the partial key 𝐾! and the public keys 𝑝𝑘_(𝑇𝐿, 𝑢) , corresponding to the individual trust occurring in the data access policy 𝐴𝐴 of user 𝑢. The algorithm encrypts 𝐾! with the policy 𝐴𝐴 and outputs the cipher-key 𝐶𝐾! . The access policy 𝐴𝐴 can be described as 𝐴𝐴 = ! !!! 𝑇𝐿_𝑗 , where m represents the number of selected TL.  𝑇𝐿! represents an individual trust level set by 𝑢 to control the access. 𝑇𝐿_𝑗 = 𝑇𝐿! means that 𝑢 gives the users with 𝑇𝐿! the authority to decrypt the cipher-key. For example, 𝐼!" = 5, 𝐴 = 𝑇𝐿! 𝑇𝐿! means the users with 𝑇𝐿 ≥ 4 can be granted access rights. The Encrypt0 algorithm iterates over all 𝑗 = 1, … , 𝑚. It

7

generates a random value 𝑅! ∈   ℤ! , for each required TL level 𝑇𝐿! in the policy and constructs 𝐶𝐾!! as: ! 𝐶𝐾!! =  𝐸! = 𝐾! ∙ 𝑝𝑘_(𝑇𝐿! , 𝑢)!! !    𝐸!! = 𝑃!! ， !

𝐸!!! = 𝑝𝑘_(𝑇𝐿! , 𝑢)! ! . This process is conducted at the device of a data owner. The owner publishes the output of the algorithm along with its encrypted data to CSP. Decrypt0  (𝑃𝐾, 𝐴𝐴, 𝐶𝐾! , 𝑠𝑘_𝑢′, 𝑠𝑘_(𝑇𝐿, 𝑢, 𝑢 ! )) . The Decrypt0 algorithm takes as input a cipher-key produced by the Encrypt0 algorithm and a key ring 𝑠𝑘!! , 𝑠𝑘_(𝑇𝐿, 𝑢, 𝑢 ! ) for user 𝑢 ! . It decrypts the cipher-key 𝐶𝐾! and outputs the corresponding plain key 𝐾! if the attribute is sufficient to satisfy the policy 𝐴𝐴  used for encryption. 𝐾! = 𝐸! ∙

! !! ! ,!"_(!"! ,!,!!) ! !! !! ,!"_!'

.

Otherwise it outputs NULL. It is easy to verify that the decryption is correct [8]. Let a! : =   Hsk_! (𝑇𝐿! ). Then, E! = 𝐾! ∙ e(g, g)!!!!! , E!!! = g !!!! and 𝐸! ∙

! !! ! ,!"_(!"! ,!,!!) ! !! !! ,!!!'

𝐾! ∙ 𝑒 𝑔, 𝑔

!!! !!

∙

= 𝐾! ∙ 𝑒 𝑔, 𝑔 ! !,!

!!! !!

∙

!! !" ! !! !

! !" ! ! !,! ! !! ! ∙! !,! !!! !!

! !!! ,!

!" ! !! !

! !!! !! ,!! ∙!

!" ! !

=

= 𝐾! .

ReencryptionKeyGeneration(  𝑝𝑘!" , 𝑠𝑘!" , 𝑝𝑘!! ). This algorithm is defined in [26], the output 𝑟𝑘_𝑅𝐶 → 𝑢’ = !! 𝑔′!!!! = 𝑝𝑘!! , where 𝑎! is part of 𝑠𝑘!" and 𝑏! is part of 𝑠𝑘!! . On input 𝑝𝑘!" , 𝑠𝑘!" , and  𝑝𝑘!! , the algorithm generates the re-encryption key rk_RC→  𝑢’ for 𝑢’ if it satisfies the access policy of the data owner based on the latest reputation evaluation at RC. The RC then forwards rk_RC→  𝑢’ to CSP. Encrypt1( 𝑝𝑘!" , 𝐾! ). As defined in [26], a data owner encrypts its partial secret key 𝐾!  (𝑛 ≥ 1) using the public key of RC to obtain the encrypted 𝐾! by 𝑝𝑘!" , denoted 𝐸(𝑝𝑘!" ; 𝐾! ), 𝐸(𝑝𝑘!" , 𝐾! ) = (𝑔′! , 𝐾! 𝑍 !!! ), where 𝑍 !! is part of 𝑝𝑘!" and  𝑥 ∈   ℤ! . The owner publishes 𝐸(𝑝𝑘!" , 𝐾! ) along with its encrypted data to CSP. RE(rk_RC→  𝑢’,𝐸(𝑝𝑘!" , 𝐾! )). If an entity 𝑢′ is allowed to access the data, CSP conducts 𝑅𝐸(𝑟𝑘_𝑅𝐶 → 𝑢’, 𝐸(𝑝𝑘!" , 𝐾! )) = 𝐸(𝑝𝑘!! , 𝐾! ) = 𝑍!!!!! , 𝐾! 𝑍 !!! =  𝐶𝐾! , and gives it to 𝑢′ . User 𝑢 ! decrypts 𝐸(𝑝𝑘!! , 𝐾! ) using its private key 𝑠𝑘!! to obtain 𝐾! . In the proposed scheme, CSP functions as the proxy in terms of PRE [26]. It indirectly distributes the partial secret key 𝐾! to authorized entities without learning anything about these secrets (e.g., 𝐾! and the plain data). Decrypt1(𝑠𝑘!! , 𝐸(𝑝𝑘!! , 𝐾! )). The algorithm takes as input a cipher-key produced by the RE algorithm and 𝑠𝑘!! and decrypts the cipher-key 𝐸(𝑝𝑘!! , 𝐾! ), 𝐾! =  

!! ! !! !

!

(! !! !! ! )!!

.

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < Encrypt(K, M). This algorithm takes as input K and data M to get encrypted data CT. The data owner publishes CT to CSP. In our implementation AES is applied. Decrypt(CT, K). The algorithm takes as input a cipher-text CT produced by the Encrypt algorithm and the complete encryption key 𝐾 to output the plaintext 𝑀. E. Procedure Figure 2 illustrates the procedure of data access control based on the proposed scheme. We suppose that user 1 (𝑢! ) saved its sensitive personal data at CSP, while user 2 (𝑢! ) requests to access it with the authorization of 𝑢! and one RC.

8

Step 6: 𝑢! decrypts 𝐶𝐾! and 𝐶𝐾! with the issued secret keys from 𝑢! and its private key 𝑠𝑘!! . By combining 𝐾! and 𝐾! , 𝑢! can get the complete 𝐾 to decrypt CT and get M. Step 7: 𝑢! re-evaluates the trust based on past and newly accumulated experiences regarding the data access context. If 𝑢! has been issued the secret keys and is not eligible at present, 𝑢! will put them into its underlying data access greylist and inform the CSP. RC can re-generate reputation of different entities based on newly collected data. If RC indicates that 𝑢! doesn’t satisfy with access policy 𝐴𝐴, RC will inform the CSP to block 𝑢! ’s access to 𝑢! ’s data. Note that the greylist is data-oriented since different data access may request different trust levels. Its content is dynamically upgraded based on timely trust and reputation evaluation. F. Revocation

Fig. 2: A procedure of data access control

Step 0: System setups by calling Setup. Step 1: 𝑢! generates an encryption key 𝐾 and separates it into two parts 𝐾! and 𝐾! . It encrypts data M with the secret key 𝐾 to get CT. It generates the data access policy 𝐴𝐴 with regard to individual trust level threshold, public reputation threshold for accessing M. 𝑢! uploads the encrypted data CT, policy 𝐴𝐴 and encrypted 𝐾! (𝐶𝐾! ) by applying Encrypt1 and encrypted 𝐾! (𝐶𝐾! ) by applying Encrypt0 to CSP; 𝑢! also sends 𝐴𝐴 to RC. Step 2: 𝑢! would like to access 𝑢! ’s data by requesting CSP. The CSP checks the validity of its ID and the package of encrypted 𝐾 in order to decide if forwarding this request to 𝑢! and/or RC if it is not in the greylist. Based on the content in 𝐴𝐴, the CSP decides whether to contact 𝑢! and/or RC. Step 3: If RC is contacted, RC evaluates 𝑢! ’s reputation and checks if it satisfies with M’s access policy 𝐴𝐴. Based on the reputation level, RC generates 𝑟𝑘_𝑅𝐶 → 𝑢! if access is allowed; meanwhile, if 𝑢! is contacted, it checks the eligibility of 𝑢! in order to generate a personalized secret key 𝑠𝑘_(𝑇𝐿, 𝑢! , 𝑢! ) for 𝑢! to decrypt 𝐶𝐾! . Step 4: RC issues 𝑟𝑘_𝑅𝐶 → 𝑢! to the CSP that re-encrypts the 𝐶𝐾! to get 𝐸(𝑝𝑘!! , 𝐾! ) if the re-encryption was never conducted; meanwhile, 𝑢! issues 𝑠𝑘_(𝑇𝐿, 𝑢! , 𝑢! ) to 𝑢! . Step 5: CSP allows 𝑢! to access requested data by providing corresponding encrypted data CT and encrypted keys (𝐶𝐾! and 𝐶𝐾! ) to 𝑢! .

Due to the dynamic change of trust and reputation, the data access right should be dynamically managed. The proposed scheme applies three ways of revocation. First, CSP follows the notification of the data owner and/or RCs to block data access if the data requestor’s trust and/or reputation levels don’t satisfy the access policy. When, the data requester’s trust and/or reputation levels reach the access threshold, the block will be released by the CSP. This approach is appropriate in the situation that CSP cooperates with the data owner and the RCs on access control. A way to ensure CSP to perform the above additional access control is applying a reputation mechanism, as illustrated in [29]. Each CSP’s reputation is evaluated according to the user’s feedback and published in order to encourage and ensure good behaviors of CSPs. For a disreputable CSP, the user will not use its services, thus the CSP will lose its users and profits. Second, the data owner re-encrypts 𝐾! with a new TL attribute’s public key if its policy about 𝐾! is changed and sends the new 𝐶𝐾! to the CSP. The data owner will also inform the RCs to update the new policy about 𝐾!  (𝑛 ≥ 1) if there is any change. Thus, later re-encryption key generation will follow the new policy at the RCs. This approach is suitable in the situation that the access policy of the data owner is updated. Third, the data owner refresh data encryption key 𝐾 and applies a new key 𝐾′ to encrypt new data stored at the CSP. This approaches is suitable in the case that the old key could be disclosed to the CSP (e.g., by a malicious data requester or guessed by the CSP). One protection strategy is different symmetric keys are applied to encrypt different data. Another strategy is the data owner updates the symmetric key for data encryption periodically and uploading newly encrypted data to CSP. (We assume deletion of old data can be performed by CSP honestly.) In another line of our work, we proved with game theory that CSP normally would not cooperate with malicious data requesters when applying a reputation and punishment mechanism because it will lose users and profits due to reputation loss. Due to paper size limitation, this study with a number of simulation results will be reported in another paper.

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < V. TRUST EVALUATION & REPUTATION GENERATION Trust can be assessed based on the clue showed in mobile social networking. Herein, we apply a concrete approach for automatic trust evaluation based on mobile social networking in order to gain usability in trust evaluation. The function to calculate the trust value 𝑇𝐿(𝑢! , 𝑢! ) of two persons 𝑢!  and  𝑢!  based on mobile social networking is proposed in our previous work [29]. Notably, other methods can also be applied and cooperate with the proposed scheme. User feedback, performance monitoring and reporting contribute reputation generation. In [30], we proposed a concrete algorithm to support data access control in cloud computing. Notably, the trust evaluation and reputation generation are context-aware. For data access in a concrete context (e.g., health treatment), the trust is evaluated and the reputation is generated. In this paper, we focus on heterogeneous cloud data access control scheme design and evaluation. VI. SECURITY ANALYSIS & PERFORMANCE EVALUATION A. Security Proofs The security goal of our scheme is to guarantee that only the users whose trust and reputation satisfy the access control policies of the data owner can access the data saved in the cloud. The proposed scheme achieves security as analyzed below. Fine-Grainedness of Access Control Our scheme can achieve fine-grained access control. Various access policies regarding trust and/or reputation can be defined and enforced. We remove the complexity of hierarchical attribute-based fine-grained access control [22] by replacing it with trust-reputation based one. We evaluate the trust levels according to many factors and simplify the ABE attribute structure by only considering one attribute: trust levels. This design not only reduces the complexity of access policy description, but also keeps its expressivity. The computation of trust evaluation is much less complicated than embedding the trust-factor related attributes into the attribute structure of an ABE scheme. The reputation generation is performed at RC, which can release the computation burden of data owners. Apart from the above, the proposed scheme can be flexibly applied into many scenarios by cooperating with a trust management framework. Context-awareness can be easily achieved by applying context-aware trust evaluation and reputation generation. Data confidentiality The security of this scheme is ensured by the PRE theory, ABE theory, symmetric encryption theory and public key encryption theory. In particular, we apply trust and reputation to control data access in a heterogeneous manner to enhance both security and flexibility in cloud computing. Data confidentiality is achieved by symmetric key encryption (e.g., AES), ABE, and PRE. Assuming that the symmetric key algorithm is secure, the security of the proposed scheme relies on the security of our architecture design based on the PRE and ABE. RCs are unable to access

9

the user data stored in CSP even though they hold the partial encryption key (refer to 𝐸(𝑝𝑘!" , 𝐾! ) ) in the case that 𝐾! ≠ 𝐾! , 𝐾! ≠ 𝑛𝑢𝑙𝑙. Meanwhile, the plaintext of the user data is also hidden from CSP since it could only gain the re-encryption keys and the CSP, alone, cannot re-delegate the decryption rights from, for example, rk_RC→A and rk_A→B to produce rk_RC→B, because of the non-transitive property of PRE. Even though the CSP colludes with user B who has been issued the decryption right, they can only recover the weak secret ga1 instead of the private key of RC, 𝑠𝑘!" . The standard security and master key security have been proved in [26], which shows that the PRE used in our scheme is secure. In addition to the security of the encryption algorithm, the reputation mechanism encourages the system entities to behave properly in order to retain or improve their reputation levels. User accountability can also be achieved by setting up a punishment rate according to their reputation levels when RCs issue re-encryption keys for data requesters [30]. Security Proof of ABE We analyze the security of ABE used in our scheme by, firstly, defining a security model, which we call Game 1, and then comparing it with a modified model, Game 2, which has already been proved as secure in our previous work [21] in order to prove the security of Game 1. We sketch these two games firstly and describe the reduction procedure subsequently. It is customary to define security in a context like ours by using a model involving a game between two parties where one of the parties is an adversary who tries to get an advantage in the game. More specifically, we define the security model of our scheme as follows between an adversary 𝒜 and a challenger 𝒞. Game 1 Setup. A challenger 𝒞, who plays the role of the data owner or a trustworthy user agent, runs the Setup algorithm and gives the public key 𝑃𝐾 to an adversary 𝒜. Phase 1. The adversary 𝒜 asks the challenger 𝒞 for an arbitrary number of user keys. Herein, the users include all kind of data consumer, such as users and CPSs who want to access the data. The challenger 𝒞 calls the ABEUserKeyGeneration algorithm for each requesting user and returns the resulting public and private user keys to 𝒜. Meanwhile, for each user, 𝒜 can request the secret and public attribute keys that 𝒞 creates by calling key generation algorithms, i.e., IssueIndividualTrustPK and IssueIndividualTrustSK algorithms, respectively. Challenge. The adversary 𝒜 submits two messages 𝑀! and 𝑀! and an access policy 𝐴𝐴 such that none of the users he created in Phase 1 satisfy 𝐴𝐴. (If any user from Phase 1 satisfies 𝐴, the challenger aborts.) The challenger 𝒞 flips a coin 𝑏, encrypts 𝑀! under 𝐴𝐴, and gives the cipher text CT to the adversary. Phase 2. Like in Phase 1, the adversary may create an arbitrary number of users. He can also request more secret attribute keys for the users he created in Phase 1 and Phase 2. The only restriction is if any secret attribute key would give the respective user trust level that would satisfy 𝐴𝐴, then the

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < challenger aborts. As described before, 𝒜 can always request any public attribute keys. Guess. The adversary 𝒜 outputs a guess 𝑏 ! of 𝐴𝐴 . The advantage of adversary 𝒜 is defined as: Advantage = 𝑃𝑟 𝑏 ! = 𝑏 − 0.5. We claim that our scheme is secure in Game 1 if the advantage of the adversary 𝒜 is negligible whenever the adversary operates in probabilistic polynomial time. Game 2 The phases Setup, Phase 1, and Phase 2 are equal to the Game 1. In the Challenge phase, the adversary 𝒜 submits an access policy 𝐴𝐴  such that none of the users that he created in Phase 1 satisfy 𝐴𝐴  (but unlike the Game 1, 𝑀! and M! are not submitted). The challenger 𝒞 flips a coin 𝑏, and creates a ciphertext for the access policy 𝐴𝐴, but instead of computing 𝐸! ≔ 𝑀 ∙ 𝑒 𝑔, 𝑔 !!!!! (We replace 𝐾! with 𝑀 here for convenience) according to our encryption algorithm, he computes E! as 𝐸! =

𝑒 𝑔, 𝑔 !!! !! ,        𝑖𝑓    𝑏 = 1 , 𝑒 𝑔, 𝑔 !! ,          𝑖𝑓    𝑏 = 0

where all elements 𝜃! are uniformly and independently chosen random numbers from ℤ! . Then we make the assumption that there exists a polynomial-time adversary 𝒜1 who has a non-negligible advantage in Game 1. With the help of 𝒜1 we are then able to construct another polynomial-time adversary 𝒜2 who has a non-negligible advantage in Game 2. In our previous work [21], it has been showed that Game 2 is secure under polynomial-time adversary. Then, we can draw a conclusion that the ABE used in our scheme is provable secure. Next, we show how to construct 𝒜2 from 𝒜1. Given now an adversary 𝒜1 that has an advantage 𝜖 in Game 1, we can construct 𝒜2 as follows: in the phases Setup, Phase 1, and Phase 2,  𝒜2 forwards all messages he receives from 𝒜1 to the challenger (of the Game 2) and all messages from the challenger to 𝒜1 . In the Challenge phase, 𝒜2 receives two messages 𝑀! and 𝑀! from 𝒜1 and the challenge 𝐶 , which is either 𝑒 𝑔, 𝑔 !!!!! or 𝑒 𝑔, 𝑔 !! , from the challenger 𝒞. Now 𝒜2 has to play the role of the challenger in Game 1 and therefore he flips a coin 𝛽 and sends 𝐶 ! ≔ 𝑀! ∙ 𝐶 to 𝒜1. When  𝒜1 outputs a guess 𝛽 ! , 𝒜2 outputs as its own guess 1 if 𝛽 ! = 𝛽, or 0 if 𝛽 ! ≠ 𝛽. If 𝐶 = 𝑒 𝑔, 𝑔 !!!!! , then 𝒜2 ’s challenge (in the game against 𝒜1 ) is 𝐶 ! ≔ 𝑀! ∙ 𝑒 𝑔, 𝑔 !!!!! , which is a random encryption of 𝑀! under the public keys 𝑝𝑘_ 𝐿𝑇, 𝑢 , and consequently 𝒜1 has advantage 𝜖 of guessing the correct 𝛽 ! = 𝛽. It follows that 𝒜2 has the same advantage in its own game. If 𝐶 = 𝑒 𝑔, 𝑔 !! , then the challenge 𝐶 ! is nominally dependent of 𝛽 but in fact 𝐶 ! could result from each of the messages 𝑀! and 𝑀! , with a suitable choice of the parameter 𝜃! . This implies that 𝒜1 cannot have any advantage in guessing 𝛽 so the advantage of 𝒜2 is also 0. ! Thus, the overall advantage of 𝒜2 is 𝑃𝑟 𝛽 ! = 𝛽|𝑏 = 1 + ! !

!

! !

!

! !

𝑃𝑟 𝛽 ! ≠ 𝛽|𝑏 = 0 − =

+𝜖 +

! !! !!

!

!

!

!

− = 𝜖.

10

Now the existence of any 𝒜1 having a non-negligible advantage in Game 1 implies the existence of an adversary 𝒜2 who succeeds with non-negligible advantage as well in Game 2. However, in [21], it is shown that no polynomial time adversary can have a non-negligible advantage in Game 2. So we can conclude that no 𝒜1 can have non-negligible advantage in Game 1. According to the analysis above, we can conclude that the data confidentiality of our proposed scheme is provably secure under the protection of ABE. B. Performance Analysis Computation Complexity We analyze the computation complexity of the following operations: setup, CP-ABE user key generation, PRE user key generation, individual trust public key and secret key generation, re-encryption key generation and re-encryption, encryption and decryption, as well as revocation. The setup and key generations, including the generation of the CP-ABE user key pair, the PRE user key pair and the re-encryption key, are not affected by either the specified access policy or attributes. Therefore, the computation complexity of the above operations is 𝒪 1 . When individual trust level is considered in the access authorization, the data owner needs to generate the individual Trust Level public key for encryption and issue the private key to eligible data requesters. The computation complexity of TL public key generation depends on the total number of specified TL levels, thus the complexity is 𝒪 2𝐼!" , where 𝐼!" refers to the maximum number of TL levels. Note that each level of TL public key generation contains two exponentiations. The TL private key issuing is only related to the authorized attribute, and the computation complexity is 𝒪 1 . The encryption contains several parts: Encrypt, Encrypt0 and Encrypt1. The first is the encryption of the data using symmetric key 𝐾, and the rest is the encryption of partial key using either CP-ABE or PRE, or both depending on the data owner’s access policy. The complexity of Encrypt depends on the size of the underlying data and it is inevitable in any cryptographic method. The complexity of Encrypt0 and Encrypt1 depends on the data owner’s policy on key division and the required TL level in the access policy. For each CP-ABE encryption operation, the complexity is 𝒪 𝐿 , where L is the number of conjunction in the specified access policy and 𝐿 ≤ 𝐼!" . For each PRE encryption operation that contains two exponentiations, the complexity is 𝒪 1 . For n pieces of partial keys for RC management, the complexity is 𝒪 𝑛 . The Decryption also contains two parts. One is decrypting divided pieces of encrypted partial keys, and the other is the decryption of the data using the plain key 𝐾 . For each decryption operation in either CP-ABE or PRE, the complexity is 𝒪 1 . Thus the total computation complexity of Decryption depends on the number of divided key pieces, i.e., 𝒪 𝑛+2 . The computation complexity for applying the first approach of revocation is 𝒪 1 since there is no need to calculate new keys and perform encryption. However, communications are

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT)