Future Generation Computer Systems

(1)

Contents lists available atSciVerse ScienceDirect

Future Generation Computer Systems

journal homepage:www.elsevier.com/locate/fgcs

Towards secure mobile cloud computing: A survey

Abdul Nasir Khan

a,∗

,

M.L. Mat Kiah

a

,

Samee U. Khan

b

,

Sajjad A. Madani

c

a_{Faculty of Computer Science & Information Technology, University of Malaya, Malaysia} b_{Department of Electrical and Computer Engineering, North Dakota State University, USA} c_{Department of Computer Science, COMSATS Institute of Information Technology, Pakistan}

a r t i c l e i n f o

Article history: Received 5 January 2012 Received in revised form 16 July 2012

Accepted 11 August 2012 Available online 25 August 2012 Keywords:

Cloud computing Mobile cloud computing Virtualization Security Privacy

a b s t r a c t

Mobile cloud computing is gaining popularity among mobile users. The ABI Research predicts that the number of mobile cloud computing subscribers is expected to grow from 42.8 million (1.1% of total mobile users) in 2008 to 998 million (19% of total mobile users) in 2014. Despite the hype achieved by mobile cloud computing, the growth of mobile cloud computing subscribers is still below expectations. According to the recent survey conducted by the International Data Corporation, most IT Executives and CEOs are not interested in adopting such services due to the risks associated with security and privacy. The security threats have become a hurdle in the rapid adaptability of the mobile cloud computing paradigm. Significant efforts have been devoted in research organizations and academia to build secure mobile cloud computing environments and infrastructures. In spite of the efforts, there are a number of loopholes and challenges that still exist in the security policies of mobile cloud computing. This literature review: (a) highlights the current state of the art work proposed to secure mobile cloud computing infrastructures, (b) identifies the potential problems, and (c) provides a taxonomy of the state of the art.

1. Introduction

To have an in depth understanding of Mobile Cloud Computing

(

MCC

)

, it is necessary to get a complete grasp on cloud computing. Cloud computing provides a new computing paradigm that delivers IT as a service. The objectives of the new computing paradigm are to increase capacity and capabilities at runtime without investing in new infrastructure, licensing new software, and training new recruits. Cloud computing permits customers to utilize cloud services on the fly in pay-as-you-go manner [1,2] through the Internet. The services may be Infrastructure as a Service

(

IaaS

)

, Data storage as a Service

(

DaaS

)

, Communication as a Service

(

CaaS

)

, Security as a Service

(

SecaaS

)

, Hardware as a Service

(

HaaS

)

, Software as a Service

(

SaaS

)

, Business as a Service

(

BaaS

)

, and Platform as a Service

(

PaaS

)

. There are various layered architectures available for cloud computing to provide the aforementioned services as a utility [3–5]. One such cloud computing layered architecture is presented inFig. 1.

Cloud’s backbone layer consists of physical servers and switches. The cloud service provider is responsible to run, man-age, and upgrade cloud hardware resources according to the re-quirements of users. The backbone layer is also responsible to

∗_{Corresponding author. Tel.: +60 108124496; fax: +60 379579249.}

E-mail addresses:[email protected](A.N. Khan),[email protected] (M.L. Mat Kiah),[email protected](S.U. Khan),[email protected] (S.A. Madani).

allocate hardware resources to users in an efficient, quick, and smooth way. The supervisor software layer contains the system software to manage the cloud hardware resources. The system software permits application software to run and utilize under-lying resources in an efficient way. The various implementations of supervisor software include: (a) operating system, (b) hyper-visor, and (c) middleware. The operating system manages the computer hardware resources and provides an interface for inter-action of user and application software with hardware resources. The hypervisor is a system software that allows users to remotely create virtual machines on cloud server(s) at runtime. The virtual machine has user defined hardware specifications and a software stack. The virtualization process improves the availability of the user’s hosted services even in case of hardware failure. The virtual machine with the entire software stack can be migrated to another server with negligible unavailability of hosted services. Moreover, virtualization is also beneficial for cloud service providers. Because,

IT research firm ‘‘Infotech’’ estimates that the distributed

physi-cal servers without virtualization utilize only 20% of total capa-bilities. The virtualization process can boost hardware utilization

between 60% and 80% [6]. The middleware system software

man-ages the transparent execution and interaction among jobs run-ning on cloud servers. The software infrastructure layer hands over the network resources to upper layers and provides a foundation for a new computing paradigm that delivers IT as a service. The software infrastructure layer can be subdivided into three cate-gories: (a) IaaS, (b) DaaS, and (c) CaaS. IaaS [7] offers computational

(2)

Fig. 1. Layered architecture of cloud computing [6].

resources (e.g. servers) to the end users. For efficient utilization of resources, multiple virtual machines may be created on each server according to users’ demand. The examples of IaaS include Amazon Elastic Computing Cloud

(

EC 2

)

, Enomaly’s Elastic Computing Plat-form

(

ECP

)

[8], and Resources and Services Virtualization without Barriers

(

RESERVOIR

)

architecture [9]. DaaS allows users to store an enormous amount of data on remote server(s). The users can ac-cess the uploaded data immediately from any site having Internet connectivity. Simple Storage Service

(

Amazon S3

)

[10] and Zenter ZumoDrive [11] are the examples of DaaS. CaaS provides secure, re-liable, and fast communication services for the users. The platform infrastructure layer provides an application development platform and a set of Application Programming Interfaces

(

APIs

)

for the de-velopers. The developers use APIs to program applications that can interact and utilize the full power of the cloud resources. Google App Engine [12] and Salesforce.com’s Apex Code [13] are examples of PaaS. The topmost application layer allows users to access and use applications installed on a cloud provider’s data center through the Internet. Users can easily access such applications through a web client, even with limited processing and storage capabilities. Moreover, a cloud service provider can upgrade the applications without requiring the user to install any update or patch.

Cloud computing with resource constraint mobile devices, ubiquitous wireless infrastructure, mobile web, and location-based services provides a ground for a new computing paradigm called

MCC . Mobile devices being battery powered, have limited

pro-cessing power, low storage, less security, unpredictable Internet connectivity, and less energy. The aforementioned limitations of mobile devices are always obstacles for computationally intensive and storage demanding applications on a mobile. To augment the capability, capacity and battery time of the mobile devices, compu-tationally intensive and storage demanding jobs should be moved to cloud [14,15]. On the basis of the above discussion, MCC can be defined as:

‘‘A service that allows resource constrained mobile users to adaptively adjust processing and storage capabilities by transparently partitioning and offloading the computationally intensive and storage demanding jobs on traditional cloud resources by providing ubiquitous wireless access’’.

