Incremental Proxy Re-encryption Scheme for Mobile Cloud Computing ...

Incremental Proxy Re-encryption Scheme for Mobile Cloud Computing Environment Abdul Nasir Khan a,*, M. L. Mat Kiaha, Sajjad A. Madanib, Mazhar Alic, Atta ur Rehman Khana , Shahaboddin Shamshirbanda a

Faculty of Computer Science & Information Technology. University of Malaya, Malaysia

b

Department of Computer Science, COMSATS Institute of Information Technology, Pakistan

c

Department of Electrical and Computer Engineering, North Dakota State University, Fargo, USA *

Corresponding Address: Faculty of Computer Science & Information Technology, University of Malaya, Malaysia, Tel: 0060108124496, Fax: 0060379579249 E-mail Addresses: [email protected] (A.N. Khan), [email protected] (M.L. Mat Kiah), [email protected] (Sajjad A.Madani), [email protected] (M. Ali), [email protected] (A.R. Khan), [email protected] (S. Shamshirband)

Abstract: Due to the limited computational capability of mobile devices, the research organization and academia are working on computationally secure schemes that have capability for offloading the computational intensive data access operations on the cloud/trusted entity for execution. Most of the existing security schemes, such as proxy re-encryption, manager-based re-encryption, and cloud-based re-encryption, are based on El-Gamal cryptosystem for offloading the computational intensive data access operation on the cloud/trusted-entity. However, the resource hungry pairing-based cryptographic operations, such as encryption and decryption, are executed using the limited computational power of mobile device. Similarly, if the data owner wants to modify the encrypted file uploaded on the cloud storage, after modification the data owner must encrypt and upload the entire file on the cloud storage without considering the altered portion(s) of the file. In this paper, we have proposed an incremental version of proxy re-encryption scheme for improving the file modification operation and compared with the original version of the proxy reencryption scheme on the basis of turnaround time, energy consumption, CPU utilization, and memory consumption while executing the security operations on mobile device. The incremental version of proxy re-encryption scheme shows significant improvement in results while performing file modification operations using limited processing capability of mobile devices.

Keywords: Cloud Computing, Mobile Cloud Computing, Security, Privacy

1

1. Introduction Cloud computing is an emerging computing paradigm that introduces an innovative method of computing by offering various elastic computational services in pay-as-you-go manner [13]. To meet the computational requirement of the cloud subscribers, the cloud services can be upgraded and downgraded at runtime with negligible time period and without purchasing new hardware resources [4-8]. Similarly, the utilization of the cloud services on resource constraint mobile devices introduces new computing paradigm known as mobile cloud computing. The objectives of the utilization of the cloud services on resource constraint mobile device are: (a) to increase the processing and storage capabilities of the mobile device, (b) to reduce the energy consumption, and (c) to improve the reliability of the mobile user data and applications [9] through cloud backup services [10, 11]. The architecture of the mobile cloud computing is shown in Figure 1. A light-weight cloud client application is installed on the mobile device that communicates with the cloud controller using mobile network services, such as wireless (Wi-Fi, Wi-Max), cellular (3G or 4G), or satellite internet connectivity, for accessing the cloud services. Cloud Service Provider

WiFi/WiMax

Satellite

Cloud Layered Architecture

3G, 4G

SaaS Google Apps, Backup as a Service

Internet PaaS Google App Engine, Salesforce.com’s Apex Code

Application (Web based Application)

Platform Infrastructure (Application Development Environment and Supported API)

Software Infrastructure Mobile User

IaaS Amazon Elastic Computing Cloud (EC2), Enomaly’s Elastic Computing Platform (ECP) ,

RESERVOIR architecture

(Computational Resources, Storage, and Communication)

Supervisor Software (OS, Hypervisor, Middleware)

Cloud Backbone (Servers, Switches, Hubs etc.,)

Figure 1: Architecture of Mobile Cloud Computing Environment

ABI Research and Juniper Research reports forecast that the adoption of mobile cloud computing subscribers [12] and cloud-based mobile applications [13] are dramatically increasing. However, the international data corporation has conducted a survey [14] from various business organizations to investigate the top most challenges that need urgent attention for maintaining the consistent growth of the cloud subscribers. According to survey results, almost 74% of business organizations are not in the favor of adoption of the cloud services due to security and privacy risk involved. The research organizations and academia are actively working on computationally secure schemes for protecting the data on the cloud storage. However, the resource limitation of mobile devices is an obstacle for executing the computational intensive operations involved in computationally secure schemes. Therefore, there is a need of the security schemes that provides security services with minimum processing, storage, and communication overhead on mobile device. By keeping in view the resource limitation of the mobile device, this paper introduces an Incremental Proxy Reencryption Scheme (I-PReS) that provides confidential and integrity services and improves the file modification operation in terms of turnaround time, energy consumption, CPU usage,

2

and memory utilization on the mobile device without compromising the privacy of mobile users. The rest of the paper is organized as follows. Section II presents the related work for securing the mobile cloud computing environment. In section III, we define the proposed incremental proxy re-encryption scheme. The comprehensive empirical analysis along with some critical remarks is discussed in section IV. Section V concludes our work and addresses future research directions.

2. Existing Security Schemes for mobile users in cloud environment To improve the processing capability of mobile devices, the existing literature focuses on the migration of computational intensive portion(s) of an application on the cloud. The migration of computational intensive portion(s) of an application from resource constraint mobile device to resource enrich cloud improves the processing capability of the mobile device, however there is a need to address the security and privacy issues that are arisen due to the migration of the portion(s) of application. A number of such security issues are identified and addressed in [14-22]. Similarly, the mobile user can store enormous amount of data by using cloud storage services; however there is a need to address the security issues that are formed due to loss of physical control of the mobile user’s data. Few of the issues related to the security and privacy of the mobile user data are identified and addressed in [23-29]. The focus of this paper is on the data security issues; therefore we will limit our discussion only on the security issues that are arisen due to migration of the mobile user’s data on the cloud storage. Interested readers may refer [1] to see the security issues that are occurred due to migration of application or portion(s) of application on the cloud for execution. The classification of the exiting security schemes for mobile cloud computing environment is presented in Figure 2. Security Schemes (20)

Data Security Schemes (10)

Remote Execution (7)

Trusted Entities (3) [28, 29, 25]

Cloud and Trusted Entities (2) [26, 29]

Application Security Schemes (10)

Security of Application Models (1)

Local Execution (3)

Cloud (2) [27, ,30]

Encryption Based Scheme (1) [24]

Coding Based Scheme (1) [24]

Sharing Based Scheme (1) [24]

Elastic Mobile Application model (1) [15, 23]

Mobile Applications Security (9)

MobiCloud (2) [19, 20]

Locationbased Services (2) [17, 21]

Scheduling Services (3) [22]

Authentication In cloud (2) [18, 16]

Figure 2: Classification of the security schemes for the mobile cloud computing

The authors in [23] proposed three privacy preserving schemes for ensuring confidentiality and integrity of the mobile users data while using the cloud storage services. The focus of the schemes presented in [23] is to reduce the computational complexity of cryptographic algorithm and execute entire security operations using the computational power of mobile device. The first scheme called encryption-based scheme uses the standard cryptographic functions for providing the confidentiality services. The second scheme called coding-based scheme uses comparatively light-weight operation (matrices multiplication) as compared to encryption-based scheme for providing the confidentially services. The third scheme called sharing-based scheme uses the XOR operations for providing the light-weight confidentiality services as compared to encryption-based scheme and coding-based scheme. However, reduction in the computational complexity of cryptographic algorithm somehow