Careful planning is required before offloading the jobs on a cloud server by considering the network conditions and communication overhead to make offloading beneficial for mobile users [16]. The architecture of the MCC is depicted inFig. 2.

Mobile clients interact with a cloud service provider using native mobile applications or embedded browser applications. Embedded browser applications are developed using standard web development languages (e.g. HTML and JavaScript). Native

applications are developed using mobile platform supported programming languages and a set of APIs provided by the cloud service provider. Mobile clients are connected with the base transceiver station to access the mobile network services. The mobile client utilizes mobile network services to communicate with cloud through the Internet. There are two types of cloud servers: (a) portal cloud server(s) and (b) back-end cloud server(s). The portal cloud server receives and processes the mobile client requests for using the cloud services. The portal cloud server is also known as the cloud controller in literature. The portal cloud server utilizes the back-end cloud servers for providing different services to mobile clients.

1.1. Security threats and counter measures

There are numerous challenges existing in the field of MCC , including data replication, consistency, limited scalability, unrelia-bility, unreliable availability of cloud resources, portability (due to lack in cloud provider standard), trust, security, and privacy [17]. The above-mentioned challenges have become a barrier in the rapid growth of MCC ’s subscriber. According to survey [18,19], 74% of IT Executives and Chief Information Officers are not will-ing to adopt cloud services due to the risks associated with secu-rity and privacy. To attract potential consumers, the cloud service provider has to target all the security issues to provide a completely secure environment. Research organizations and academia have undertaken a massive amount of work to secure a cloud comput-ing environment. There are still some grey areas that need to be addressed, such as the security and privacy of user’s data stored on cloud server(s), security threats caused by multiple virtual machines, and intrusion detection. As MCC is based on cloud com-puting, all the security issues are inherited in MCC with the extra limitation of resource constraint mobile devices. Due to resource limitation, the security algorithms proposed for the cloud comput-ing environment cannot be directly run on a mobile device. There is a need for a lightweight secure framework that provides security with minimum communication and processing overhead on mo-bile devices.Fig. 3shows the different security services that may run on different layers to provide a secure MCC environment.

The security and privacy protection services can be achieved with the help of secure cloud application services. In addition to security and privacy, the secure cloud application services provide the user management, key management, encryption on demand, intrusion detection, authentication, and authorization services to mobile users. There is a need for a secure communication channel between cloud and the mobile device. The secure routing protocols can be used to protect the communication channel between the mobile device and cloud. Virtualization improves the utilization of cloud resources but introduces new security issues due to the lack of perfect isolation of virtual machines hosted on a single server. The security issues imposed by virtualization can be tackled to some extent with the help of virtual machine secure monitoring, mirror, and migration. To provide the transparent cloud environment, mobile users must have the facility to audit the security level of the hosted services. The audit can be done with the help of a cloud service monitor. The cloud service monitor examines the security level and flows of the running environment. The security level should meet the user security requirements and the flow of the running environment should be normal. The security verification of uploaded data on cloud can be done using a storage security verification service. The physical security of the datacenter plays a very important role to achieve security and privacy. Physical security deals with the measures taken to avoid unauthorized personnel physically accessing the resources of the cloud service provider. Physical security can be achieved with the help of security guards, video surveillance,

(3)

Fig. 2. Mobile cloud computing architecture.

Fig. 3. Security services on different layers.

security lighting, sensors, and alarms. The researchers have done

a massive amount of work [20–28] to provide an energy-aware

high performance computing environment. However, there is also a need for energy-efficient security frameworks for mobile devices to provide security and privacy services in an MCC environment [29].

For the last few years, MCC has been an active research area. As

MCC is in the preliminary stages, limited surveys are available in

various domains of MCC [30–32]. In [30], the authors present the comparison of different application models for MCC and highlight the research challenges on the subject. The authors in [31] have investigated the MCC architectures, application offloading, and context-aware services. To the best of our knowledge, there exists only a single survey [32] that discusses security issues as a part of the survey in MCC . The major focus of the survey

presented in [32] is on mobile communication and computing

issues. The mobile communication issues are associated with low bandwidth, service availability, and heterogeneity. The computing issues are linked with computing offloading, security, data access, and context-aware mobile cloud services. This survey is different from [32] in the following aspects: (a) the focus of the survey is completely on security issues in MCC , (b) existing lightweight security frameworks are investigated in detail, (c) the survey highlights important parameters and discusses the impact of the parameters on security frameworks, (d) the survey identifies the

open research issues regarding security and privacy in MCC , and (e) state of the art taxonomy is presented.

The rest of the paper is organized as follows. Section2presents the parameters used to evaluate different security frameworks for MCC . Section3deals with actual survey of different security frameworks that have been presented and published. The positive and negative aspects of security frameworks are illustrated in Section4. Finally, Section5concludes our survey.

2. Evaluation criteria for security frameworks

A number of the security frameworks presented in the survey deal with the security of files/data created and manipulated on a mobile device or cloud servers. The rest of the frameworks cover the security aspects of mobile applications or a mobile application model that uses cloud resources to augment the capability of a mobile device. Therefore, the survey classifies existing security frameworks for MCC into two categories: (a) data security frameworks and (b) application security frameworks. The computational requirements, scalability, and assumptions play a very important role for the successful deployment of security frameworks in an MCC environment. Moreover, mobile users are more interested in storing files on a cloud server without exposing any information. Security frameworks should also provide privacy and security features to mobile users.

(4)

2.1. Evaluation criteria for data security frameworks

The data security frameworks deal with the security of mobile user’s files created and manipulation on a mobile device or cloud server. By considering the importance of the aforementioned pa-rameters (Section2) in MCC , the following evaluation parameters have been selected for comparing the presented security frame-works.

2.1.1. Basic theory

The basic theory parameter specifies the basic building blocks of the discussed security frameworks for MCC . The basic building blocks may be mathematical or cryptographic principles. The basic theory parameter is included to identify the computational requirements of the discussed security frameworks.

2.1.2. Data protection

A number of security frameworks cover the Protection of

Data Created and Manipulated on Device

(

ProDCMD

)

[29]. The

rest of the security frameworks deal with the Protection of Data

Created and Manipulated on Cloud

(

ProDCMC

)

[33]. The data

protection parameter identifies the category of discussed security frameworks as ProDCMD or ProDCMC .

2.1.3. Data integrity

To increase the storage capacity, mobile users upload files on the cloud server and lose physical control of uploaded files. There should be a mechanism to ensure the correctness of users’ uploaded files. The correctness of the uploaded file can be verified with the help of integrity verification. The data integrity parameter identifies the consideration of the integrity verification issue in discussed security frameworks.

2.1.4. Scalability