3

compromises the privacy of mobile users. Hsueh et al. in [24] proposed a framework for secure cloud storage service for the mobile users. The proposed framework uses the standard cryptographic function, digital signatures, and cryptographic hash function for providing confidentially, authentication, and integrity services for the mobile user in cloud environment. However, the proposed framework overlooked resource limitation of the mobile device. The entire security operations, such as execution of encryption, decryption, integrity verification, and digital signature generation, are executed using the limited computational power of the mobile device. In 1998, the authors in [30] introduced an atomic re-encryption scheme based on El-Gamal cryptosystem [31] in which the idea of re-encryption was introduced. In re-encryption, the ciphertext encrypted with user ‘A’ public key can be transformed into a ciphertext encrypted with ‘B’ public key without ever learning the plaintext. Therefore, most of the existing security schemes based on [30] can offload the data access operation on trusted entity called proxy/manager or cloud. For mobile cloud computing environment, Jia et al. in [26] and Zhou et al. [29] proposed data security schemes based on the concept of re-encryption for offloading the data access operation on cloud without revealing the data content and security keys. Similarly, the authors in [27] proposed a scheme for securing the cloud storage services for the mobile users by offloading the computational intensive data access operation on the trusted-third party by using the concept of proxy re-encryption. Furthermore, the authors in [28] proposed manager-based re-encryption and cloud-based re-encryption schemes for securing the data partition on cloud storage with minimum processing overhead on the mobile device. Therefore, proxy re-encryption is very useful for offloading the computational intensive data access operations on cloud/third-party in mobile cloud computing environment. To the best of our knowledge, so far there is only one security scheme discussed in [25] which uses the concept of incremental cryptographic specifically for the mobile cloud computing environment. The authors in [25] proposed a light-weight framework for ensuring the integrity of the mobile user’s data uploaded on the cloud storage using the incremental cryptographic concept [32-34]. To make the framework suitable for the mobile device, most of the integrity verification jobs are offloaded on trusted entity and cloud. However, the security of the mobile user’s data is overlooked in the proposed framework. In this paper, we have defined the proxy re-encryption scheme which is based on atomic reencryption scheme [30]. Moreover, we introduced an incremental version of the proxy reencryption scheme for improving the file modification operation while providing the confidentiality services using the concept of the incremental cryptographic discussed in [25]. In proxy re-encryption scheme, a trusted entity called proxy provides re-encryption services to the associated users. The main operations involved in the proxy re-encryption scheme can be defined as: Setup: The proxy re-encryption scheme works on two groups G1 and G2 of prime order q with a bilinear map e: G1 × G1 → G2 having the properties of bilinearity, computability, and nondegeneracy [35]. The system parameters, such as g ∈ G1 and Z = e (g, g) ∈ G2 are randomly generated that are used for encryption, decryption, and re-encryption of the message. Key generation: In key generation phase, the proxy generates and disseminates public and private keys information to each authorized user of the data partition on the cloud storage using the following procedure:

SKi  xi PK i  g

xi

*

xi  Z q

(1)

Encryption: Let say user ‘A’ wants to upload message M on the data partition of cloud. The user ‘A’ generates random number r ∈ Zq* and encrypts the message using the personal private key as shown below:

4

CA  g

xAr

,C  M.Z

r

(2)

Re-encryption: If mobile user ‘B’ wants to download the uploaded file of mobile user ‘A’, the mobile user ‘B’ requests trusted entity called proxy for re-encryption. The trusted entity checks the access control list to verify the access rights of the mobile user ‘B’. If mobile user ‘B’ has access right for the requested file, the trusted entity downloads and re-encrypts the uploaded message using the ‘CA’ as shown below:

 x r xxB  A A CB  e  g , g  

 rx B r  rx B   eg , g   Z , C  M . Z 

(3)

The trusted entity transfers re-encrypted message (C, CB) to the mobile user ‘B’ for decryption of the message. Decryption: The mobile user ‘B’ decrypts the message using the ‘CB’ and personal private key as shown below:

Z 

1 xB r x B

 1   rx B *   xB 

 Z 

 M .Z r M   Zr 

Z

(4)

r

   

(5)

Although aforementioned re-encryption schemes offload the computationally intensive data access operations on the cloud; however mobile user has to perform computationally intensive encryption and decryption operation. In case of file modification on the cloud storage, the data owner needs to encrypt and upload the modified file on the cloud storage without considering the updated portion of the file.

3. Incremental Proxy Re-encryption Scheme for Mobile Cloud Computing Environment The proposed scheme uses the concept of incremental cryptographic covered in [25] for improving the file modification operations of proxy re-encryption scheme in terms of communication and processing overhead on mobile device. The system model of proposed scheme is shown in Figure 3. Cloud Client Application Cloud Service Provider

Mobile User A

Internet

Cloud Client Application

Mobile User B

Figure 3: System model of incremental proxy re-encryption scheme for mobile cloud computing environment

5

The incremental proxy re-encryption scheme can be defined as: Setup: The proposed scheme works on two groups G1 and G2 of prime order q with a bilinear map e: G1 × G1 → G2 having the properties of bilinearity, computability, and non-degeneracy [35]. The system parameters, such as g ∈ G1 and Z = e (g, g) ∈ G2 are randomly generated that are used for encryption, decryption, and re-encryption of the message. Key generation: In key generation phase, the trusted entity called proxy generates key pair for each authorized group member of the data partition ‘P’ on the cloud storage using the following procedure:

SKi  xi PK i  g

xi

*

xi  Z q

(6)

where the private key (xi ∈ Zq*) for ith group member is selected randomly and securely disseminated to each authorized group member of the data partition on the cloud. Encryption: Let say mobile user ‘A’ wants to upload file F on the data partition of cloud. To achieve the confidentiality, mobile user splits the file F into d blocks; each block has t chunks of equal size except last part (depending on the file size and number of blocks). The division of the file F should satisfy the following three equalities:

F  ||i1 Bi 

(7)

 FS  BS j    , where 1  j  (d  1)  d 

(8)

  FS   BS d  FS       (d  1)    d  

(9)

d

where FS denotes the size of file F, Bi represents the ith block of file F, BSj represents the jth block size of file F, and  is the representation of mathematical floor function to remove the fraction part. To encrypt each block (Bi ∈ G2), the mobile user ‘A’ generates random number r ∈ Zq* and encrypts the message using the personal private key as shown below:

CA  g

x Ar

r

, Ci  Bi . Z where 1  i  d

C  ||i1 Ci  where 1  i  d d

(10) (11)

Similarly, the message authentication code for each block of F is generated using cryptographic hash function. Subsequently, the generated message authentication codes are concatenated and cryptographic hash function is applied to get the final message authentication code for verifying the integrity of the uploaded file using the following procedure. MACi  H SHA2 Bi where 1  i  d (12)





MAC final  H SHA2 ||i1 MACi  where 1  i  d d

(13)

File name along with total number of blocks represented with ‘d’ for that file is stored on local storage of mobile device. The encrypted file (C, CA), message authentication code for each block (MACi), the value of ‘d’, and final message authentication code (MACfinal) are uploaded on the data partition of cloud. Mobile user keeps the information of file name and total number of blocks for each uploaded file on local storage of mobile device. Re-encryption: If mobile user ‘B’ wants to download the uploaded file of mobile user ‘A’, the mobile user ‘B’ requests trusted entity called proxy for re-encryption. The trusted entity checks the access control list to verify the access rights of the mobile user ‘B’. If mobile user ‘B’ has access right for the requested file, the trusted entity downloads and re-encrypts the uploaded message using the ‘CA’ as shown below: xB   x Ar x A CB  e  g , g  

  rxB rxB r   eg , g   Z , Ci  Bi . Z 