Scalability is the ability of the system to handle a growing amount of users in an elegant manner. The security framework is considered to be highly scalable, if the users’ increase can be adaptively handled without degradation in performance or change in physical infrastructure. If the proposed security framework is dependent on some centralized server managed by a third party to provide security features, the scalability of the framework is considered as moderate, otherwise poor.

2.1.5. Assumption

A security framework is considered to be secured, if the under-lying assumptions of the framework are weaker. The assumption parameter identifies the components that are assumed to be fully trusted, semi-trusted, or distrusted to provide security features in an MCC environment. Semi-trusted means some functions are as-sumed to be done perfectly but some may be compromised, for example storage may be exposed but computation is properly con-ducted.

2.1.6. Data access

Data access can be divided into three categories: (a) auto-mated and (b) semi-autoauto-mated. Data access is considered to be automated, if users share encrypted files located on cloud servers among groups of people and authorized users can access and de-crypt files automatically (without the physical involvement of the file’s owner). The data access is considered to be semi-automated if the user requires to send some secret information (e.g. password, secret key) through other means (e.g. email, SMS, or call) to access and decrypt the uploaded file.

2.1.7. Authentication

If a mobile user has uploaded the files on cloud server for sharing with multiple users, there should be a mechanism to verify the originator of the file. The authentication mechanism may help to verify the originator of the file. The authentication parameter identifies the consideration of authentication issue in discussed security frameworks.

2.2. Evaluation criteria for application security frameworks

The application security frameworks deal with the security of the mobile application or mobile application model [34–37] that utilizes cloud resources to provide better services to mobile users. The selected evaluation parameters are discussed below:

2.2.1. Application type

Application type parameter is used to identify the mobile application model or type of mobile application whose security aspects are covered in the MCC environment.

2.2.2. Security features

Security features parameter identifies the covered security aspect of mobile applications or mobile application models in the

MCC environment. The security features may be data security, data

integrity, identity privacy, location privacy, authentication, secure data access management, risk management, or secure routing.

2.2.3. Assumptions

The framework is considered to be secured, if the underlying assumptions of the frameworks are weaker. The assumptions’ parameter identifies components that are assumed to be fully trusted, semi-trusted, or distrusted to provide security features.

2.2.4. Scalability

Security frameworks proposed for mobile applications or the mobile application model are considered to be highly scalable, if the users’ increase can be adaptively handled without degradation in performance or change in physical infrastructure. If the proposed security framework is dependent on some centralized server managed by a third party to provide security features, the scalability of the proposed framework is considered moderate, otherwise poor.

3. Survey of existing security frameworks for MCC

In this section, we present countermeasure solutions that have been proposed in the scientific journals and conferences pertaining to securing MCC . A comparison and critical discussion on the proposed ideas will be detailed in the next section.

3.1. Data security frameworks

The countermeasures for data security frameworks are pre-sented in chronological order. The prepre-sented data security frame-works only considered the security of mobile users’ data created and manipulation on the mobile device in the MCC environment.

3.1.1. Energy efficient framework for integrity verification of storage services in MCC

Itani et al. [38] proposed an energy efficient framework for mo-bile devices to ensure the integrity of the momo-bile users’ files/data stored on the cloud server using the concept of incremental cryptography and trusted computing [39,40]. The system design

(5)

Fig. 4. Interaction among the mobile client, cloud service provider and trusted coprocessor.

contains three main entities: (a) mobile client, (b) cloud service provider, and (c) trusted third party. The mobile client utilizes the storage services provided by the cloud service provider. The cloud service provider is responsible for managing, operating, and allo-cating the cloud resources efficiently. The trusted third party is responsible for configuring and installing the tamperproof copro-cessors on the remote cloud. Each coprocessor is associated with multiple registered mobile clients. The coprocessor distributes Se-cret Key

(

SK

)

with associated mobile clients and generates a mes-sage authentication code on behalf of mobile clients. Interactions among the components are shown inFig. 4.

The authors have discussed uploading, block insertion, block deletion, and integrity verification operations for files in the MCC environment. For uploading a file on cloud server, the mobile client

generates an incremental Message Authentication Code

(

MACf

)

using SK shown in Eq.(1).

MACf

=

k



i=1

HMAC

(

Fi

,

SK

)

(1) where k represents the total logical partition of file, Ficorresponds to the ith part of the file, and MACfrepresents the sum of increment

message authentication codes. The mobile client stores MACf on

local storage and uploads files on a cloud server.

At any time, the mobile client can perform insert, delete, and update operations on uploaded file(s). To insert or delete a block at the jth position of file, the mobile client requests a cloud server for the file. The cloud server transfers files to the mobile client as well as to the trusted coprocessor. The trusted coprocessor recon-structs and sends the MACcopto the mobile client. The mobile client receives the file and MACcopfrom the cloud server and trusted co-processor respectively. The received MACcopis compared with the stored MACf for integrity verification. The same value of received and recalculated MACs confirms the integrity of the file. After in-tegrity verification, the mobile client inserts/deletes a block at the

jth location of the file and reproduces MACfusing inserted/deleted blocks, old MACf, and SK . To avoid the communication overhead, only the updated block with location information is uploaded on the cloud server for storage synchronization. The mobile client can verify the integrity of file(s) stored on the cloud server. The mo-bile client initiates the integrity verification process by sending a request to cloud server(s). On receiving the request, the cloud

server(s) transfer files to the trusted coprocessor. The trusted co-processor computes the incremental authentication code for each file and sends to the mobile client. The mobile client only needs to compare the stored MACf with received MACcopto verify the in-tegrity of files.

Experimental results of the proposed framework show a 90% saving in processing and energy on the mobile device as compared to conventional techniques that generate MACffrom scratch.

3.1.2. A framework for secure data service in MCC

Jia et al. [41] proposed a secure data service that outsources data and security management to cloud in trusted mode. The secure data service allows mobile users to move data and data sharing overhead to cloud without disclosing any information. There are three main entities involved in the proposed network model: (a) data sharer, (b) data owner, and (c) cloud service provider shown inFig. 5. The data owner shares files and grants access privileges to the data sharer. The data owner and data sharer both utilize the cloud storage service to store and retrieve files.

The proxy re-encryption [42] and identity base encryption [43] schemes are used to achieve the secure data service. In the proxy re-encryption scheme, a semi trusted proxy transforms ciphertext encrypted with A’s public key into another ciphertext encrypted with B’s public key [44]. The identity based encryption scheme is based on bilinear mapping. A bilinear map can be defined as:

e

:

_G₁

×

_G₁

→

_G_T

.

(2) Eq.(2)represents the efficient bilinear map having the properties of bilinearity, computability, and non-degeneracy [43]. The G1and

GTare the multiplicative cyclic groups with prime order q and g is the generator of the G1. Two independent hash functions H1and H2

are used in the proposed scheme shown in the following equation.