(14)

6

The trusted entity transfers the re-encrypted message (C, CB), MACfinal, and the value of ‘d’ to the mobile user ‘B’ for decryption and integrity verification. Decryption: The mobile user ‘B’ decrypts the message using the ‘CB’ and personal private key as shown below:

Z 

1 xB r x B

1

 Z rxB * xB  Z r

 B .Z r Bi   i r  Z 

(15)

  where 1  i  d  

(16)

The mobile user ‘B’ performs the concatenation operations to get the original file and verifies the integrity of downloaded file using the following procedure:

F  ||id1 Bi  where 1  i  d

(17)

MACi  H SHA2 Bi where 1  i  d

(18)

MAC final  H SHA2 ||id1 MACi  where 1  i  d

(19)





The integrity of the file can be confirmed by comparing the calculated final MAC with the downloaded final MAC. The same value of final MACs confirms the integrity of the downloaded file. The block modification operations for the proposed scheme can be categorized into (a) block(s) insertion operation, (b) block(s) deletion operation, and (c) block(s) modification operation. Here, we assumed that the data owner performs complete block modification operations that can be defined as:

3.1. Block Insertion Operations Let say the mobile user ‘A’ (data owner) wants to insert the dinsert new blocks represented with (Binsert) in the uploaded file. The mobile user downloads encrypted file (C, CA), and message authentication code of each block (MACi) from the cloud storage. The value of CA is used for the encryption of the new blocks as shown below: 1 1     1 x A   x Ar xA  r  x Ar * C , g  g , g  A     g , g  xA  Z    

(20)

r

Cinsert i  Binsert i . Z where 1  i  dinsert

(21)

Afterwards, the mobile user updates the message authentication codes for new inserted blocks and final message authentication code using the following procedure:

MACinserti  H SHA2 ( Binserti ) where 1  i  dinsert



dinsert

loc

d

MAC final  H SHA2 || i1MACi || j 1 MACinsert j || k loc1MACk



(22) (23)

‘loc’ is the representation of a location where mobile user wants to insert new block(s). The mobile user ‘A’ sends the update request to cloud service provider along with the updated message authentication codes for each new block (MACinsert), final message authentication code (MACfinal), location information (loc), and new encrypted blocks Cinsert. The cloud services provider inserts the block(s) into the corresponding file and updates the message authentication codes using the following procedure: dinsert

loc

d

MAC  || i1MACi || j 1 MACinsert j || k loc1MACk loc

dinsert

d

C  || i1Ci || j 1 Cinsert j || k loc1Ck

(24) (25)

The value of final message authentication code is also updated on cloud storage and the value of d is updated on the cloud and mobile device as d = d + dinsert for the corresponding

7

file. The block(s) insertion operation can be performed at multiple location of the uploaded file as shown in the algorithm 1. Algorithm 1: Block(s) Insertion Operation on Multiple Location of File Require: dnew contians multiple blocks insertion requests in the form {loc, bmod} Data: Binsert, Cinsert, Zr, MAC /*All elements are discussed above*/ /* d : total blocks of the file loc : location(s) where user wants to insert block(s) bmod : total blocks that user wants to insert at loc ∥: represents is a string concatenation operation */ SET i to one SET Cupdate to ‘ ’ /*updated encrypted file*/ SET MACupdate to ‘ ’ /* updated MAC codes*/ Cinsert ← encrypt(Binsert , Zr) ; /*encrypted form of new blocks*/ i

i

MACinsert ← HMAC(Binsert ); /*MAC for new blocks*/ i

i

FOR each e in dnew do

WHILE i ≤ e.loc Cupdate ← Cupdate ∥ Ci ; MACupdate ← MACupdate ∥ MACi; INCREMENT i ; END WHILE SET j to One WHILE j ≤ e. bmod Cupdate ← Cupdate ∥ Cinsert ; j

MACupdate ← MACupdate ∥ MACinsert ; j

INCREMENT j ; END WHILE WHILE i ≤ d Cupdate ← Cupdate ∥ Ci ; MACupdate ← MACupdate ∥ MACi ; INCREMENT i ; END WHILE d ← d + bmod ; END FOR

3.2. Block Deletion Operations Let the mobile user ‘A’ (data owner) wants to delete ddelete existing block(s) at location ‘loc’ in the uploaded file. The mobile user downloads the message authentication code of each block (MACi) of the corresponding file from the cloud storage. For deletion of the block(s) from the uploaded file, the mobile user updates the final message authentication code by performing the cryptographic hash function on the concatenation of the hash value of the remaining blocks as shown below:



loc

d

MAC final  H SHA2 || i1MACi || k loc1ddelete MACk



(26)

The mobile user ‘A’ sends the delete request to cloud service provider along with the updated final message authentication codes, location information (loc), and number of blocks information (ddelete) that mobile user wants to delete. The cloud services provider deletes the block(s) into the corresponding file and updates the message authentication codes using the following procedure: loc

d

MAC  || i1MACi || k loc1ddelete MAC k loc

d

C  || i1Ci |||k loc1ddelete Ck

(27) (28)

The value of final message authentication code is also updated on cloud storage, and the value of d is updated on the cloud and mobile device as d = d - ddelete for the corresponding file. Similarly, the block(s) deletion operation can be performed at multiple location of the uploaded file as shown in the algorithm 2. Algorithm 2: Block(s) Deletion Operation on Multiple Location of File Require: dnew contians multiple blocks deletion requests in the form {loc, bmod} Data: Zr, MAC /*All elements are discussed above*/

8

/* d : total blocks of the file loc : location(s) where user wants to delete block(s) bmod : total blocks that user wants to delete from loc onward ∥: represents is a string concatenation operation */ SET i to one SET Cupdate to ‘ ’ /*updated encrypted file*/ SET MACupdate to ‘ ’ /* updated MAC codes*/ FOR each e in dnew do WHILE i ≤ e.loc Cupdate ← Cupdate ∥ Ci ; MACupdate ← MACupdate ∥ MACi; INCREMENT i ; END WHILE i ← e.loc + e.bmod + 1; WHILE i ≤ d Cupdate ← Cupdate ∥ Ci ; MACupdate ← MACupdate ∥ MACi ; INCREMENT i ; END WHILE d ← d ‒ bmod ; END FOR

3.3. Block Modification Operations Let the mobile user ‘A’ (data owner) wants to update dmodify blocks represented with (Bmodify) in the uploaded file. The mobile user downloads encrypted file (C, CA) and message authentication code of each block (MACi) from the cloud storage. The value of downloaded CA is used for encryption of the updated blocks as shown below: 1 1     1 x A   x Ar xA  r  x Ar * C , g  g , g  A     g , g  xA  Z     r

Cmodifyi  Bmodifyi . Z where 1  i  d modify

(29) (30)

Afterwards, the mobile user updates the message authentication codes for updated blocks and final message authentication code using the following procedure:

MACmodifyi  H SHA2 ( Bmodifyi ) where 1  i  d modify

(31)

d modify loc d MAC final  H SHA2  || i 1MACi || j 1 MACupdate j || k loc1MAC k   

(32)

‘loc’ is the representation of a location where mobile user wants to update block(s). The mobile user ‘A’ sends the update request to cloud service provider along with the updated message authentication codes for each update block (MACmodify), final message authentication code (MACfinal), location information (loc), updated encrypted blocks Cupdate, and total number of updated block(s) (dmodify). The cloud services provider updates the block(s) and message authentication codes using the following procedure: dmodify