H1

: {

0

,

1

}

∗

→

_G₁

,

H2

:

GT

→

G1

.

(3)

The proposed secure data service works in six phases discussed in the following section:

(1) Setup phase: In this phase, system Master Key (MK ) and system parameters (G1

,

GT

,

g

,

gs) are generated, where s

∈

Zqis randomly selected. Only the authority has information about the

MK while system parameters are public and disseminated among

(6)

Fig. 5. Proposed framework’s network model [41].

(2) Key generation phase: Mobile users have to register in the system to obtain a SK on the basis of mobile users’ identity using

MK and H1as illustrated in the following equation.

SKID

=

H1

(

ID

)

MK

,

where ID

∈ {

0

,

1

}

∗

.

(4)

(3) Encryption phase: Mobile user divides file into n chunks. Each chuck is represented with miand encrypted under owner identity

(

IDowner

)

as a public key. The encryption under identity is referred as identity based encryption.

EF

=



gr

,

mi

·

e



gs

,

H1

(

IDowner

)

r



where 1

≤

i

≤

n

.

(5)

Here, r

∈

_Z_qis selected randomly. The Encrypted File

(

EF

)

is up-loaded on the cloud server.

(4) Re-encryption key generation phase: After uploading the EF , the mobile user generates the re-encryption keys for authorized users to access the file.

(5) Re-encryption phase: The re-encryption keys are sent to the cloud for encryption of the EF using the proxy re-encryption scheme. The proxy re-encryption scheme transforms ciphertext encrypted with owner’s public key into a ciphertext encrypted with sharers’ public keys.

(6) Decryption phase: The sharer requests the cloud server to obtain the re-encrypted file. The cloud verifies the validity by checking the re-encryption key for the sharer. If a key is found, the cloud server sends the corresponding re-encrypted file to the sharer. Due to the ciphertext transformation, the sharer can decrypt the file without the involvement of the data owner.

The proposed secure data service not only provides the data privacy but also fine-grained access control with the minimum cost of updating access policy and communication overheads.

3.1.3. A framework for secure storage services in MCC

Hsueh et al. [45] proposed a scheme for smart phones to en-sure the security and integrity of mobile users’ files stored on cloud server(s). The authors also introduced an authentication mech-anism to authenticate the owner of the uploaded file on cloud. The proposed framework consists of four modules: (a) mobile de-vice, (b) cloud service provider, (c) certification authority, and (d) telecommunication module shown inFig. 6. Mobile device uti-lizes cloud services. The certification authority is responsible for authentication of mobile devices. The telecommunication module

Fig. 6. Proposed framework [45].

generates and keeps track of mobile devices’ passwords and re-lated information to use cloud services. The authors suppose that

SK , Public Key

(

PK

)

, and Session Key

(

SEK

)

are securely distributed among mobile devices, the telecommunication module, and certi-fication authority. To use the cloud services, the mobile user has to register with the telecommunication module through the certifica-tion authority. On successful registracertifica-tion, the telecommunicacertifica-tion

module issues a Password

(

PWD

)

for mobile device to use cloud

resources. The registration request is represented as:

MD

→

CA

:

EPK TE

(

MU

,

Num

,

TK

) ,

UN

,

SSKMU

(

H

(

MU

,

Num

)) ,

H

(

MU

,

Num

).

(6)

The MU represents the mobile user’s name, Num is the repre-sentation of the mobile user’s number, TK is the combination of the

Num and PWD, UNdepicts the randomly generated number for the proof of identity, H is a standard hash function, EPKTMrepresents

encryption with the PK of telecommunication module, and SSKMU

generates a signature for the mobile user using a cryptographic function on the passed value and SK of the mobile device. After receiving the message from the mobile device, the certification authority validates the authenticity of the message with the help of the received signature. If the message is from a valid user, the certification authority sends the following message to the telecom-munication module.

CA

→

TM

:

EPKTM

(

MU

,

Num

,

TK

) ,

UN

,

SSKCA

(

H

(

MU

,

Num

)) .

(7)

The telecommunication module authenticates the certification authority using received SSKCA. On successful authentication of the

certification authority, the telecommunication module registers the mobile user by storing the mobile user’s information in a local database. The stored information is used for verification of mobile users in the future. The telecommunication module is also responsible to generate PWD for the mobile user to access cloud resources. For secure delivery of PWD to a mobile device, the telecommunication module encrypts the mobile user’s information using the mobile device’s PK . The PWD is further encrypted with TK to ensure that only the authorized mobile user can decrypt the PWD. The telecommunication module forwards the encrypted information to the mobile device through the certification authority as shown below.

TM

→

CA

:

EPKMU

(

MU

,

Num

,

UN

,

ETK

(

PWD

))

(8)

CA

→

MD

:

EPKMU

(

MU

,

Num

,

UN

,

ETK

(

PWD

)) .

(9)

Mobile device encrypts file with SEK and uploads file along with

PWD, MU, and SSKMUon cloud.

MD

→

C

:

PWD

,

MU

,

ESEK

(

Data

) ,

(7)

where SV represents the secret value generated by the mobile device. The authors assume that SV is known to the mobile device, cloud, and telecommunication module. To download a file,

the mobile device sends PWD, MU, and H

(

MU

∥

SV

)

to cloud.

Cloud regenerates the hash value using MU and SV . The newly computed hash value is compared with the received signature for authentication of the mobile device request. After successful authentication, cloud sends the encrypted file to the mobile device along with a signature.

C

→

MD

:

ESEK

(

Data

) ,

H

(

ESEK

(

Data

) ∥

SV

) .

(11) The mobile device verifies the signature and decrypts the file using

SEK . The authors also introduced a secure file sharing mechanism

between two mobile users, say A and B. If user B wants to share a file with user A, user B has to inform user A about MUB, NumB, and

PWDBto access files on cloud. After downloading file, user A can authenticate the owner of the file on the basis of a signature stored with the encrypted file. The sharing mechanism reveals user B’s secret information on A. User A can utilize the secret information to impersonate user B in the future.

3.1.4. A public provable data possession scheme for MCC

Yang et al. [46] extended the public provable data possession scheme proposed in [47] for a resource constrained mobile device that ensures the privacy, confidentiality, and integrity of mobile users’ data stored on cloud. The system model consists of three main entities: (a) mobile end-user, (b) trusted third party, and (c) cloud storage service. The mobile end-user utilizes the cloud storage and may request data storage validation. Trusted Third Party

(

TTP

)

provides encryption, decryption, and authentication services for the mobile end-user to overcome the processing

burden. The cloud Storage Service

(

CSS

)

contains an enormous

amount of storage for mobile end-users. The CSS is also responsible for providing proof of data possession when requested by TTP or the mobile end-user. The proposed scheme uses Diffie–Hellman key exchange [48], bilinear mapping [49], and Merkle Hash Tree

(

MHT

)

[50]. Diffie–Hellman key exchange is used to securely

distribute the symmetric key between two users without the

involvement of a third party. A map e

:

₁

×

_G₁

→

_G_T having

properties of bilinearity, computability, and non-degeneracy is called a bilinear map. Where G1is the gap Diffie–Hellman group,

GT is the cyclic multiplicative group of prime order p, and g is the generator of G1. MHT is constructed as a binary tree where

leaf nodes contain the hash value of data blocks. The MHT is an efficient way to identify that the set of data blocks are unchanged or undamaged. During the verification, the verifier only needs to verify the root hash value of the tree. In the setup phase, TTP and mobile end-user share the symmetric key using a Diffie–Hellman key exchange process. The Diffie–Hellman key exchange process

uses the private keys

α

and

β

of mobile-end user and TTP

respectively. The key exchange process is shown in steps 1 and 2 ofFig. 7.

The mobile end-user encrypts the file with shared symmetric key

(

gαβ

)

. The encrypted file is delivered to the TTP. After receiving the file from the mobile end-user, TTP generates the pair of asymmetric keys

(

ek

,

dk

)

for encryption and decryption respectively. TTP encrypts the file using ek, divides the encrypted file into N small chunks, encodes each chunk with erasure codes, and constructs MHT . The leaf nodes of the MHT represent the hash values of the file’s chunks. The TTP is also responsible for generating the hash of the root of MHT tree represented with

H

(

R

)

, encrypting dk and H

(

R

)

with the shared symmetric key, and delivering encrypted information to the mobile end-user. The

mobile end-user signs H

(

R

)

with private key

α

to generate a

meta signature

(

SigSK

(

H

(

R

)))

. The mobile end-user sends a meta signature back to TTP. The encrypted file is uploaded on a cloud

Fig. 7. Setup phase of proposed scheme.

Fig. 8. Integrity verification phase of the proposed scheme.

server along with SigSK

(

H

(

R

))

and a collection of file chunks’ signatures (Φ). TheΦis evaluated using the following equation.

Φi

= [

H

(

mi

)

umi

]

β

,

1

≤

i

≤

N (12) where u is randomly chosen from G1and miis the ith chunk of the file.

In the integrity verification phase, the mobile end-user or TTP sends a challenge to CSS as shown inFig. 8. The challenge is built by choosing c random variables in the range of 1 to N to construct a set T . For each t

∈

T , the corresponding

v

t

∈

Zpis randomly selected. The challenge

(

t

, v

t

)

for each t

∈

T is sent to the CSS. After receiving the challenge, CSS generates a proof of verification that includes H

(

mt

)

of the corresponding data block for every t

∈

T

, µ, ω

, and additional information

(Ω

_t

)

to rebuild the root H

(

R

)

. The

µ

and

ω

are calculated using following equations.

µ =

c



t=1

v

tmt

∈

Zp (13)

ω =

c



t=1 Φvt t

∈

G1

.

(14)

The generated proof is sent to TTP. The TTP reconstructs MHT on the basis of received H

(

mt

)

andΩt. The integrity verification is confirmed, if the bilinear mapping of the following equations satisfies the equality.

e

(

Sig_sk

(

H

(

R

)) ,

g

)

=

?e

(

H

(

R

) ,

gα

)

(15) e

(ω,

gα

)

=

? e



_c



t=1

(

H

(

mt

)

vtuµ

) ,

gαβ



.

(16)

In the secure file retrieval phase, the mobile end-user and TTP share SK through Diffie–Hellman key exchange. The mobile end-user encrypts dk with SK and sends to TTP. The TTP requests CSS for the encrypted file. The encrypted file is decoded and decrypted by TTP to get the original file. Finally, TTP sends the decrypted file to the mobile-end user through the secure channel.

In the public provable data possession scheme, TTP sends an encrypted and encoded file to CSS that ensures the privacy and confidentiality of the file. The signature structure of MHT helps to ensure the integrity of file with minimum storage and communication overhead.

(8)

3.1.5. Lightweight and compromise resilient storage outsourcing in MCC

Ren et al. [29] proposed three schemes to ensure the confiden-tiality and integrity of the users’ files stored on cloud. The files are assumed to be created and operated only on a mobile device. The files may be stored on single or multiple cloud servers. The authors assume the cloud servers as distrusted nodes, the mo-bile device as semi-trusted in case of storage, and trusted in case of computation. The mobile device is considered semi-trusted in terms of storage due to the fact that the loss of the device exposes all the storage information. The mobile device is considered trusted in case of computation for the reason that a mobile user may take precautionary measures to hide the execution environment of mo-bile device from malicious activities. In each scheme, the momo-bile device is responsible for encryption, decryption, and integrity ver-ification. The authors discuss secure uploading and downloading of a file on cloud server(s) in each scheme.

3.1.5.1. Encryption based scheme

(

EnS

)

. When a user wants to

upload a file on a cloud server through a mobile device, the user has to provide a PWD. Mobile device generates Encryption Key

(

EK

)

and Integrity Key

(

IK

)

by applying standard Hash function

(

H

)

on concatenation of File Name

(

FN

)

, File Size

(

FS

)

, and PWD depicted in the following equations.

EK

=

H

(

PWD

∥

FN

∥

FS

)

(17)

IK

=

H

(

FN

∥

PWD

∥

FS

).

(18) Mobile device encrypts file with EK for confidentiality and generates MAC using file and IK for authentication.

EF

=

EEK

(

file

)

(19)

MAC

=

HMAC

(

file

,

IK

).

(20) Mobile device uploads EF , H

(

FN

)

, and MAC on the cloud server, deletes IK and EK , and stores FN in the local file table. While downloading a file, mobile device computes H

(

FN

)

and transfers the hash value to the cloud server. The cloud server looks for corresponding EF and MAC with the help of received H

(

FN

)

. If a file is found, the cloud server sends EF and MAC to the mobile device. The mobile device prompts the user to enter a PWD for the file to regenerate IK and EK for integrity verification.

EK

=

H

(

PWD

∥

FN

∥

FS

)

(21)

IK

=

H

(

FN

∥

PWD

∥

FS

).

(22) Afterwards, the mobile device decrypts the EF using regenerated

EK to get the original file. The mobile device also regenerates MAC

using FN and regenerated IK .

Decrypted File

(

file

) =

DEK

(

EF

)

(23)

MAC

=

HMAC

(

file

,

IK

).

(24) The same value of received and recalculated MACs confirms the integrity of the file.

3.1.5.2. Coding based scheme

(

CoS

)

. CoS reduces the computation