loc

d

MAC || i1MACi || j 1 MAC modify j || k loc1MAC k loc

d modify

d

C || i1Ci || j 1 Cmodify j || k loc1Ck

(33) (34)

The value of final message authentication code is also updated on cloud storage, and the value of d remains same on cloud and mobile device for the corresponding file. Likewise, the block(s) modification operation can be performed at multiple location of the uploaded file as shown in the algorithm 3. Algorithm 3: Block(s) Modification Operation on Multiple Location of File Require: dnew contians multiple blocks modification requests in the form {loc, bmod} Data: Bmodify, Cmodify, Zr, MAC /*All elements are discussed above*/ /* d : total blocks of the file

9

loc : location(s) where user wants to update block(s) bmod : total blocks that user wants to update at loc onward ∥: represents is a string concatenation operation */ SET i to one SET Cupdate to ‘ ’ /*updated encrypted file*/ SET MACupdate to ‘ ’ /* updated MAC codes*/ Cmodify ← encrypt(Bmodify , Zr) ; /*encrypted form of update blocks*/ i

i

MACmodify ← HMAC(Bmodify ); /*MAC for updated blocks*/ i

i

FOR each e in dnew do WHILE i ≤ e.loc Cupdate ← Cupdate ∥ Ci ; MACupdate ← MACupdate ∥ MACi; INCREMENT i ; END WHILE SET j to One WHILE j ≤ e. bmod Cupdate ← Cupdate ∥ Cmodify ; j

MACupdate ← MACupdate ∥ MACmodify ; j

INCREMENT j ; END WHILE WHILE i ≤ d Cupdate ← Cupdate ∥ Ci ; MACupdate ← MACupdate ∥ MACi ; INCREMENT i ; END WHILE END FOR

By analyzing the working of PReS and I-PReS, this can be concluded that the involvement of the additional file partitioning operations and cryptographic hash functions in I-PReS increases the resource utilization and response time on mobile device as compared to the PReS, however the encryption procedure adopted in I-PReS improves the response time and resource utilization on mobile device while performing the block modification operations on the uploaded files.

4. Results and Discussion The schemes are evaluated on the basis of turnaround time in seconds, energy consumption in percentage, CPU utilization in percentage, and memory consumption in kilobytes on the mobile device while performing encryption, decryption, block(s) insertion, block(s) deletion, and block(s) modification operations on the dataset given in Table I. For the development of the cloud client application, we have used android SDK that provides the library and tools for development, testing, and debugging of the mobile application. The cloud client application is deployed on Sony Xperia S smartphone having the specification given in Table II. A single front-end web instant of class F4 is hosted on Google App Engine (GAE) having 2.4 GHz processing and 512 MB RAM capabilities [36]. The cloud client application communicates with the web instant hosted on GAE for Google Cloud Storage [8] services. Moreover, the cloud client application uses http post method to request the hosted web instant for the file modification stored on Google Cloud Storage. Table I: Dataset used for the experiments No. 1 2 3 4 5

File Size in Bytes 51200 102400 153600 204800 256000

Total Files 50 50 50 50 50

Total Operations 40000 80000 120000 160000 200000

The cloud client application uses the java Pairing Based Cryptography library (jPBL) [30, 37] for encryption of the files. Type A pairing is construed on curve y2=x3+x on a prime field Fq for a prime number q of 512 bits. Maximum 64 bytes data block can be encrypted at any given

10

time due to the size of prime field Fq. Therefore, total number of multiplication operations (B . Zr) during encryption and division operation ((B . Zr)/Zr) during decryption can be calculated and given in Table I. To ensure the integrity of the uploaded file on cloud storage, the cryptographic hash function SHA-2 is used. Each experiment has been repeated ten times under the same system configuration and the average results are presented in the graphs and tables. Table II: Hardware specification of Sony Xperia S smartphone Sony Xperia S CPU RAM Storage OS Mobile Application Development Toolkit Battery Internet Connectivity

Dual-core 1.5 GHz 1 GB 32 GB Android OS v4.0.4 Android SDK 1750 mAh Wi-Fi

Experiment I: Turnaround time and energy consumption while encrypting/decrypting and uploading/downloading given dataset In this experiment, we have investigated the turnaround time and energy consumption on mobile device while encryption/decrypting and uploading/downloading the dataset given in Table I for PReS and I-PReS. The turnaround time and energy consumption can be evaluated as:

Total Turnaround Time (TTT )  t fr  ted  tud

(35)

where tfr refers to the time required for file reading, ted represents the encryption/decryption time, and tud denotes the uploading/downloading time. Similarly, energy consumption can be evaluated as:

Total Energy Consumed (TEC )  Ecomm  E fr  Eed

(36)

where Ecomm refers to the energy consumption in communication, Efr represents the energy consumption in file reading, Eed denotes the energy consumption in encryption/decryption operations. Figures 4 and 5 show the turnaround time and energy consumption on the mobile device while encryption and uploading the given dataset on the cloud storage. The xaxis of the graphs shows the file size in bytes along with the total number of files and y-axis shown the energy consumption in percentage and turnaround time in seconds.

11

400

4.00 3.00 2.00

4.33 4.67

5.00

3.33 3.67

6.67 7.00

741.52 820.40

7.00 6.00

200

I-PReS

8.00

1.67 2.33

600

317.31 362.72

800

505.77 526.57

1000

650.30 677.76

1200

PReS

5.67 6.33

I-PReS 968.85 990.81

PReS

1.00

0

0.00

Figure 4: Turnaround time while encrypting and uploading the dataset

Figure 5: Energy consumption while encrypting and uploading the dataset

The experimental results show that the proposed I-PReS takes more time and consumes more energy on the mobile device for completing encryption and uploading operations on the given dataset. In I-PReS, the mobile user needs to divides the file into blocks, encrypts each block, performs the cryptographic hash functions on each block, generates final message authentication code, combines the encrypted block, and uploads on the cloud storage. However, the operations involve in PReS are encryption of the file and uploading of the encrypted file on cloud storage. Therefore, due to the involvement of the addition operations, I-PReS completes the encryption and uploading of given dataset in more time with more energy consumption on mobile device as compared to PReS. However, the procedure adopted in I-PReS for encryption significantly improves the file modification operations in terms of turnaround time and energy consumption. Similarly, Figure 6 and Figure 7 show same behavior for downloading and decrypting the given dataset.

Figure 6: Turnaround time while downloading and decrypting the dataset

I-PReS

4.67 5.33

7.00

3.00 2.00

1.33 2.00

4.00

2.67 2.83

5.00

3.33 3.67

6.00

5.67 6.33

PReS 818.26 857.51

662.68 732.71

I-PReS

542.86 571.39

480.75 491.77

1000 900 800 700 600 500 400 300 200 100 0

274.69 328.71

PReS

1.00 0.00

Figure 7: Energy consumption while downloading and decrypting the dataset

Experiment II: Turnaround time and energy consumption while encrypting the dataset In this experiment, we have investigated the turnaround time and energy consumption on mobile device while performing the core encryption operation on the given dataset for PReS

12

and I-PReS. Due to the inconsistence behavior of network, we cannot conclude the results obtained in experiment-I. Therefore, this experiment is carried out for the confirmation of the experiment-I, in which communication overhead is excluded from the obtained results. The turnaround time and energy consumption can be evaluated as:

Total Turnaround Time (TTT )  t fr  ted

(37)

Similarly, the energy consumption can be evaluated using the following equation:

Total Energy Consumed (TEC )  E fr  Eed