overhead of encryption imposed by EnS using a lightweight computation operation to preserve the privacy of the users’ files. When a mobile user wants to upload a file on the cloud server through a mobile device, the user has to provide a PWD. The mobile device divides the file into d parts such that each part has t chunks and each chunk has n bits. Suppose the mobile user wants to store a file on d cloud server(s). The mobile device generates coding vector (

α

) by applying the recursive hash function on a concatenation of

PWD, FN, and FS for secrecy as stated in the equations below.

α

i

=

Hi

(

PWD

∥

FN

∥

FS

),

where 1

≤

i

≤

t

.

(25)

Hiis evaluated as:

H1

(

x

) =

H

(

x

) ,

Hi

(

x

) =

H



Hi−1

(

x

)

where 2

≤

i

≤

t

.

(26)

The mobile device generates IK by applying a hash function on the concatenation of

α

.

IK

=

H

(α

1

∥

α

2

∥

α

3

· · · ∥

α

t

).

(27) The mobile device uses

α

to produce Secrecy Code

(

SC

)

for each part of the file to achieve confidentiality.

SC [j]

=



_t



i=1

α

i

∗

F

[

i

][

j

]



where 1

≤

j

≤

d (28)

where F

[

i

][

j

]

represents the jth part of the file. The mobile device constructs the MAC using the file and IK .

MAC

=

HMAC

(

file

,

IK

).

(29) Afterwards, the mobile device uploads SC

[

j

]

,

H

(

FN

+

j

)

, and MAC on cloud server

(

CSj

)

, where j is randomly selected in the range of 1 to d. The mobile device saves FN on local table and deletes

α

and

IK .

While downloading the file from cloud server(s), the mobile device regenerates H

(

FN

+

j

)

and sends it to the corresponding

CSj. The CSj looks for SC and MAC in local storage using the

received H

(

FN

+

j

)

. If a record is found, the cloud server sends the corresponding SC and MAC to the mobile device. The mobile device prompts the user to enter a PWD for the file to reproduce

α

and IK .

α

i

=

Hi

(

PWD

∥

FN

∥

FS

)

where 1

≤

i

≤

t (30)

IK

=

H

(α

1

∥

α

2

∥

α

3

· · · ∥

α

t

).

(31) The mobile device decodes the file by multiplying SC with the

inverse of

α

. The multiplication of SC with the inverse of

α

produces the original file.

file

=



α

_i−1

∗

SC [j]



where 1

≤

i

≤

t

,

1

≤

j

≤

d

.

(32) After getting the original file, the mobile device regenerates MAC using the decrypted file and regenerated IK .

MAC

=

HMAC

(

file

,

IK

).

3.1.5.3. Sharing based scheme

(

ShS

)

. ShS is more energy efficient as

compared to EnS and CoS. The ShS introduces a simple

exclusive-OR

(

xor

)

based secret sharing mechanism that requires less

computation power on the device side. When the user wants to upload a file on the cloud server through a mobile device, the user has to provide a PWD. The mobile device generates IK using a hash function on FN, FS, and PWD.

IK

=

H

(

FN

∥

PWD

∥

FS

).

(34) The mobile device generates

(

d

−

1

)

random files/shares donated by RS

[

j

]

, where j is in the range of 1 to

(

d

−

1

)

. The dth share is produced with the help of two xor operations. The first xor operation is performed on

(

d

−

1

)

randomly generated files/shares to produce Accumulative Results

(

AR

)

. The second xor operation is performed on the original file and AR as shown below.

AR

=



_d₋₁



i=1 RS [i]



(35) RS

[

d

] =

AR



file

.

(36)

(9)

The mobile device further generates MAC using the file and IK to achieve integrity.

MAC

=

HMAC

(

file

,

IK

).

(37) The mobile device uploads RS

[

i

]

, H

(

FN

+

i

)

, and MAC on CSi, where i is randomly selected in the range of 1 to d. The mobile device saves

FN and deletes IK . When the user wants to download a file from CS

through the mobile device, the mobile device computes H

(

FN

+

i

)

and sends to the corresponding CSi. The corresponding CSilooks for

RS

[

i

]

and MAC with the help of the received H

(

FN

+

i

)

. If a record is found, CSisends the corresponding RS

[

i

]

and MAC to the mobile device. The mobile device prompts the user to enter a PWD for the file to reproduce IK .

IK

=

H

(

FN

∥

PWD

∥

FS

).

(38) Now the mobile device decodes the secrecy code by simply applying xor on all SC .

file

=



_d



i=1 RS [i]



.

(39)

After getting the original file, the mobile device computes MAC for integrity checking using the original file and IK .

MAC

=

HMAC

(

file

,

IK

).

The authors further analyzed each scheme for confidentially and integrity in an environment where cloud servers were fully distrusted and encrypted files were stored on single or multiple cloud server(s). The authors came to conclusion that the probability of guessing the EK and IK is negligible. Other malicious activities to obtain EK and IK either generate a large amount of traffic or require a lot of processing. Both activities can be identified by an intrusion detection system installed on a mobile device.

3.1.6. A security framework for efficient and secure data storage services in MCC

Zhou and Huang [51] proposed a privacy preserving framework called Privacy Preserving Cipher Policy Attribute-Based Encryption

(

PP-CP-ABE

)

for lightweight mobile devices. The proposed scheme offloads the processing and storage intensive encryption and decryption operations on cloud without revealing any information about data contents and security key. The authors also proposed an attribute based data storage system that provides cryptographic access control to overcome the communication and storage overhead for data management on mobile devices as well as on cloud. Here, we limit our discussion to PP-CP-ABE. The architecture of the proposed scheme contains four components: (a) data owner, (b) encryption service provider, (c) decryption service provider, and (d) storage service provider shown inFig. 9.

The Data Owner

(

DO

)

can be a mobile device or a sensor that may request to store and retrieve data from cloud. To increase the processing capability of DO, a major portion of encryption and decryption operations are outsourced on cloud. Encryption Service Provider

(

ESP

)

encrypts the file for DO without having knowledge about the security keys. Decryption Service Provider

(

DSP

)

decrypts the file for DO without getting any information about data contents. The encrypted data is stored on a storage service provider. The authors assume that Trusted Authority

(

TA

)

is responsible for generating and distributing keys among DOs. The PP-CP-ABE is based on bilinear mapping (discussed in Sec-tion3.1.2) [52], access policy tree, and secret sharing scheme [53]. Access policy tree is constructed with the help of internal and leaf nodes. The leaf nodes represent the attributes associated with DO while internal node represents the logic gates (e.g. AND or OR). The

Fig. 9. Architecture of proposed framework [51].

secret sharing scheme divides the secret into n shares where any t shares can reconstruct the secret.

In the setup phase, TA randomly selects

α, β ∈

_Zpand generates a bilinear map on G1. The TA constructs the PK known to everyone

and MK only known to TA.

PK

=

(

_G₁

,

g

,

h

=

gβ

,

f

=

g1/β

,

e

(

g

,

g

)

α

)

(41)

MK

=

(β,

gα

).

(42)

Users need to get registered with TA to get private keys. The private key is generated on the basis of user’s attributes.

SK

=



D

=

g(α+ r) β

_{, ∀}

_j

∈

S

:

Dj

=

gr

·

H

(

j

)

rj

,

D′j

=

g rj



(43) where r

∈

_Z_p, S represents user attributes, rj

∈

Zp, and j

∈

S.

DO needs to specify the Data Access Tree

(

DAT

)

to outsource encryption operations. The DAT is divided into two sub trees

DATDOand DATESP to preserve data security while offloading the

computation. DATESP is cloud controlled data access policy and

DATDOis DO controlled data access policy. The original DAT can be reconstructed as follows:

DAT

=

DATDO

∧

DATESP (44)

where

∧

represents a logical AND gate and depends on the root

node of DAT . The DATDOis dealing with a small number of attributes to reduce computational overhead on the device. Normally, DATDO contains one attribute. The DO randomly creates a one degree poly-nomial

(

qr

(

x

))

and generates secrets s

=

qr

(

0

),

s1

=

qr

(

1

)

, and

s2

=

qr

(

2

)

. The DO sends DATESPand s1 to ESP. On successful re-ception of DATESP, ESP generates Temporal Cipher

(

TC

)

on the basis of received information as depicted in the following equations.

TCESP

=

∀

y

∈

YESP

:

Cy

=

gqy(0)

,

C ′ y

=

H

(

att

(

y

))

qy(0)



(45) qy

(

0

) =

qparent(y)

×

(

index

(

y

)) ,

(10)

Fig. 10. Reference architecture of elastic application [34].

where YESPrepresents the set of leaf nodes in DATESP, att

(

y

)

returns the attributes associated with the leaf node y, and index

(

y

)

returns the unique index associated with each node. Meanwhile, DO com-pletes the encryption process using s and s2.

TCDO

=

∀

y

∈

YDO

:

Cy

=

gqy(0)

,

C ′ y

=

H

(

att

(

y

))

qy(0)



(47) C

=

Me

(

g

,

g

)

αs

,

C

=

hs (48) where M is a message and e represents the bilinear mapping. DO sends TCDO,C , and C to ESP. The ESP generates the ciphertext on

ˆ

the basis of received information described in Eq.(49).

CT

=



DAT

=

DATESP

∧

DATDO

; ˆ

C

=

Me

(

g

,

g

)

αs

;

C

=

hs

; ∀

y

∈

YDO



DATESPCy

=

gqy(0)

,

C_y′

=

H

(

att

(

y

))

qy(0)

 .

₍₄₉₎

To offload computation for decryption without revealing private key information, DO blinds the private key with the help of ran-dom number t

∈

_Z_pas shown in Eqs.(50)and(51).

Dt

=

g t(α+r) β ₍₅₀₎ SKB

=



DB

=

g t(α+r) β

_{, ∀}

_j

∈

S

:

Dj

=

gr

·

H

(

j

)

rj

,

D′j

=

g rj

 .

₍₅₁₎

DSP uses the blinded key on encrypted file to generate a raw file. DO converts the raw file into the original file with acceptable

pro-cessing and storage overhead. Interested readers may refer to [51] to see the detail of decryption process.

ESP works on DATESP and s1 during encryption. For a given one degree polynomial q

(

x

)

, secrets s and s2 are information-theoretically secure, if s1 is known [54]. DSP works on a blinded key for decryption to produces a raw file. DO converts the raw file into the original file with minimum effort. Therefore, processing intensive encryption and decryption operations are outsourced on cloud without revealing any data contents during encryption and security keys during decryption.

All the frameworks discussed under the category of data

secu-rity frameworks have been presented inTable 1chronologically.

Each security framework has been evaluated with reference to evaluation criteria discussed in Section2.1.

3.2. Application security frameworks

The countermeasures for application security frameworks are presented in chronological order. The presented application secu-rity frameworks considered the secusecu-rity of the mobile application or mobile application model in the MCC environment.

3.2.1. Securing elastic application on mobile device for cloud computing

Zhang et al. [34] proposed a model for securing an elastic mo-bile application in a cloud environment. An elastic application [55] consists of: (a) one or more weblet(s), (b) user interface, and (c) manifest. Weblets are independent software modules that can run on a device or cloud and expose an interface for communica-tion with other weblets or user interfaces. The manifest is a static

XML file that contains metadata about an application e.g. digital

sig-nature, maximum weblet instances launched on mobile and cloud, and processing power requirements. The detail of the model is shown inFig. 10.

The main component on the device side is the Device Elas-ticity Manager

(

DEM

)

that configures the application at launch time and makes configuration adjustments at runtime. The router module provides an interface between weblet and user to achieve the transparency between user interface and weblet location. The router module has complete information about each weblet exe-cution location. When the weblet is migrated, the router module is informed about the update in location. The sensing module keeps track of device utilization and shares the information with DEM. The DEM uses device utilization information to take a decision of whether weblet(s) should be launched on a device or moved to cloud. On the cloud side, the main component is the Cloud Elastic-ity Service

(

CES

)

that consists of: (a) cloud manager, (b) application manager, and (c) sensing information collection. The responsibility of the cloud manager is to allocate cloud resources for the execu-tion of weblet(s) and release them after the successful execuexecu-tion of weblet(s). The cloud manager maintains the resource’s usage in-formation like memory used, bandwidth consumed, and compu-tation conducted by each weblet. The application manager installs and maintains the elastic application on behalf of the elastic device. The sensing module collects operational data on cloud. The cloud manager utilizes operational data for tracking usage. The sensing

(11)

Table 1 Comparison of evaluated data security frameworks. Basic theory Data protection Data integrity Authentication Scalabilit y Assumption (AP) Data access ProDCMD ProDCMC AP-1 AP-2 Itani et al. [ 38 ] Incremental message authentication code No No Yes No Moderate Coprocessor is trusted Coprocessor is tamperproof – Jia et al. [ 41 ] Proxy re-encryption (PRE) scheme and identity base encryption (IDE) scheme Yes No No No Highly scalable Cloud server is semi trusted and assume to be always online Adversary cannot hold re-encryption key Automated Hsueh et al. [ 45 ] Standard cryptography functions Yes No Yes Yes Moderate Keys are securely distributed Secret values are securely distributed. Automated Yang et al. [ 46 ] Diffie–Hellman key exchange, bilinear mapping, and merkle hash tree Yes No Yes Yes Moderate Communication channel is secured TTP is trust – Ren et al. [ 29 ] (EnS) Standard cryptography functions Yes No Yes Yes Highly scalable Mobile device is semi trusted, cloud servers are distrusted Communication channel is secured Semi automated Ren et al. [ 29 ] (CoS) Coding vector Yes No Yes Yes Highly scalable Mobile device is semi trusted, cloud servers are distrusted Communication channel is secured Semi automated Ren et al. [ 29 ] (ShS) Exclusive-OR Yes No Yes Yes Highly scalable Mobile device is semi trusted, cloud servers are distrusted Communication channel is secured Semi automated Zhou and Huang [ 51 ] Bilinear pairing, access policy tree, and secret sharing scheme Yes No No No Highly scalable Cloud service provider is semi trusted Security algorithms are secured Automated