(38)

Figure 8 and Figure 9 show turnaround time and energy consumption while encrypting the given dataset for I-PReS and PReS. As I-PReS divides the file into multiple blocks, therefore the experiments are performed by varying the total number of blocks for each file. The bar in the graphs for I-PReS(8), I-PReS(64), I-PReS(128), and I-PReS(256) represent the results of the I-PReS with 8, 64, 128, and 256 blocks, respectively.

I-PReS(64)

I-PReS(128)

250

118.97 120.90 121.20 121.63 122.45

200

100

71.38 72.86 73.25 73.48 74.26

150

169.77 172.11 172.50 172.98 173.50

300

I-PReS(256) 271.60 275.64 275.89 276.19 276.82

I-PReS(8)

223.33 226.80 227.05 227.47 228.18

PReS

50 0

Figure 8: Turnaround time while encrypting the dataset

I-PReS(10)

I-PReS(64)

I-PReS(128)

1

0.6667 0.6805 0.6841 0.6862 0.6935

1.3333 1.3517 1.3548 1.3585 1.3626

2

1.0000 1.0162 1.0188 1.0224 1.0292

2

1.6667 1.6926 1.6944 1.6976 1.7029

3

I-PReS(256) 2.0000 2.0297 2.0315 2.0337 2.0384

PReS

1 0

Figure 9: Energy consumption while encrypting the dataset

13

The main objective of this experiment is to investigate how variable number of blocks effects the turnaround time and energy consumption on the mobile device for I-PReS. The experimental results show that the I-PReS completes the encryption request on the given dataset with more time and more energy consumption on mobile device. The total number of multiplication operations (B . Zr) required for encryption are almost same in I-PReS and PReS, however the involvement of the additional cryptographic hash function in I-PReS increases the turnaround time and energy consumption on mobile device as compared to PReS.

4.1. CPU and Memory Utilization In this experiment, we have evaluated the CPU utilization in percentage, private memory in kilobytes, and Proportional Set Size (PSS) memory in kilobytes while encrypting the 20 files of size 2506000 Bytes. The amount of memory that is released after the termination of a process is called private memory. The amount of memory that is shared among multiple processes is called PSS memory [38] and can be evaluated as: S  PSS   Mem  (39)  N  where ‘SMem’ is the representation of the shared memory among multiple running processes on the mobile device, and ‘N’ indicates the number of processes utilizing the shared memory. We have developed a mobile application for evaluating the resource utilization that executes the android top command [39] for every second to get the resources utilization information of each running process. Each experiment is repeated three times under same system configuration and average results are presented in the Table III. Table III: CPU utilization and memory consumption while encrypting 20 files of size 2506000 bytes PGReS: 20 File of Size 256000 bytes CPU (%) Time (Msecs) PM (KB) SM (KB) 56.00 108641.86 16930.22 23278.49 55.80 108593. 67 15276.84 21579.97 108344.58 54.45 16523.22 22532.11

I-PGReS: 20 File of Size 256000 bytes (8) CPU (%) Time (Msecs) PM (KB) SM (KB) 56.15 110256.53 16746.00 18772.35 55.10 110250.22 17502.38 19419.62 110252.44 55.82 17963.76 19877.76

55.42

55.69

108493.22

16243.42

22463.52

110253.0633

17404.05

19356.57

I-PGReS: 20 File of Size 256000 bytes (64) CPU (%) Time (Msecs) PM (KB) SM (KB) 57.05 110355.33 17500.65 18523.22 57.11 110370.73 17443.66 18542.22 56.53 110300.54 17554.74 18697.22

I-PGReS: 20 File of Size 256000 bytes (128) CPU (%) Time (Msecs) PM (KB) SM (KB) 58.15 110474.93 17604.65 18566.22 58.11 110469.21 17599.72 18569.92 58.83 110481.33 17636.00 19785.67

56.90

58.36

110342.2

17499.68

18587.55

110475.1567

17613.46

18973.93

I-PGReS: 20 File of Size 256000 bytes (256) CPU (%) Time (Msecs) PM (KB) SM (KB) 59.15 110727.33 17800.31 19866.91 59.17 110831.47 17663.22 18967.18 59.83 110885.94 17888.33 19856.32 59.38

110814.9133 17783.95 PM: Private Memory

19563.47 SM: Shared Memory

MSecs: Milliseconds

The results presented in Table II show that increase in the cryptographic hash function for IPReS also increases the CPU utilization and memory consumption on the mobile device. The important parameter that need to be considered is the time to which the CPU and memory is kept busy. The measurement obtained from the experiment confirms that the I-PReS consumes marginally more resources and takes slightly more time to complete the request

14

as compared to PReS, however the procedure adopted in I-PReS for encryption significantly improves the file modification operations in terms of response time and energy consumption on the mobile device as compared to PReS.

4.2. Block Modification Operation In this experiment, we have investigated the turnaround time and energy consumption while performing block insertion, deletion, and modification operations on uploaded file. The energy consumption and turnaround time for I-PReS is evaluated as: Total Turnaround Time (TTT )  t fr  tbe  tbu (40) where tfr refers to the time required for file reading, tbe represents the block(s) encryption time, and tbu denotes the block uploading time. Similarly, energy consumption can be evaluated as: Total Energy Consumed (TEC )  Ebu  E fr  Ebe (41) where Ebu refers to the energy consumption in block(s) uploading, Efr represents the energy consumption in file reading, Ebe denotes the energy consumption in encrypting the block(s). Figure 10 and Figure 11 show turnaround time and energy consumption while performing the block(s) modification operations on the given dataset for I-PReS and PReS. In the experimental setup, each file of the given data set is divided into eight blocks and the bars in the graphs for I-PReS(6), I-PReS(5), I-PReS(4), I-PReS(3), I-PReS(2), and I-PReS(1) represent the results of the I-PReS with 6, 5, 4, 3, 2, and 1 blocks modification operations, respectively. I-PReS(6)

I-PReS(5)

I-PReS(4)

I-PReS(3)

I-PReS(2) 968.85

1200

317.31 272.25 226.88 181.51 136.14 90.77 45.40

505.77 396.54 330.49 264.44 198.39 132.33 66.28

650.30 510.28 425.28 340.28 255.28 170.28 85.28

741.52 618.34 515.35 412.37 309.38 206.40 103.42

1000

51200×50

102400×50

153600×50

204800×50

800

600

400

200

I-PReS(1)

731.64 609.78 487.92 366.07 244.21 122.36

PReS

0 256000×50

Figure 10: Turnaround time while performing block(s) modification/insertion operation on the dataset

In I-PReS, the data owner needs to only encrypt the modified block(s), generates the message authentication code(s) for modified block(s), updates the final message authentication code, and transfers the modified block(s) along with the corresponding message authentication code(s) to the web instant hosted on GAE. The hosted web instant receives the block modification request and updates the corresponding file along with the message authentication code. Alternatively, PReS encrypts and transfers the complete file to the hosted web instant on GAE without considering how much file has been modified. Due to communication and processing overhead, PReS takes more time and consumes more energy on the mobile device as compared I-PReS while performing the block modification operations on the given dataset.

15

I-PReS(6)

I-PReS(5)

I-PReS(4)

I-PReS(3)

3.3333 2.7613 2.3013 1.8414 1.3814 0.9215 0.4616

4.3333 3.5135 2.9283 2.3430 1.7577 1.1725 0.5872

51200×50

102400×50

153600×50

5 4

2 1

I-PReS(1)

5.2755 4.3968 3.5182 2.6396 1.7609 0.8823