(12)

module is also accountable for monitoring the cloud resources for failure detection and resource availability. Cloud fabric interface is a web service provided by CES for mobile applications. Weblet run-time environment is hosted on each cloud node (referred as weblet container) that is responsible for the execution of weblet. The node manager is deployed on each cloud node to look after resource usage (e.g. memory, CPU) of a particular node (server) within cloud. The collected resource’s utilization information is shared with application manager and cloud manager for further actions.

The authors have also addressed various security aspects of the elastic mobile application model. For secure installation of an application, the developer signed a SHA1 hash value for each weblet and stored it in a java like application package. When a user installs the application, the installer re-computes and compares the hash value for integrity verification. After successful verification, the installer registers the application with DEM. The

DEM keeps track of all the applications that require elasticity

manager support. As an installation option, part of the application can be installed on CES with the help of the application manager. Only registered and authenticated users can install the application on CES. The authors also introduced a mechanism that enables the weblet to authenticate another weblet of the same application. The

DEM generates a weblet session key and weblet session secret.

The keys are shared among all the weblets that belong to same application at launch time. During the authentication process, the weblet generates a Hash-based Message Authentication Code

(

HMAC

)

on the basis of nonce, source weblet ID, destination

weblet ID, and weblet session secret. The original message and

HMAC value are sent to the destination weblet. The destination

weblet re-computes the HMAC using received message and own session secret key. The same value of received HMAC and re-computed HMAC confirms the authenticity of the weblet. Weblets can migrate between cloud and device. Usually DEM starts the migration process due to (a) increase in battery life of the device or (b) removal of an intensive execution burden from the device. For secure migration, DEM sends a request to the weblet to stop further processing. The weblet saves running state including session secret and returns to DEM. The DEM sends the request to the cloud manager through the cloud fabric interface for migration. The cloud manager allocates the resources to the migrated weblet and starts the execution from the last saved state. The weblet’s new location information is propagated among all weblets of the application through DEM. The weblets running on cloud need authorization to access external web services before downloading user data. The authorization is only possible if the weblet has the capability to authenticate the user. Authentication can be achieved using different methods. In the shared user credential approach, the weblet may request the user obtains credentials (user name, password, or digital signature) for authorization. The shared user credential is a simple approach but involves risk. In the shared session information approach, weblet(s) running on a device authenticate from the web server and share the received application session key and application session secret among weblets for further communication with external web services. The shared session information approach shares only the session key that is valid for short time period. The third approach says that the weblet requiring external web service access should be executed only on the device. The proposed security framework covers secure installation of elastic application, authentication, secure migration, and authorization of weblets.

3.2.2. A lightweight dynamic credential generation mechanism for user identity protection in MCC

In a cloud computing environment, users’ identity is mainly ver-ified using digital credential e.g. a password or digital certificate.

An adversary may hack the credential’s information to imperson-ate the legal users in a cloud environment. The problem becomes more sophisticated in a mobile cloud environment due to the com-putational limitation of mobile device of running sophisticated security software. Xiao and Gong [56] proposed a lightweight algo-rithm for an MCC environment to generate the automatic dynamic credentials with the mutual coordination of mobile devices and cloud. The automatic generated credentials protect mobile users from an adversary. The proposed scheme changes the dynamic cre-dential constantly on the basis of user and cloud communication. The exchanged data between cloud and user are transformed into dynamic secrets. If a message Miis sent by the mobile user, an up-date in the user’s dynamic secret (Su) is done by applying an xor operation on the sent message shown below.

SU

=

SU

⊕

Mi

.

(52)

If a message Miis sent by cloud, the update in cloud’s dynamic se-cret

(

Su

)

is done by applying a xor operation on a sent message as depicted in the following equation.

SC

=

SC

⊕

Mi

.

(53)

On each dynamic secrets update, there is an increase in packet counter

(

N

=

N

+

1

)

as well. Dynamic credentials

(

S

)

are updated, when the mobile user requests for new data channel from the base station or user-cloud packets exchanged have been increased to a threshold

(

Nthreshold

)

value. The new data channel is required, when mobile users switch between base stations or start new communi-cation. The Nthresholddepends on how frequently the user wants to change the credential. The S is updated on the basis of S, Su, and Sc illustrated in Eq.(54).

S

=

S

⊕

H

(

SU

∥

SC

)

(54)

where

∥

represents a concatenation operation and H represents a

standard hash functions, e.g. SHA or MD5. After updating the dy-namic credential the values of Su, Sc, and N are set to zero.

The frequent update in dynamic credential makes the recovery of S difficult for the adversary. Suppose an adversary keeps the information of S at time t0 and plans for an attack at time t1,

where t1

>

t0. The adversary must track all the communication

of the user-cloud between t0and t1for accurate calculation of S

at t1. The possibility of attack seems to be impractical due to user

mobility, unreliability of wireless communication, and resource limitation. Even the loss of a single packet between t0and t1makes

the recovery of S difficult for an adversary.

3.2.3. In-device spatial cloaking mechanism for privacy protection in MCC

Spatial cloaking is used to protect the privacy of a mobile user

while using the location-based services. Wang and Wang [57]

proposed a top down spatial cloaking mechanism with and without optimization that utilizes cloud resources to provide a scalable, efficient, and improved privacy preserving framework for location-based services. The architecture of the proposed scheme is shown inFig. 11.

The mobile client is responsible for generating the clocked re-gion with the help of hierarchical decomposing of spatial space into h levels, where each level has 4h_{grid cells [}₅₈_{]. The root at} level zero covers the entire system area. In level one, the root is divided into four child grid cells. Level two is constructed by sub-dividing the each child grid cell of level one into four sub-child grid cells. The processing of subdivision is dependent on h. Two cells are considered to be the horizontal neighbors

(

CH

)

of each other, if both cells have same parent and reside in the same row. Two cells are considered to be the vertical neighbors

(

CV

)

of each other, if both cells have same parent and reside in the same column.