1.6667 1.5270 1.4935 1.3949 1.2562 0.9176 0.4589

6

5.6667 4.7734 3.9784 3.1834 2.3884 1.5934 0.7984

7

3

I-PReS(2) 6.6667

PReS

0 204800×50

256000×50

Figure 11: Energy consumption while performing block(s) modification/insertion operation on the dataset

The operations involved in block(s) insertion and modification are almost same, therefore the turnaround time and energy consumption is almost identical. Moreover, in block deletion operation(s), the data owner transfer the block deletion request to the web instant hosted on GAE the contain location information, number of blocks that mobile user wants to delete, and the updated final message authentication code. On reception of the request, the hosted web instant deletes the block(s) along with the corresponding message authentication code and updates the final message authentication code. The main operation that needs to be performed on mobile device during block deletion operation is cryptographic hash function. Figure 12 shows that the time in milliseconds consumed in performing the cryptographic hash function on the given dataset when a file is partition into 8 blocks. 4500 4000 3500 3000 2500 2000 1500 1000 500 0 51200×50 102400×50 153600×50 204800×50 256000×50

Figure 12: Turnaround time while performing block(s) deletion operation the dataset in I-PReS

In PReS, the mobile user needs to encrypt and transfer the entire file after deleting the block(s) to the web instant hosted on GAE. By analysis Figure 8 and Figure 12, it can be concluded that I-PReS completes the block(s) deletion operations much faster with minimum resource consumption on the mobile device as compared to PReS.

4.3. Security Analysis Pairing-based cryptographic operations are implemented by using the java Pairing Based Cryptography library (jPBL) [30, 37]. We assume a Type A pairing construed on curve y2=x3+x on a prime field Fq for a prime number q of 512 bits. For secure cryptosystem, the value of q

16

should be large to keep maximum points on the elliptic curve. According to Standards for Efficient Cryptography [40], the recommend value of q is 112-521 bits. In PReS and I-PReS, at any given time maximum 64 bytes of data block can be encrypted time due to the size of prime field Fq. Moreover, the same of value of q (i.e. 512 bits) is used for PReS and I-PReS that provide same level of security. As PReS and I-PReS are based on well-known atomic BBS reencryption whose security is well-proven and can be found in [30]. Therefore, we will limit our discussion on the verification of the proposed schemes using formal methods.

4.4. Formal Analysis and Verification The verification process is used for ensuring the correctness of the proposed system. The bounded model checking is used to ensure that the system terminates after finite number of states for any input. The bounded model checking contains (a) rules/properties of the system, (b) model representation of the system, and (c) verification tool for ensuing that the model holds the specified properties[41, 42]. In this paper, we use bounded model checking to verify proposed I-PReS. The High Level Petri Net (HLPN) representation of the I-PReS is depicted in Figure 13. For development of petri net model, we have identified data types, places, and mappings of data types to places. Table IV and Table V show the data types and mappings, respectively. In HLPN model, the rectangular black boxes are the representation of transitions that belong to set T. The circles are places and belong to set P.

X18

Dec_M

Rk Key_Gen B_Delete X17

X21

X1

X19

X20

Enc_M

X28

X27

X2

X10 X9

X15 Req_CB_S

X14

X16 X13

Proxy

X7

User

Cloud

X11 X8

X12 Req_CB_F

X4

X3

Split_F X24

X23 X6

X22 X21 Send_keys

X5

X25

B_Insert

Gen_r_Z

Cmb_msg

X26

B_Modify

Figure 13: HLPN model for I-PReS Table IV: Data types for I-PReS Data Type g Z Ui

Description Number belonging to group G1 of prime order q A number, e(g, g) belonging to group G2 A number identifying user i

17

Pi SKi PKi Bi

A number identifying partition i over cloud Secret key of user i Public key of user i

MACi Bnew MACnew Cnew MACfinal r C Ci

Hash value of Bi New blocks that user wants to update Hash value of Bnew Encrypted form of new blocks Final hash value H( H(B1) || H(B1) || H(B1)….|| H(Bd)) A random number Encrypted F

d

( )

String representing ith chunk of bytes from F, such that, F =|| i =1 Bi

d

( )

Encrypted form of Bi, such that C =||i =1 Ci . rx

CA

Number representing g

RKA⟶B CB

Re-encryption key from user A to B Number representing ZrxB

d F ddel

Number representing total blocks of file A file that is to be encrypted Number representing deleting blcoks

A

Table V: Places and mappings used in HLPN model of I-PReS Place (Proxy)

Mapping ℙ(Pi×Ui×SKi×PKi×g×Z×CA × CB × RKA⟶B×r)

(User) (Cloud) (RK)

ℙ(Pi×Ui×SKi×PKi×Z×r×F×Bi×C×Ci×MACi ×MACfinal×d×Cnew×Bnew×MACnew×ddel) ℙ (Pi×Ui×C × MACi × MACfinal) ℙ (CB × C)

In this section we define formulas to map on transitions. The system starts with key generation and setup phase that generates public and private keys for each user belonging to data partition ‘P’ of the cloud. This is done by the starting transition Key_Gen in HLPN model. Following formula maps to the aforesaid transition:

R( Key _ Gen )  ∀x1 ∈ X 1 ,∀x2 ∈ X 2 | x2 [3] : Gen _ SK i ( x1[2]) ∧ x2 [4] : Gen _ PK i ( x1[2]) ∧ x2 [5] : Gen _ g ( x1[1])

(42)

X 1  X 1 ∪{x2 [3], x2 [4], x2 [5]} '

X 2  X 2 ∪{x2 [3], x2 [4], x2 [5]} '

Generated keys are then sent to the authorized users by transition Send_keys. The following rule shows the operation:

R( Send _ Keys )  ∀x3 ∈ X 3 ,∀x4 ∈ X 4 | x4 [1] : x3 [1]∧ x4 [2] : x3 [2]∧ x4 [3] : x3 [3]∧ x4 [4] : x3 [4]∧

(43)

X 4  X 4 ∪{x4 [1], x4 [2], x4 [3], x4 [4]} '

Parameter ‘r’ for user and system parameter Z is generated by following transition and associates rule:

R(Gen _ r _ z )  ∀x5 ∈ X 5 ,∀x6 ∈ X 6 | x6 [5] : Gen _ z ( x5 [1]) ∧ x6 [6] : Gen _ r ( x5 [1]) ∧

(44)

X 6  X 6 ∪{x6 [5], x6 [6]} '

18

The user that wants to upload the data to the cloud divides the file into multiple portions according to the parameters given in detail of I-PReS. Following rule over transition Split_F highlights the process:

R( Split _ F )  ∀x7 ∈ X 7 ,∀x8 ∈ X 8 | x8 [8] : split _ file( x7 [7], x7 [13]) ∧

(45)

X 8  X 8 ∪{x8 [8]} '

The mobile user encrypts the data and generates the corresponding message authentication codes according to given encryption rule and sends it to the cloud. This is done at transition ENC_M and following formula represents it:

R( ENC _ M )  ∀x9 ∈ X 9 ,∀x10 ∈ X 10 | x10 [1] : x9 [1]∧ x10 [2] : x9 [2]∧ x10 [10] : encrypt ( x9 [8], x9 [5], x9 [6]) ∧ x10 [9] : concat ( x10 [10]) ∧ x10 [11] : gen _ mac ( x9 [8]) ∧

(46)

x10 [12] : concat ( x10 [11]) ∧ X 10  X 10 ∪{x10 [1], x10 [2], x10 [9] x10 [10] x10 [11] x10 [12]} '

With this the process of encryption and uploading to the cloud is completed. If any user (Let say user ‘B’) wants to download and decrypt the data, the user ‘B’ requests for CB from manager. The manager checks the access control list for the requesting user. If requesting user is not in access control list, the request for CB fails that is depicted in the following rule:

R(Re q _ C B _ F )  ∀x11 ∈ X 11 ,∀x12 ∈ X 12 ,∀x13 ∈ X 13 | x12 [1]  x11[1]∧ x12 [2]  x11[2]∧ X 12  X 12 '

(47)

X 13  X 13 '

If requesting user has access rights for the uploaded message, the manager calculates reencryption key and CB, and sends CB to user. This can be represented in the form of Req_CB_S (authentication successful) transitions:

R(Re q _ C B _ S )  ∀x14 ∈ X 14 , x15 ∈ X 15 ,∀x16 ∈ X 16 ,∀x17 ∈ X 17 | x15 [1]  x14 [1]∧ x15 [2]  x14 [2]∧ X 15  X 15 ∧ X 17  X 17 ∧ '

'

∀x18 ∈ X 18 |

(48)

x17 [1] : x16 [8]∧ x18 [2] : prod ( x14 [8], power ( x14 [5], prod ( x14 [3], x14 [6]))) ∧ X 18  X 18 ∪{x18 [1], x18 [2]} '

After receiving CB, user transforms the encrypted portion of the message into plain text. This is done at transition Dec_M with following rule:

R( Decr _ CMobile )  ∀x18 ∈ X 18 ,∀x19 ∈ X 19 ,∀x20 ∈ X 20 ,∀x21 ∈ X 21 | x19 [8] : decrypt ( x21[10], x18 [1], x19 [2]∧

(49)

X 19  X 19 ∪{x19 } '

After decryption, the blocks are concatenated with following transition and rule:

19

R(Cmb _ msg) = ∀x21 ∈ X 21 ,∀x22 ∈ X 22 | x22 [11] := gen _ ma c( x21[8]) ∧ x22 [12] := gen _ fma c( x22 [11]) ∧ x22 [7 ] := conca t( x21[10]) ∧

(50)

'

X 22 = X 22 ∪{ x22 [11], x22 [7 ]}

When mobile user wants to modify the file stored on cloud storage, the file modification is done through block insertion, deletion, and modification operation discussed above. The block modification request in represented with B_Insert, B_Modify, and B_Delete transitions and rules: R( B _ Insert )  ∀x23 ∈ X 23 ,∀x24 ∈ X 24 | x23 [14] : encrypt ( x23 [15], x23 [5], x23 [6]) ∧ x23 [9] : insert ( x24 [14]) ∧ x23 [16] : gen _ fmac( x23 [15]) ∧ x23 [12] : insert ( x24 [16]) ∧ x24 [3] : x23 [9]∧ x24 [4] : x23 [12]∧

(51)

X 23  X 23 ∪{x23 [4], x23 [6], x23 [9], x23 [16], x23 [12]} '

X 24  X 24 ∪{x24 [3], x24 [4]} '

R( B _ Modify)  ∀x25 ∈ X 25 ,∀x26 ∈ X 26 | x25 [14] : encrypt ( x25 [15], x25 [5], x25 [6]) ∧ x26 [3] : update( x25 [14]) ∧ x25 [16] : gen _ fmac( x25 [15]) ∧ x26 [4] : update( x24 [16]) ∧

(52)

X 25  X 25 ∪{x25 [14], x25 [16]} '

X 26  X 26 ∪{x26 [3], x26 [4]} '

R( B _ Delete )  ∀x27 ∈ X 27 ,∀x28 ∈ X 28 | x28 [3] : delete ( x27 [17]) ∧ x28 [4] : update( x28 [4], x27 [17]) ∧

(53)

X 28  X 28 ∪{x28 [3], x28 [4]} '

Verification property: The aim of verification was to ensure that the proposed system works according to the specifications and produces the results correctly. The following properties are verified:   

Encryption of the message by user is done correctly and as specified by the system. Decryption requests are handled correctly by the proxy and user, and after decryption user gets the original data that was uploaded by the data owner. After block modification operations, mobile user is capable to get the modified file correctly.

The above given model was translated to SMT-Lib and verified thorough Z3 solver. The solver showed that the model is workable and executes according to the specified properties. Z3 solver took 0.05 seconds to upload data of user after encryption, and download and decrypt for another user in the group.

5. Conclusion and Future Work In this paper, we have proposed an incremental proxy re-encryption scheme and compared with the existing proxy re-encryption scheme on the basis of turnaround time, energy consumption, CPU utilization, and memory allocation on the mobile device. Due to the involvement of additional file segmentation, blocks concatenation, and cryptographic hash

20

function, the proposed scheme provides confidentially and integrity services to mobile users with slightly more time and marginally more energy consumption on the mobile device as compared to PReS. However, I-PReS shows improvement in results while performing the block(s) insertion, deletion, and modification operation(s) as compared to the PReS. The improvement in results depends on the number of block(s) that the data owner wants to update. Table VI shows the result improvement of I-PReS in block(s) modification operation(s) as compared to PReS. Table VI: Summary of result improvement in block modification operation File Size × Total File I-PReS(6) I-PReS(5) I-PReS(4) I-PReS(3) I-PReS(2) I-PReS(1) Average

51200×50 14.20% 28.50% 42.80% 57.09% 71.39% 85.69% 49.95%

102400×50 21.60% 34.66% 47.71% 60.77% 73.83% 86.89% 54.24%

153600×50 21.53% 34.60% 47.67% 60.74% 73.81% 86.89% 54.21%

204800×50 16.61% 30.50% 44.39% 58.28% 72.17% 86.05% 51.33%

256000×50 24.48% 37.06% 49.64% 62.22% 74.79% 87.37% 55.93%

Modification 75.0% 62.5% 50.0% 37.5% 25.0% 12.5%

Average 19.68% 33.06% 46.44% 59.82% 73.20% 86.58%

The average results presented horizontally in the Table III show 50 to 56 percent collective improvement while performing the block(s) modification operation on the given dataset with 6, 5, 4, 3, 2, and 1 block(s) modification operations. The average results presented vertically in the Table III show individual percentage improvement in results while performing the block(s) modification operation on the given dataset with 6, 5, 4, 3, 2, and 1 block(s) modification operations. In the future, we aim to enhance the incremental proxy re-encryption scheme that can handle the file modification operation efficiently anywhere in the file.

ACKNOWLEDGEMENT We would like to acknowledge the financial support of the BrightSparks Program at University of Malaya, Malaysia for carrying out this research experiments.

References [1] A.N. Khan, M. Mat Kiah, S.U. Khan, S.A. Madani. Towards secure mobile cloud computing: a survey, Future Generation Computer Systems, 29 (2013) 1278–1299. [2] A.N. Khan, M. Mat Kiah, S.A. Madani, M. Ali. Enhanced dynamic credential generation scheme for protection of user identity in mobile-cloud computing, The Journal of Supercomputing, (2013) 1-20. [3] A. Khan, M. Othman, S. Madani, S. Khan. A Survey of Mobile Cloud Computing Application Models, IEEE Communications Surveys & Tutorials, PP (2013) 1 - 21 [4] A. Nathani, S. Chaudhary, G. Somani. Policy based resource allocation in IaaS cloud, Future Generation Computer Systems, 28 (2012) 94-103. [5] L. Wang, G. Von Laszewski, A. Younge, X. He, M. Kunze, J. Tao, C. Fu. Cloud computing: a perspective study, New Generation Computing, 28 (2010) 137-146. [6] J. Murty. Programming Amazon Web Services: S3, EC2, SQS, FPS, and SimpleDB: O'Reilly Media, Incorporated, 2008. [7] E.Y. Chen, M. Itoh. Virtual smartphone over IP, in: World of Wireless Mobile and Multimedia Networks (WoWMoM), 2010 IEEE International Symposium on a: IEEE, 2010, pp. 1-6. [8] Google Cloud Storage Java API Overview,August 15, 2012,https://developers.google.com/appengine/docs/java/googlestorage/overview [9] H.T. Dinh, C. Lee, D. Niyato, P. Wang. A survey of mobile cloud computing: architecture, applications, and approaches, Wireless Communications and Mobile Computing, (2011).

21

[10] Zip cloud,May 01, 2013,http://www.zipcloud.com/ [11] Crashplan,May 06, 2013,http://www.crashplan.com/ [12] S.M. Hashemi, M.R.M. Ardakani. Taxonomy of the Security Aspects of Cloud Computing Systems-A Survey, International Journal of Applied Information Systems, 4 (2012) 21-28. [13] Mobile cloud computing: $9.5 billion by 2014, Juniper, Technical Report (2010),April 24, 2013,http://www.juniperresearch.com/reports/mobile_cloud_applications_and_services [14] X. Zhang, J. Schiffman, S. Gibbs, A. Kunjithapatham, S. Jeong. Securing elastic applications on mobile devices for cloud computing, in: Proceedings of the 2009 ACM workshop on Cloud computing security: ACM, 2009, pp. 127-134. [15] S. Xiao, W. Gong. Mobility Can Help: Protect User Identity with Dynamic Credential, in: Mobile Data Management (MDM), 2010 Eleventh International Conference on: IEEE, 2010, pp. 378-380. [16] S. Wang, X.S. Wang. In-device spatial cloaking for mobile user privacy assisted by the cloud, in: Mobile Data Management (MDM), 2010 Eleventh International Conference on: IEEE, 2010, pp. 381-386. [17] R. Chow, M. Jakobsson, R. Masuoka, J. Molina, Y. Niu, E. Shi, Z. Song. Authentication in the clouds: a framework and its application to mobile users, in: Proceedings of the 2010 ACM workshop on Cloud computing security workshop: ACM, 2010, pp. 1-6. [18] D. Huang, X. Zhang, M. Kang, J. Luo. MobiCloud: building secure cloud framework for mobile computing and communication, in: Fifth IEEE International Symposium on Service Oriented System Engineering (SOSE '10): IEEE, 2010, pp. 27-34. [19] D. Huang, Z. Zhou, L. Xu, T. Xing, Y. Zhong. Secure data processing framework for mobile cloud computing, in: IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS '11): IEEE, 2011, pp. 614-618. [20] Y.J. Chen, L.C. Wang. A Security Framework of Group Location-Based Mobile Applications in Cloud Computing, in: 40th International Conference on Parallel Processing Workshops (ICPPW '11): IEEE, 2011, pp. 184-190. [21] I. Bilogrevic, M. Jadliwala, P. Kumar, S.S. Walia, J.P. Hubaux, I. Aad, V. Niemi. Meetings through the cloud: Privacy-preserving scheduling on mobile devices, Journal of Systems and Software, 84 (2011) 1910-1927. [22] X. Zhang, S. Jeong, A. Kunjithapatham, S. Gibbs. Towards an elastic application model for augmenting computing capabilities of mobile platforms, Mobile wireless middleware, operating systems, and applications, (2010) 161-174. [23] W. Ren, L. Yu, R. Gao, F. Xiong. Lightweight and Compromise Resilient Storage Outsourcing with Distributed Secure Accessibility in Mobile Cloud Computing, Tsinghua Science & Technology, 16 (2011) 520-528. [24] S.C. Hsueh, J.Y. Lin, M.Y. Lin. Secure cloud storage for convenient data archive of smart phones, in: IEEE 15th International Symposium on Consumer Electronics (ISCE '11) IEEE, 2011, pp. 156-161. [25] W. Itani, A. Kayssi, A. Chehab. Energy-efficient incremental integrity for securing storage in mobile cloud computing, in: International Conference on Energy Aware Computing (ICEAC '10) Cairo, Egypt IEEE, 2010, pp. 1-2. [26] W. Jia, H. Zhu, Z. Cao, L. Wei, X. Lin. SDSM: A secure data service mechanism in mobile cloud computing, in: IEEE Conference on Computer Communications Workshops (INFOCOM '11) Shanghai, China: IEEE, 2011, pp. 1060-1065. [27] J. Yang, H. Wang, J. Wang, C. Tan, D. Yu. Provable Data Possession of Resource-constrained Mobile Devices in Cloud Computing, Journal of Networks, 6 (2011) 1033-1040. [28] P.K. Tysowski, M.A. Hasan. Re-Encryption-Based Key Management Towards Secure and Scalable Mobile Applications in Clouds, IACR Cryptology ePrint Archive 668 (2011). [29] Z. Zhou, D. Huang. Efficient and secure data storage operations for mobile cloud computing, in: Cryptology ePrint Archive, 2011. [30] M. Blaze, G. Bleumer, M. Strauss. Divertible protocols and atomic proxy cryptography, in: K. Nyberg (Ed.) Advances in Cryptology — EUROCRYPT'98: Springer Berlin Heidelberg, 1998, pp. 127-144. [31] T. ElGamal. A public key cryptosystem and a signature scheme based on discrete logarithms, in: Advances in Cryptology: Springer, 1985, pp. 10-18. [32] M. Bellare, O. Goldreich, S. Goldwasser. Incremental cryptography: The case of hashing and signing, in: Advances in Cryptology—CRYPTO’94: Springer, 1994, pp. 216-233.

22

[33] M. Bellare, O. Goldreich, S. Goldwasser. Incremental cryptography and application to virus protection, in: Proceedings of the twenty-seventh annual ACM symposium on Theory of computing: ACM, 1995, pp. 45-56. [34] M. Bellare, D. Micciancio. A new paradigm for collision-free hashing: Incrementality at reduced cost, in: Advances in Cryptology—EUROCRYPT’97: Springer, 1997, pp. 163-192. [35] S. Yu, C. Wang, K. Ren, W. Lou. Achieving secure, scalable, and fine-grained data access control in cloud computing, in: Proceedings IEEE (INFOCOM '10) NJ, USA: IEEE, 2010, pp. 1-9. [36] Adjusting Application Performance,September 05, 2012,https://developers.google.com/appengine/docs/adminconsole/performancesettings [37] A. De Caro, V. Iovino. jPBC: Java pairing based cryptography, in: IEEE Symposium on Computers and Communications (ISCC '11) Kerkyra: IEEE, 2011, pp. 850-855. [38] Proportional Set Size,August 23, 2012,http://lwn.net/Articles/230975/ [39] Android Top Command To Get CPU Usage and Memory Usage,September 09, 2012,http://www.javachartingandroid.com/2011/04/android-top-command-to-get-cpu-usageand-memory-usage/ [40] Certicom, Standards for Efficient Cryptography, SEC 2: Recommended Elliptic Curve Domain Parameters, Version 1.0,September 2000, http://www.secg.org/download/aid386/sec2_final.pdf [41] T. Murata. Petri nets: Properties, analysis and applications, Proceedings of the IEEE, 77 (1989) 541-580. [42] L. de Moura, N. Bjørner. Satisfiability modulo theories: An appetizer, in: Formal Methods: Foundations and Applications: Springer, 2009, pp. 23-36.

23