J Supercomput (2014) 70:946–976 DOI 10.1007/s11227-014-1269-8
BSS: block-based sharing scheme for secure data storage services in mobile cloud environment Abdul Nasir Khan · M. L. Mat Kiah · Mazhar Ali · Sajjad A. Madani · Atta ur Rehman Khan · Shahaboddin Shamshirband
Published online: 7 August 2014 © Springer Science+Business Media New York 2014
Abstract For the last few years, academia and research organizations are continuously investigating and resolving the security and privacy issues of mobile cloud computing environment. The additional consideration in designing security services for mobile cloud computing environment should be the resource-constrained mobile devices. The execution of computationally intensive security services on mobile device consumes battery’s charging quickly. In this regard, the study presents a novel energy-efficient block-based sharing scheme that provides confidentiality and integrity services for mobile users in the cloud environment. The block-based sharing scheme is compared with the existing schemes on the basis of energy consumption, CPU utilization, memory utilization, encryption time, decryption time, and turnaround time. The experimen-
A. N. Khan (B) · M. L. M. Kiah · A. R. Khan Faculty of Computer Science and Information Technology, University of Malaya, Kuala Lumpur, Malaysia e-mail:
[email protected];
[email protected] M. L. M. Kiah e-mail:
[email protected] A. R. Khan e-mail:
[email protected] M. Ali Department of Electrical and Computer Engineering, North Dakota State University, Fargo, USA e-mail:
[email protected] A. N. Khan · S. A. Madani COMSATS Institute of Information Technology, Abbottabad, Pakistan e-mail:
[email protected] S. Shamshirband Islamic Azad University of Mashhad (IAUM), Mashhad, Iran e-mail:
[email protected]
123
Data security in mobile cloud environment
947
tal results show that the block-based sharing scheme consumes less energy, reduces the resources utilization, improves response time, and provides better security services to the mobile users in the presence of fully untrusted cloud server(s) as compared to the existing security schemes. Keywords
Cloud computing · Mobile cloud computing · Security · Privacy
1 Introduction The objectives of cloud computing [1–3] are to increase the computational capacity of the cloud system and to extend the access to the system services and resources of the cloud end-users keeping the costs of the utilization of cloud infrastructure at relatively low levels. The cloud computing providers offer different types of services to cloud’s subscribers, such as Software as a Service (SaaS), Infrastructure as a Service (IaaS), Platform as a Service (PaaS). In mobile cloud computing (MCC), the aforementioned services can be also accessed by the mobile users. The limited processing and storage capability of mobile devices restrict mobile users for executing the computationally intensive applications using computational power of mobile devices. However, the mobile users may utilize the cloud’s computational power and storage capability for executing the computationally intensive and storage demanding processes of an application. The offloading of the computationally intensive processes on the cloud smoothen the ground for executing computationally intensive and storage demanding applications on the mobile devices. The important factors, such as network condition, dependability of processes, and communication overhead play critical role in making the offloading beneficial for the mobile users [4]. The generic architecture of the MCC is depicted in Fig. 1. Mobile clients interact with base transceiver station to utilize the mobile network services. Mobile clients use cellular/satellite networks or Wi-Fi/WiMAX Internet connectivity to access the cloud resources. The cloud controller utilizes the back-end cloud servers for providing numerous services to cloud’s subscribers. The cloud controller is also accountable to interact with the cloud’s subscribers. The mobile client interacts with the cloud controller using Internet to utilize the cloud’s services. For the last few years, the mobile users are rapidly adopting the cloud services. According to the prediction of ABI Research firm, the mobile cloud computing subscribers are expected to grow from 1.1 % of total mobile users in 2008 to 19 % of total mobile users in 2014 [5,6]. The MCC is facing various challenges that have restricted the expected growth of MCC’s subscribers. These challenges are (a) data replication, (b) consistency, (c) limited scalability, (d) unreliability, (e) unreliable availability of cloud resources, (f) portability (due to lack in cloud provider standard), and (g) trust, security, and privacy [7–9]. The International Data Corporation ( IDC) firm has conducted a survey from different IT Executives and Chief Information Officers ( CIOs) to investigate the top most challenges that need urgent consideration. The survey [10,11] concludes that 74 % of IT Executives and CIOs are not willing to adopt MCC services due to the associated security and privacy risks. MCC is based
123
948
A. N. Khan et al. Cloud Service Provider Cloud Layered Architecture
Mobile Network Services
Application (Web based Application) Platform Infrastructure (Application Development Environment and Supported API) Software Infrastructure (Computational Resources, Storage, and Communication)
Wireless Network
Supervisor Software (OS, Hypervisor, Middleware) Cloud Backbone
`
Internet
Fig. 1 Generic architecture of MCC
on cloud computing, and therefore, all the security threats are inherited in MCC with an additional restriction of mobile device having limited resources. In mobile cloud computing environment, the resource limitation of mobile devices motive researches for proposing energy-efficient security schemes that provides security services with minimum processing, storage, and communication overhead on a mobile device. Energy consumed by the mobile cloud users can be optimized as: • The most data and computational intensive security operations are executed rather in the cloud infrastructure than at the low-power mobile devices without affecting the security and privacy of the mobile users. • The reduction of the computational complexity of security operations by optimizing the codes and implementation techniques. However, there is still not so much work that has been done in the reduction of the computational complexity of the cryptographic algorithms [12]. Therefore, in this paper we have developed a novel energy-efficient cryptographic method, namely Block Based Sharing Scheme (BSS) that reduces the computational complexity of security operations as compared to the exiting schemes such as, encryption-based scheme, codingbased scheme, and sharing-based scheme. The main objective of this research study is to improve secure access of mobile users to the data stored in the fully untrusted cloud servers with the minimization of energy utilized by the mobile devices. The effectiveness of the presented method is justified in a simple empirical analysis and compared with the existing security schemes under four main criteria, namely energy consumption, turnaround time, CPU utilization, and memory usage on the mobile device.
123
Data security in mobile cloud environment
949
The rest of the paper is organized as follows. Section 2 presents the existing security schemes proposed for MCC. In Sect. 3, the MCC security system model is discussed. In Sect. 4, we define a novel cryptographic block based sharing scheme. The results of the comprehensive empirical analysis with some critical remarks are presented in Sects. 5 and 6. We conclude our work in Sect. 7 and address future research directions.
2 State of the art in application and data security for MCC To augment the processing capability of mobile device, mobile users offload the computationally intensive processes of an application on the cloud. However, offloading of the application’s processes on the cloud raises security issues that are identified and addressed in [9,13–19]. Cloud service providers offer storage as a service to increase the storage capacity of the cloud’s subscribers. The mobile user may utilize the cloud storage services to store enormous amount of data on the remote cloud server(s). The mobile users do not have a physical control on the files uploaded on the cloud storage. The loss of physical control on the uploaded files/data raises security and privacy issues that are covered in [10,12,20–23]. In this study, the main focus is only on the data security schemes. Interested reader may refer [1] to explore the security issues in mobile application/mobile application model. The data security schemes found in the literature are as follow: Itani et al. [20] presents an integrity verification scheme for the files uploaded on the cloud storage using incremental message authentication code. To preserve the energy for mobile users, the major portion of integrity verification is carried out by cloud service provider and trusted third party. In [10], Jia et al. introduces a secure data service that offloads security and data management operations on the cloud in a trusted mode using identity based encryption [24] and proxy re-encryption [25] schemes. The authors in [21] proposed a scheme that uses the standard cryptography function to achieve confidentially, integrity, and authentication for mobile users in the cloud environment. Yang et al. [22] covers the privacy and confidentiality issues for mobile users in the proposed scheme called public provable data possession. The resource hungry jobs, such as encryption/decryption, encoding/decoding, signatures generation, and verification are offloaded on trusted third party. In [12], Ren et al. presents three schemes for ensuring the confidentiality and integrity of the mobile users’ files stored on the cloud servers. The first scheme uses standard cryptography functions, second scheme uses the matrix multiplication, and third scheme uses the xor operation to encrypt/decrypt files. Zhou et al. in [23] extends the ciphertext policy attribute-based encryption scheme [15] for providing a privacy preserving framework. The resource intensive security operations are migrated on the cloud in a trusted mode without revealing data contents and security keys. In [26], the authors proposed reencryption based key management schemes for efficiently management of security keys in continuously changing environment. The proposed scheme is dependent on trusted entity refer as manager under the control of client organization. The main contribution of the authors is to reduce the responsibilities of the manager assign in [27] for building a scalable key distribution protocol. In [26], the manager is only accountable to authorize users, generates new public and private keys for every change
123
950
A. N. Khan et al.
in group members, and shares newly generated private key to all authorized users in a group. The rest of the computationally intensive security management operations are migrated on the cloud without affecting users’ privacy. The data security schemes presented in [10,20,28] consider cloud servers as semitrusted entities and offload most of the security management jobs on the cloud to reduce the processing overhead from the mobile device. The data security frameworks/schemes discussed in [20–22] are dependent on the trusted third party to provide the security features. The former data security schemes consider cloud server as a semi-trusted component to implement the solution accurately. The later data security schemes are dependent on trusted third party to handle encoding/decoding, encryption/decryption, signatures generation, or verification on behalf of the mobile user. Although the offloading of mobile users’ jobs on trusted third party saves energy, increase in number of mobile users result in performance degradation. In [26], the focus of the authors is to reduce the responsibilities of the manager assign in [27] for building a scalable key distribution protocol. The trusted entity involved in [26] is under the control of client organization and gracefully handle the client requests. However, the mobile user has to encrypt (only first time) and decrypt (for every download) the file using pairing and exponential operations based on a Weil and Tate pairing [29]. There is a need of encryption and decryption scheme that impose limited processing burden on the mobile device. This paper critically investigates only those data security schemes that focus on the reduction of the computational complexity of cryptographic algorithms. Moreover, the selected schemes provide security features without the involvement of trusted third party and even in the presence of fully untrusted cloud servers. Those schemes that are not dependent on trusted third party and work accurately even in the presence of fully untrusted cloud servers are (a) encryption based scheme, (b) coding based scheme, and (c) sharing based scheme presented in [12]. In each scheme, mobile user is accountable for encryption, decryption, and integrity verification. The CSP is responsible just for the management and storage of the mobile users’ files and requests. If mobile user wants to share files with multiple users, mobile user shares the password of the uploaded files with each user through other communication channel (e.g. SMS, e-mail, and phone call). A brief characteristics of those three cryptographic techniques is provided in the following subsections. The notations used in this paper are presented in Table 1.
2.1 Encryption-based scheme In the Encryption-based scheme (EnS), standard cryptographic function is used to achieve confidentially for the files uploaded on the cloud storage. The integrity of the uploaded files is verified using hash-based message authentication code, such as SHA1 or MD-5. The HMAC procedure is used to generate the message authentication code using the secret key and original message that need to be verified. To upload file on the cloud server, mobile user provides a password that is transformed into encryption key and integrity key. The encryption key is used to achieve confidentially and integrity key is used to verify the integrity of the file. The keys are generated using file name,
123
Data security in mobile cloud environment
951
Table 1 Notations and abbreviations No.
Notation
Abbreviation
No.
Notation
Abbreviation
1
FN
File name
14
α
Coding vector
2
FS
File size
15
Bi
ith Block/chunk of original file
3
MAC
Message authentication code
16
Ci
ith Block/chunk of encrypted file
4
HMAC
Hash-based message authentication code
17
Ki
Encryption/decryption key for ith block/chunk
5
H
Standard hash function
18
IV
Initialization vector
6
PWD
Password
19
DES
Data encryption standard
7
xPWD
Extended password
20
SC
Secrecy code
8
EK
Encryption key
21
RS
Random share(s)
9
IK
Integrity key
22
AR
Accumulative result
10
EF
Encrypted file
23
EnS
Encryption-based scheme
11
F
Original file
24
CoS
Coding-based scheme
12
Concatenation
25
ShS
Sharing-based scheme
13
⊕
Exclusive-OR operation
26
BSS
Block-based sharing scheme
file size, and password as demonstrated in Eqs. (1) and (2). EK = H (PWD FN FS) IK = H (FN PWD FS)
(1) (2)
The standard cryptographic function with encryption key is used to transform the original file into an encrypted file as expressed in Eq. (3). The message authentication code is generated using a hash-based message authentication code procedure that works on the original file and integrity key as illustrated in Eq. (4). EF = Encrypt EK (F) MAC = HMAC H (F, IK)
(3) (4)
The mobile device uploads encrypted file along with H(FN) and message authentication code on the cloud storage using mobile device. For security purposes, the mobile device only saves file name in local file table and deletes all other data, such as integrity key, encryption key, and original file. For downloading a file, mobile device computes H(FN) for the file and transfers the downloading request in conjunction with H(FN) to CSP. The CSP identifies the corresponding encrypted file using received H(FN). The corresponding encrypted file together with message authentication code is delivered to the mobile device. For decryption and verification of a downloaded file, mobile device has to regenerate the integrity and encryption keys. The mobile user knows the password, and hence the keys can be regenerated using the Eqs. (1) and (2). The regenerated encryption key is used to decrypt a file. The decrypted file and regenerated integrity key are used to generate the message authentication code for the verification of downloaded file as
123
952
A. N. Khan et al.
expressed in the following equations. F = Decrypt EK (EF) MAC = HMAC H (F, IK)
(5) (6)
To verify the integrity of the downloaded file, the downloaded message authentication code is compared with the newly calculated message authentication code. The similarity of the message authentication codes ensures the integrity of the downloaded file. 2.2 Coding-based scheme Another cryptographic scheme presented in [12] is Coding-based Scheme (CoS) for ensuring the confidentiality and integrity of the files uploaded on the cloud server. In CoS, confidentiality is achieved using the matrix multiplication and integrity is ensured using hash-based message authentication code. To achieve the confidentiality, mobile device divides the file into ‘d’ blocks, each block is composed of ‘t’ chunks and each chunk is the collection of ‘n’ bits. After file decomposition, ‘d’ matrices of the size ‘t × n’ are generated. The mobile device multiplies each such matrix with coding vector matrix (α) to generate the secrecy code for ensuring confidentiality. For secure uploading of a file, mobile user provides password that is transformed into coding vector matrix. The coding vector matrix is produced with recursive standard hash function calls using password, file name, and file size as expressed in Eq. (7). αi = H i (PWD FN FS), 1 ≤ i ≤ t, where H 1 (x) = H (x), H i (x) = H (H i−1 (x)), 2 ≤ i ≤ t
(7)
The multiplication of each matrix with coding vector produces a secrecy in the following way: SC[ j] =
t
αi ∗ F[i][ j] , where 1 ≤ j ≤ d and 1 ≤ i ≤ t
(8)
i=1
whereF[i][ j] denotes the jth block of the file. To ensure the integrity, mobile device generates the integrity key using standard hash function on concatenation of secrecy codes. The generated integrity key is used to produce message authentication code as expressed in the following equations: IK = H (α1 ||α2 ||α3 || . . . . . . .||αt ) MAC = HMAC H (F, IK)
(9) (10)
The mobile device uploads the generated ‘d’ secrecy codes together with corresponding H(FN+j) and message authentication code on the cloud server(s). Similarly as
123
Data security in mobile cloud environment
953
in the previous method, the mobile device only saves file name in local file table and deletes integrity key, coding vector matrix, and original file. For downloading a file, mobile device computes H(FN+j) where 1 ≤ j ≤ d , for the each block of file. Subsequently, mobile device transfers the downloading request together with H(FN+j) to CSP. The CSP identifies the corresponding secrecy code using received H(FN+j). The secrecy codes together with message authentication code are delivered to the mobile device. For decryption and verification of a downloaded file, mobile device has to regenerate the coding vector and integrity key. The mobile user knows the password, hence the integrity key and coding vector matrix can be regenerated using the process discussed in Eqs. (7) and (9). Each secrecy code is multiplied with the inverse of newly generated coding vector matrix to obtain the decrypted file as illustrated in Eq. (11). F[i][ j] = (αi−1 ∗ SC[ j]), where 1 ≤ i ≤ t and 1 ≤ j ≤ d
(11)
The decrypted file and regenerated integrity key are used to generate the message authentication code for the verification of downloaded file as expressed in the following equation. (12) MAC = HMAC H (F, IK) To verify the integrity of the downloaded file, the downloaded message authentication code is compared with the newly calculated message authentication code. The similarity of the message authentication codes ensures the integrity of the downloaded file. 2.3 Sharing-based scheme The third cryptographic technique presented in [12] is a Sharing-based Scheme (ShS). In this method, confidentially is achieved using simple exclusive-or (xor) based secret sharing mechanism that needs relatively low computational power on mobile device. The file integrity is verified using the hash-based message authentication code as discussed above. To upload file on the cloud storage, mobile device generates (d − 1) random shares denoted by RS[j], where 1 ≤ j ≤ (d − 1). The dth share is generated in two phases. In first phase, the mobile device performs xor operations on (d − 1) randomly generated shares to produced accumulative result. In second phase, mobile device produces dth share by performing xor operation on previously calculated accumulative result and original file. The process of dth share generation is depicted in Eqs. (13) and (14). d−1 RS[i]) AR = (⊕i=1 RS[d] = AR ⊕ F
(13) (14)
Afterwards, the shares, H(FN+j), and message authentication code are delivered to CSP for storage. Mobile device only keeps the information of file name and deletes the other information, such as integrity key, shares, and original file.
123
954
A. N. Khan et al.
Table 2 Summary of the schemes Core Supporting operation operation
Assumptions
Limitations
Conclusions
EnS
Standard cryptography functions
–
Mobile device is Core operations Consume considerable semi-trusted are computationally amount of energy on device intensive
CoS
Matrix multiplication
Construction of coding vector matrix
Mobile device is Extra file semi-trusted management overhead on mobile device
ShS
ExclusiveOR
Generation and uploading of random shares
ShS consumes Mobile device is Supporting less resources as semi-trusted operations are computationally compare to EnS and CoS intensive
CoS requires less resources as compare to EnS
To download a file from CSP, mobile device sends ‘d’ download requests along with H(FN+j) where 1 ≤ j ≤ d to CSP. The CSP delivers the corresponding shares along with message authentication code to mobile device. The mobile device simply performs the xor operations on received shares to generate original file as expressed in Eq. (15). d RS[i]) (15) F = (⊕i=1 The summary of EnS, CoS, and ShS is presented in Table 2. EnS uses the standard cryptography functions that consume considerable amount of energy on the mobile device. On the basis of theoretical analysis, authors in [12] claim that CoS reduces processing overhead on the mobile device as compared to EnS. In CoS, file is physically divided into multiple blocks and each block is represented in the form of matrix. The physical division of the file into multiple blocks imposes extra file management overhead on the mobile device that results in communication overhead. The generated matrices are multiplied with coding vector to achieve the confidentiality for each block of file. The key operations involved in matrix multiplication are (a) multiplication and (b) addition. The multiplication and addition are computationally intensive operations that may result in performance degradation as compared to EnS (depending on the type of cryptography function used in EnS). To reduce more processing overhead on mobile device, ShS was introduced in [12]. The ShS generates (d − 1) shares randomly. The dth share is produced using of two xor operations as discussed in Sect. 2.3. All ‘d’ shares are randomly stored on the cloud storage. An adversary can capture all shares by performing Man-inthe-Middle attack [30,31]. Afterwards, the adversary regenerates the original file by simply applying xor operations. The second possibility is that shares are stored on different cloud servers but even then collusion of the multiple cloud servers can recover the original text. Moreover, the procedures defined in ShS scheme are time consuming and demand considerable amount of data processing and storage on the mobile device.
123
Data security in mobile cloud environment
955
GAE Web Application Instance F4 (2.4 GHz, 512 MB) Virtulization
Mobile Device
Cloud Service Provider
Fig. 2 The system model for block-based sharing scheme
In the proposed scheme called BSS, the users’ files are logically divided into multiple blocks that reduce the communication and file management overhead from the mobile device as compared CoS, and ShS. Similarly, comparatively light-weight operations are used in BSS for generating the secrecy codes. Moreover, the involvement of the password in generating the secrecy code keeps the scheme compromise resilient. In addition, the BSS provides confidentiality and integrity services to mobile users for the files stored on the cloud storage with minimum processing, storage, and communication overhead.
3 System model The system comprises of two main entities; (a) mobile user and (b) cloud service provider as illustrated in Fig. 2. The mobile user or mobile device also refers as the cloud client application deployed on the smartphone which is used to encrypt and upload the user file on the cloud storage. There are two types of cloud client applications that are executed on the mobile device and utilize the cloud resources. The types of cloud client applications are (a) embedded browser application and (b) native mobile application. The embedded browser application uses the standard web development languages, such as HTML and JavaScript to utilize the cloud resources. The native mobile applications are developed in mobile application development tools, such as BlackBerry JDE 7.0.0 or Android SDK. For interacting and utilization of cloud resources, the native mobile application utilizes the cloud provider’s API. The mobile devices (e.g. smartphones, tablets, wireless sensor nodes) have computational, data storage, and wireless communication capabilities. The cloud service provider is accountable to offer computational and storage services for the mobile users. In this study, we are providing a secure data storage services for mobile user in the cloud environment.
123
956
A. N. Khan et al.
3.1 Connectivity and services The system under study is a public cloud operating a centralized data center that is accessed by the mobile users through wireless Internet connectivity. The communication channel between the mobile device and cloud service provider consists of one or more wired/wireless hop(s). The cloud client application communicates with the cloud service provider for the utilization of cloud storage services through http post method. Alternatively, the cloud client application may use the remote APIs for reading and writing the files stored on the cloud storage. 3.2 Trust model The trust model identifies the components that are assumed to be fully trusted, semi trusted, or distrusted to provide security features in mobile cloud computing environment. Semi trusted means some functions are assumed to be done perfectly but some may be compromised like storage may be exposed but computation is properly conducted. The mobile device is considered as a trusted entity in the system. The mobile user can take precautionary measures to avoid the malicious activities on a mobile device. Few of the existing schemes assumed cloud as a semi-trusted entity to implement the security solution accurately. In our system model, the cloud is assumed as a fully untrusted entity. 4 Block-based sharing scheme (BSS) for MCC The main objective of this research study is to developed a novel cryptographic technique, namely Block-based Sharing Scheme (BSS), based on the all methods presented in [12], to improve the security features of the existing methodologies and to reduce the energy utilized by the mobile user, which may extend the battery life of the mobile device. In BSS method, the users’ files are logically divided into multiple blocks and the message authentication code is used as a hash code. To keep the processing lightweight, xor operations are used to achieve the confidentiality. The involvement of the password in generating the secrecy code keeps the scheme compromise resilient. The comparatively light supporting operations are used in BSS for generating the secrecy codes. In addition, the BSS provides confidentiality and integrity services to mobile users for the files stored on the cloud server(s) with minimum processing, storage, and communication overhead. The main concept of the BSS is presented in Fig. 3. The mobile user is responsible for (a) generating extended password, (b) dividing file into chunks, (c) file encryption, and (d) decryption of the encrypted blocks and re-generation of the original file. The CSP is accountable for (a) receiving files from the mobile users, (b) storing the received files, and, (c) delivering the files to mobile users when requested. The extended password generation, encryption, and decryption procedures are discussed in the following paragraphs. Extended password generation: To achieve confidentiality for mobile users in the cloud environment, a secure key for encryption and decryption of the file blocks must
123
Data security in mobile cloud environment
957
Fig. 3 The general framework of BSS method
be generated. In BSS method, this key is defined as an extended password ( xPWD), which is the result of simple extension of a secret password generated by the mobile user. The number of bits in the original password generated by the user (the password size) should be not greater than the number of bits in a biggest file’s block. Usually the passwords generated by the users are rather short (up to 6–10 characters, which can be encoded into a binary string of 48–80 bits). On the other hand, the size of the block of the original file (data) should not be too small. The complexity of the proposed methodology strictly depends on the number of the data blocks generated for the chaining encryption procedure. In this paper we assume that the original file is divided into the equal-size d blocks of the n bits, so the following condition must be satisfied: FS % d = 0 (16) where FS denotes file size. In practice, to guarantee this symmetric file defragmentation, usually some extra bits must be padded at the end of the file. In order to explain the generation of the extended password, let us first introduce the following notation: • s—a number of characters in original password generated by the user; • i 1 . . . i s —a string of decimal ASCII indexes of the Latin symbols and characters in the user’s password, (0 ≤ i j ≤ 255 for j = 1, . . .,s); • Bin j : {0, . . . , 255} i j → { j1 . . . j8 } ∈ {0, 1}8 is a binary encoding function, which encodes the indexes of the characters in the user’s password into the binary
123
958
• • • •
A. N. Khan et al.
strings { j1 ... j8 } of the length 8 (note that 0 ≤ i j ≤ 255 for all considered values of j); p = s · 8 —a number of bits in the password generated by the mobile user, ( p ≤ n); M ∈ {1, . . . , m = n/ p t}—a number of steps in the password extension procedure and ∗ denotes the greatest integer less than or equal to *, for simplicity, it is assumed that ‘n’ is a multiplication of 8, so n/p is an integer number; Shift M : {0, . . . , 255} i j → i j + M(mod256) ∈ {0, . . . , 255} ( j = 1, . . . , s) denotes a shift function, which shifts the indexes of the characters in the user’s password by M positions in the ASCII table. ShiftBIN−R : {0, 1}n i j+1 → i j denotes a binary right shift function, which shifts the indexes of the bits in the user’s extended password by one position in right direction. If the right most bit ‘i n ’ of the extended password is zero, the first bit ‘i 1 ’ of the extended password is replaced with one, and otherwise it is replaced with zero.
M is a global parameter of the password extension procedure and in fact determines the complexity of this operation. The process of generation of the extended password can be defined as follows: Step 1: M = 1 and for each character in the user’s password the ‘next position’ character in the ASCII table is generated, that is to say: i j → Shift 1 (i j ), ( j = 1, 2, 3, . . . . . . . . . , s)
(17)
The new version of the password is composed by using the ‘shifted’ indexes and is defined as follows: Shift1 (i 1 ) || Shift 1 (i 2 )||Shift1 (i 3 )|| . . . . . . . . . ||Shift1 (i s )
(18)
The binary representation of this string can be expressed as follows: Bin1 (Shift1 (i 1 )) || Bin2 (Shift1 (i 2 ))||Bin3 (Shift 1 (i 3 ))|| . . . . . . . . . ||Bins (Shift 1 (i s )) (19) The length of this binary string is p bits. Step 2: M = 2 and for each character in the password generated in Step 1, the index is shifted by 2 positions in the ASCII table and a news string of ‘s’ characters is generated and then concatenated with an actual password (generated in the previous step), that is to say: Shift1 (i j ) → Shift2 (Shift1 (i j )), ( j = 1, 2, 3, . . . . . . . . . ., s)
(20)
and Shift1 (i 1 ) || . . . .||Shift1 (i s )||Shift2 (Shift1 (i 1 ))|| . . . ..||Shift2 (Shift1 (i s ))
123
(21)
Data security in mobile cloud environment
959
Fig. 4 Extension of the ‘a21fbj’ password from 48 bits into 160 bits
The length of the password string is extended to 2s and 2 p bits and its binary representation can be defined as follows: Bin1 (Shift1 (i 1 )) || . . . .||Bins (Shift1 (i s ))||Bin1 (Shift2 (Shift1 (i 1 ))) || . . . ..||Bins (Shift2 (Shift1 (i s )))
(22)
Finally, the condition 2. p ≤ n is verified. In the case of failure of the verification procedure (the inequality is false), the password extension procedure must be stopped and the extended password is defined in Eqs. (21) and (22). Otherwise, the value of M must be increased (to M = 3) and Step 2 must be repeated for the password defined in Eq. (20). In each next execution of the Step 2, the length of the previously generated password is extended twice. The procedure in Step 2 is repeated until the length of the extended password achieves the length (the number of bits) of the file (data) block. The process of generation the extended password based on the initial user password ‘ a21fbj’ for s = 6, n = 128 and M = 3 is illustrated in Fig. 4. Encryption phase: To encrypt a file, the mobile user, based on the extended password xPWD, generates the different encryption keys for each of ‘d’ chunks of the file using the xor operation in the following way: K i = xPWDi−1 ⊕ Ci−1 , where C0 = IV, xPWD0 = xPWD and d ≥ i ≥ 1 xPWDi = Shift BIN−R (xPWDi−1 ), where d ≥ i ≥ 1
(23) (24)
IV is the representation of initial vector generated randomly and stored on the mobile device’s memory (the length of this string must be equal to the length of the binary representation of xPWD). In each key generation phase, new extended password is generated to ensure the active involvement of the password in encryption process. The repeated usage of the similar xPWD in keys generation process eliminate the effect of xPWD on few encrypted blocks due to the fact that xPWD ⊕ xPWD = 0. The
123
960
A. N. Khan et al.
Fig. 5 Encryption process of the BSS
generated keys are used to encrypt each chunk of file as follows: Ci = K i ⊕ Bi , where d ≥ i ≥ 1
(25)
where Bi denotes the binary representation of the ith chunk of the original file. The whole chain encryption process is illustrated in Fig. 5. The BSS method uses the hash-based message authentication code with a secret integrity key to confirm the integrity of the uploaded files. The mobile user generates the integrity key by applying the standard hash functions, such as secure hash algorithm (SHA) or, on a bit string which is a result of simple concatenation of binary representations of the file name ( FN), xPWD, and file size ( FS), that is: IK = H (FN||xPWD||FS)
(26)
where H denotes hash function. The generated integrity key together with the original file is used to generate a hash-based message authentication code (MAC), that is to say: (27) MAC = HMAC H (F, IK) The mobile user uploads the encrypted file together with corresponding H(FN) (the same hash function is used here) and MAC to the cloud storage. For security purposes, the mobile user saves the file name together with extra padded bits information in local file table and deletes integrity key, block keys, and original file. Decryption phase: For downloading a file, mobile user computes H(FN) and sends a downloading request together with H(FN) to CSP. The CSP identifies the corresponding encrypted file using received H(FN). The encrypted file together with message authentication code is sent to the mobile user. For decryption and verification of the downloaded file, the mobile user has to regenerate integrity key and block keys. The mobile user knows the password, but the password cannot be used to decrypt file. There is a need of transformation from password to extended password for generation of keys. The mobile user transforms the password into extended password using the procedure describes in Fig. 4. The extended password is used in decryption process as shown in Fig. 6.
123
Data security in mobile cloud environment
961
Fig. 6 Decryption process of the BSS
The decryption keys are generated using the following procedure: K i = xPWDi−1 ⊕ Ci−1 , where C0 = IV, xPWD0 = xPWD and d ≥ i ≥ 1 (28) xPWDi = ShiftBIN−R (xPWDi−1 ), where d ≥ i ≥ 1 (29) The generated keys are used to decrypt each chunk of file in the following way: Bi = K i ⊕ Ci , where d ≥ i ≥ 1
(30)
After getting the original file, mobile user regenerates integrity key and message authentication code as shown below: IK = H (FN||xPWD||FS) MAC = HMAC H (F, IK)
(31) (32)
To verify the integrity of the downloaded/decrypted file, the downloaded message authentication code is compared with the newly calculated message authentication code. The similarity of the message authentication codes ensures the integrity of the downloaded/decrypted file. For security reasons, the number of bits in extended password should be equal to the block size. If size of the extended password is less than block size, some portions of encrypted block remain unchanged during the encryption process. For any given plain text data block, the different ciphertext is generated even plaintext block contains same text pattern that makes the cryptanalyst attack difficult for adversary. The usage of different key for each plaintext block produces the different ciphertext at block level even different plaintext blocks contain same text pattern that makes the cryptanalyst attack more sophisticated. This becomes impractical for adversary to regenerate the original file without knowing the password. The mobile user stores information of file name along with the initialization vector which is used to download and decrypt the uploaded encrypt file. For our experiment, the size of the initial vector is equal to block size and generated on runtime using the fixed pattern. However, different value of the initialization vector for each file randomizes the ciphertext for similar pattern that makes the cryptanalysis difficult. In ideal situation, the size of the initialization
123
962
A. N. Khan et al.
vector should be equal to block size. However, this is not suitable for mobile user to store such a large initial value. Therefore, the size of the initialization vector is extended using the password extension method.
5 Empirical analysis In EnS, DES (encrypts/decrypts 64 bits data block using 56 bits key) and SHA-1 are used to provide confidentiality and integrity services to the mobile users. There is a need of 256 different keys to perform a brute-force attack. In CoS, coding vector matrix is used as a key. The coding vector matrix is generated on the basis of total number of chunks (t) in each part of file. For our experiment, the value of ‘t’ is kept ‘4’. Hence, the total characters in coding vector matrix are ‘4 ∗ 4’. The increase in size of coding vector also increases the turnaround time, processing, and energy in completing the request due to more multiplication and addition operations. The ShS achieves confidentiality using simple xor operations on randomly generated shares without the involvement of key. The adversary can regenerate the original file by applying the simple xor operations on each share. In BSS, the password is transformed into extended password. The extended password is converted into key for achieving confidentiality. Hence, the size of the key is equal to block size. For our experiment, the minimum value of the extended password in 2, 097, 152 bits and maximum value is 10, 485, 760 bits. The adversary needs to generate minimum 22,097,152 and maximum 210,485,760 keys to perform a brute-force attack only for single block. Hence, there is need of large number of keys to affect the confidentiality of the users in the proposed scheme that seems to be impractical. Alternately, the adversary may perform attack on the basis of the password given by the owner of the file. The normal password 20 size 28∗i rang form 8 to 20 characters. In that case, adversary needs to try maximum i=6 combination for decrypting the file. Even in the second case, the adversary need to try more combination as compared to the existing schemes. The analysis of security schemes is presented in Table 3.
5.1 Experimental setup To evaluate the resource utilization on the mobile device, we developed the mobile applications using BlackBerry JDE 7.0.0 that encrypt/decrypt the dataset given in Table 5 using EnS, CoS, ShS, and BSS, and upload/download the same dataset on/from the cloud storage. The implemented secure applications (also referred as cloud Table 3 Analysis of security schemes EnS (using DES)
CoS
ShS
BSS
Min
Max
Min
Max
Min
Max
Key size
56
128
128
N/A
N/A
2,097,152
10,485,760
Attack steps
256
2128
2128
–
–
22,097,152
210,485,760
123
Data security in mobile cloud environment Table 4 Hardware specifications of BlackBerry smartphone
Table 5 Dataset to evaluate the performance of the security schemes
963
BlackBerry 9900 CPU
1.2 GHz QC 8655
RAM
768 MB
Storage
8 GB
OS
BlackBerry OS 7.0
Battery
1,230 mAh
Mobile application development toolkit
BlackBerry JDE 7.0.0
Internet connectivity
Wi-Fi
No.
File size
Total files
1
1,048,576 bytes = 1.0 MB
50
2
1,572,864 bytes = 1.5 MB
50
3
2,097,152 bytes = 2.0 MB
50
4
2,621,440 bytes = 2.5 MB
50
5
3,145,728 bytes = 3.0 MB
50
6
3,670,016 bytes = 3.5 MB
50
7
4,194,304 bytes = 4.0 MB
50
8
4,718,592 bytes = 4.5 MB
50
9
5,242,880 bytes = 5.0 MB
50
client applications) are deployed in BlackBerry 9900 smartphone using BlackBerry Desktop Application software. On the cloud side, a single web instance of class ‘F4’ comprising 2.4 GHz processor with512 MB RAM is hosted on Google App Engine ( GAE). The hosted web instant uses the AppEngineFile API [32] for accessing the Google Cloud Storage services. The cloud client application communicates with the web instant hosted on GAE through http post method for utilization of the Google Cloud Storage. Alternatively, the cloud client application may use the remote APIs, such as appengine-api.jar and appengine-remote-api.jar for reading the files stored on the Google Cloud Storage [33]. However, the remote APIs do not provide support for writing the contents on the remote cloud storage. For the experiment, we used http post method for accessing and storing the data on the Google Cloud Storage. The hardware specifications of the BlackBerry 9900 are presented in Table 4.
5.2 Results and discussion EnS, CoS, ShS, and BSS are evaluated on the basis of (a) encryption time, (b) decryption time, (c) CPU utilization, (d) memory utilization, (e) turnaround time, and (f) energy consumption while performing encryption, decryption, uploading, and downloading operations on the dataset given in Table 5. Each experiment is performed ten times and the average results are presented in the graphs. In most of the graphs, the x-axis shows the single file size along with the total
123
964
A. N. Khan et al.
Fig. 7 Time required for core encryption operation
number of files that are involved in experiment and y-axis represents corresponding turnaround time or energy consumption. Some of the discussed data security schemes require less processing but involve communication overhead that consume considerable amount of energy. Moreover, few schemes require less processing in core encryption and decryption operations but involve massive supporting operations for completing the encryption/decryption task, such as division of files into chunks in CoS, generation of coding vector in CoS, and creation of shares in ShS are the examples of supporting operations. Therefore, we have evaluated the results with and without the involvement of the supporting operations to study the behavior of each scheme. Moreover, CoS, ShS, and BSS divide the files into chunks or generate random shares to encrypt/decrypt the files. For most of the experiments, the value of the total number of chunks/shares is kept four. However, the effect of the variation in number of chunks/shares on turnaround time and energy consumption is also presented in the study. 5.2.1 Encryption/decryption time In this experiment, we have evaluated the time required to complete the core encryption/decryption operations on the dataset given in Table 5. The communication time and time required to complete the supporting operations are not included in this experiment. Therefore, the encryption/decryption time is evaluated as: Encryption/Decryption Time (EDT) = Ted + Thmac
(33)
where Ted indicates the time required to perform core encryption/decryption operation and Thmac denotes the time required to generate and verify the message authentication code. Figures 7 and 8 show the time required to complete core encryption/decryption operation for each scheme.
123
Data security in mobile cloud environment
965
Fig. 8 Time required for core decryption operation
Due to the complex operations involve in standard cryptography function, the authors in [12] claim that EnS requires more processing that ultimately results in more time to complete the requests as compared to the existing schemes. However, the experimental results show that the EnS requires less time as compared to CoS to complete the requests. In our experiment for EnS, we used DES algorithm that contains shift, permutation, and substitution operations to encrypt/decrypt a file. Alternatively, the CoS is based on matrix multiplication for encryption and decryption of the files. The matrix multiplication operation is computationally intensive and time consuming as compared to shift operation, permutation operation, and substitution operation, therefore CoS consume more time as compared to EnS in completing the core encryption/decryption requests. However, the usage of other traditional cryptographic algorithms in EnS may produce different results as compared to EnS with DES. The ShS further reduces the request completion time as compared to EnS and CoS by using light-weight xor operations on randomly generated shares having size equal to the original file for encrypting/decrypting the dataset. Instead of applying xor operations on multiple shares, BSS performs xor operations on logically divided chunks of the files. BSS requires less number of xor operations for encrypting/decrypting the dataset as compared to ShS. The reduction in xor operations while performing the core encryption/decryption operation in BSS improves the request completion time as compared to the existing schemes. 5.2.2 Impact of increase in shares/chunks on encryption time CoS, ShS, and BSS schemes are dependent on number of chunks/shares to perform encryption and decryption operations. The CoS physically divides the files into chunks, the ShS generates the multiple shares, and BSS logically partitions the files into chunks to perform encryption/decryption operations. Figures 9 and 10 show the impact of variable shares/chunks on time and energy consumption excluding communication overhead. The experiment is performed ten times on 10 files of size 5 MB. The
123
966
A. N. Khan et al.
Fig. 9 Completion time with variable number of chunks/shares
Fig. 10 Energy consumption with variable number of chunks/shares
average results are presented in the Figs. 9 and 10. The time and energy consumption are evaluated using Eqs. (34) and (35), respectively. Time (T ) = Tr + Te + TSupp
(34)
where Tr stands for the files reading time, Te indicates the encryption time, and TSupp denotes the time required to complete the supporting operations. Energy Consumption (EC) = E r + E e + E Supp
(35)
Similarly, E r stands for the energy consumption in files reading time, E e indicates the energy consumption in encryption, and E Supp denotes the energy consumption in completing the supporting operations. CoS and ShS show an increase in time and energy consumption with increase in total number of chunks/shares. If there is an increase in number of chunks for CoS, the size of the coding vector matrix also grows. The increase in the coding vector matrix involves additional multiplication and addition operations that ultimately results in increased request completion time and energy consumption. The increasing number
123
Data security in mobile cloud environment
967
Table 6 CPU utilization and memory consumption EnS
CoS
ShS
BSS
Average memory utilization (MB) 1
50.97188
57.92142857
35.7921875
65.26923077
2
49.38125
59.53333333
33.40666667
65.18333333
3
45.38438
56.64166667
33.39180328
59.50769231
Average
48.57917
58.03214286
34.19688582
63.32008547
Average CPU utilization (%) 1
82.88462
83.59171598
87.32824427
82.35892857
2
84.89241
84.03529412
85.20879121
83.6
3
83.6519
83.49404762
86.28464419
80.56140351
Average
83.80964
83.70701924
86.27389323
82.17344403
of chunks for the files in ShS involves more generation of random shares/files. The increasing number of random shares/files also increases the xor operations required for encryption and results in more time and more energy consumption for completing the request as compared to the rest of schemes. The BSS logically divides the file into chunks and extends the password equal to size of the chunk. The total number of xor operation remains same with variable number of chunks. The major factor that reduces the time and energy consumption in BSS is the generation of extended password. The size of the extended password is dependent on the chunk size. If the chunk size decreases, it will take less time and comparatively less resources to generate the extended password. The increase in total number of chunks reduces the chunks’ size that improves the extended password generation process in terms of time and energy consumption. The improvement in extended password generation process also improves the performance of BSS in terms of energy consumption and request completion time as compared to the existing schemes.
5.2.3 CPU utilization and memory consumption The BlackBerry’s application management software is used to evaluate the CPU utilization and memory consumption on the mobile device for each selected security scheme. The experiments are performed three times on 10 text files each having 5 MB size. The results are presented in Table 6. The BlackBerry’s application management software provides the information regarding the CPU utilization and memory consumption of each running application around every second. The CPU utilization and memory consumption information is gathered for every second and average results are presented in Table 3. The CPU utilization of the presented schemes is almost identical but there is a variation in memory usage. The CPU utilization and memory consumption parameters do not clearly identify the energy-efficient scheme. The important parameter that needs to be considered for identifying the energy-efficient scheme is the time to which these resources
123
968
A. N. Khan et al.
Fig. 11 Turnaround time for uploading
are kept busy. Figures 11, 12, 13, and 14 show the total request completion time and energy consumption for each scheme that help to identify the energy-efficient scheme. 5.2.4 Turnaround time The time required to complete the uploading/downloading of the dataset given in Table 5 is referred as turnaround time. The turnaround time includes files reading/writing time, core encryption/decryption operation time, time required for transmission/communication, and time required to perform supporting operations. The turnaround time is evaluated as: Turnaround Time (TT) = TComm + Trw + Ted + TSupp
(36)
where TComm represents the communication time of uploading or downloading, Trw stands for the files reading or writing time, Ted indicates the encryption or decryption time, and TSupp denotes the time required to complete the supporting operations. Figures 11 and 12 show the turnaround time for uploading and downloading the dataset, respectively. The authors in [12] claim that the ShS completes the encryption/decryption tasks more rapidly as compared to EnS and CoS due to the involvement of light-weight core encryption /decryption operations. However, the experimental result shows that the ShS takes more time to complete the encryption/decryption and uploading/downloading process as compared to rest of the schemes. Although the core encryption/decryption operations required for ShS are light-weight, however the supporting operations required for encryption/decryption are time consuming and computational intensive, such as random shares generation and uploading/downloading of shares on the cloud storage for each file. Due to the involvement of time consuming and computational intensive supporting operations, ShS takes more time to complete the requests. Moreover, there is a significant difference in turnaround time among the ShS and the rest of the schemes while uploading the dataset. However, there is a minor difference in turnaround time among the ShS and the rest of the schemes
123
Data security in mobile cloud environment
969
Fig. 12 Turnaround time for downloading
Fig. 13 Energy consumption for uploading
Fig. 14 Energy consumption for downloading
123
970
A. N. Khan et al.
while downloading the same dataset. The uploading process takes more time due to the involvement of additional shares generation operation that mobile user has to perform. However, the downloading process only involves reception of shares from CSP as a supporting operation. Therefore, the graphs show the significant variation in turnaround time during uploading and downloading while working on the same dataset. We found the same behavior of the EnS and CoS as discussed in Sect. 5.2.1. The BSS reduces the supporting operations overhead by logically dividing the files into chunks. The logically divided chunks are encrypted or decrypted with xor operations. The mobile user only needs to upload or download single encrypted file. Hence, the involvement of light-weight operations, minimum supporting tasks, and transfer of single encrypted file results in improved turnaround time as compared to existing schemes. 5.2.5 Energy consumption This section analyzes the total energy consumed to complete the files’ uploading or downloading requests. The energy consumption is evaluated using BlackBerry’s API (i.e. DeviceInfo) [34]. The API provides percentage information about the current battery status. For each scheme, the status of the battery is noted before and after uploading/downloading operation to evaluate the battery utilization. Figures 13 and 14 show the total energy consumption for uploading and downloading of files, respectively. In Fig. 13, there is significant difference in energy consumption among the ShS and other schemes. In contrast, Fig. 14 shows the minor difference in energy consumption among the ShS and other schemes. The variation in energy consumption while uploading and downloading is due to the supporting operations as discussed in case of turnaround time. The BSS reduces the supporting operations overhead by logically dividing the files into chunks. The logically divided chunks are encrypted or decrypted with xor operations. The mobile user only needs to upload or download single encrypted file. Hence, the usage of light-weight operations, minimum supporting tasks, and transfer of single encrypted file results in improved energy consumption.
6 Validation of the BSS The validation of the scheme is carried out using two methods. In first method, the BSS is validated with the satisfaction of the following equality. HMACSHA−1 (F) = HMACSHA−1 (BSSDecryption (Ci )), where d ≥ i ≥ 1
(37)
The message authentication code is generated for the original file. The encrypted version of the same file is downloaded from the cloud server. The encrypted version of the file is decrypted using the BSS decryption method. Afterwards, message authentication code is generated on the decrypted file to verify the aforementioned equality.
123
Data security in mobile cloud environment
971
Table 7 Data types for BSS Data type
Description
F
A string representing the file for uploading to cloud
FN
A string representing file name
FS
A string representing file size
d
Total number of blocks
Blist
A list of length d storing blocks of file
pwd
A string representing user password
xPWD
A string representing extended user password
xPWDlist
A list of length d storing modified extended passwords for key generation
IV
A string representing initialization vector
i
A number with initial value, one
Klist
A list of length d storing keys for encryption
Clist
A list of length d storing cipher text of blocks
IK
A string denoting integrity key
MAC
A string denoting message authentication code
HFN
A string representing hash value of FN
In second method, the BSS is validated with the satisfaction of the following equality. (38) F = BSSDecryption (BSSEncryption (Bi )), where d ≥ i ≥ 1 The original file is divided into blocks and each block is encrypted with BSS encryption method. The encrypted blocks are decrypted with the BSS decryption methods. Afterward, decrypted file is compared with the original file to verify the aforementioned equality. The experiments are performed multiple times to validate BSS using dataset given in Table 5. Each time the equalities of aforementioned equations are satisfied that confirms the validity of BSS.
6.1 Formal analysis and verification of the BSS 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. In this paper, we use bounded model checking to verify proposed BSS [35,36]. The HLPN representation of BSS is depicted in Fig. 15. For development of petri net model, we have identified data types, places, and mappings of data types to places. Tables 7 and 8 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 (Fig. 14).
123
972
A. N. Khan et al.
Table 8 Places and mappings used in HLPN model of BSS Place
Mapping
ϕ(User)
P(F × d × FN × FS × Blist × pwd × xPWD × xpwdlist × i × IV × Klist × Clist × IK × MAC × HFN)
ϕ(Cloud)
P(Clist × MAC × HFN)
Fig. 15 Petri net model for BSS
Initially the file that is to be uploaded to the cloud is divided into d number of equal size blocks. The operation is depicted by the transition Dvd_File and is given by the following formula: R(Dvd_File) = ∀ x1 ∈ X 1 | x1 [5] := Divide_File(x1 [1])|lengtho f (x1 [5]) = x1 [2] ∧
X 1 = X 1 ∪ {x1 [5]} The user password is extended according to the process given in Sect. 4. The following rule shows the operation: R(ext_ pwd) = ∀ x2 ∈ X 2 | x2 [7] := Gen_x pwd(x2 [6])|lengtho f (x2 [7] = lengtho f (x2 [5][1]) ∧
X 2 = X 2 ∪ x2 [7]}
123
Data security in mobile cloud environment
973
The encryption keys are generated using similar procedure discussed above. Key generation process is represented by the following transition and associates rule: R(Gen_K ey) = ∀ x3 ∈ X 3 , | i f (x3 [9] = 1) x3 [11][x3 [9]] := x3 [7] ⊕ x3 [10] else x3 [11][x3 [9]] := x3 [8][x3 [9] − 1] ⊕ x3 [12][x3 [9] − 1] ∧ x3 [8][x3 [9]] := Shi f t B I N R (x3 [8][x3 [9]]) ∧ x3 [9] := x3 [9] + 1 ∧
X 3 = X 3 ∪ {x3 [11], x3 [8], x3 [9]} Each file block is encrypted with the different key. The transition Encr_File encrypts the file with the key generated by Gen_Key. Both the transitions are fired one after the other unless all the file blocks are encrypted. The following rule maps over the transition Encr_File: R(Encr _File) = ∀x4 ∈ X 4 | x4 [12][x4 [9]] := x4 [11][x4 [9]] ⊕ x4 [5][x4 [9]] ∧ X 4 = X 4 ∪ {x4 [12]} The generation of integrity key is denoted by the following: R(Gen_I K ) = ∀ x5 ∈ X 5 | x5 [13] := H ash(concat (x5 [3], x5 [7], x5 [4]) ∧ X 5 = X 5 ∪ {x5 [13]} To ensure the integrity of the file, MAC is generated. The hash value of file name is also generated to be stored on the cloud to let the cloud identify the file. The following rules perform the aforesaid operation: R(Gen_M AC_H F N ) = ∀ x6 ∈ X 6 | x6 [14] := cal_M AC(x6 [1], x6 [13]) ∧ x6 [15] := H ash(x6 [3]) ∧
X 6 = X 6 ∪ {x6 [14], x6 [15])} The ciphertext of file blocks along with MAC and hash value of file name is sent to the cloud according to following rule:
123
974
A. N. Khan et al.
R(Send) = ∀ x7 ∈ X 7 , ∀x8 ∈ X 8 | x8 [1] := x7 [12] ∧ x8 [2] := x7 [14] ∧ x8 [3] := x7 [15] ∧ X 8 = X 8 ∪ {x8 [1], x8 [2], x8 [3]} To download data, the user sends a request. The request contains the hash value of the required file name. This is done in the following rule: R(Req_data) = ∀x9 ∈ X 9 , ∀x10 ∈ X 10 | x10 [3] := x9 [15] ∧ X 10 = X 10 ∪ {x10 [3]} Upon receiving the request, the cloud searches for the received hash value and send the required data to the user: R(Rcv_data) = ∀x11 ∈ X 11 , ∀x12 ∈ X 12 | x12 [12] := x11 [1] ∧ x12 [14] := x11 [2] ∧
X 12 = X 12 ∪ {x12 [12], x12 [14]} At the user end, the keys are again calculated with the same procedure and transitions and file is decrypted: R(Decr _File) = ∀x13 ∈ X 13 | x13 [5][x13 [9]] := x13 [11][x13 [9]] ⊕ x13 [12][x13 [9]] ∧ X 13 = X 13 ∪ {x13 [5]} Verification property: The aim of verification was to ensure that the proposed system works according to the specifications and produce the results correctly. The property that is verified is following: • Encryption of the file at the mobile user site is done correctly and as specified by the system. • Decryption requests are handled correctly, and after decryption user gets the original data that was uploaded by the uploading user. 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.04 seconds to upload data of user after encryption and download.
123
Data security in mobile cloud environment
975
7 Conclusion and future work The BSS utilizes the preeminent features of existing schemes to reduce processing, storage, and communication overhead from the mobile device. In addition, the BSS provides better security services to the mobile user due to the following reasons: (a)a plaintext block containing the same text pattern are mapped into different ciphertext during the encryption due to key size and (b) the multiple plaintext blocks containing same text patterns are mapped into different ciphertext due to the usage of different keys for each plaintext block. The key size and usage of different keys for plaintext blocks make the cryptanalyst attack more sophisticated. Moreover, BSS considers password as a key component for the generation of blocks’ keys. The generated block keys are actively involved in encryption/decryption process. The password is only known to the mobile user and actively utilize in achieving confidentially and integrity for the mobile users that leads toward a more secure security scheme. Currently, we are working on extension of BSS for automatic sharing of files among groups of people. To make the BSS more energy efficient for mobile device, there should be a block insertion, deletion, and modification operations based on the incremental cryptography concept. Acknowledgments We would like to acknowledge the financial support of the BrightSparks Program at University of Malaya, Malaysia for carrying out these research experiments.
References 1. Khan AN et al (2013) Towards secure mobile cloud computing: a survey. Future Gener Comput Syst 29(5):1278–1299 2. Khan A et al (2013) A survey of mobile cloud computing application models. IEEE Commun Surv Tutor 16(1):393–413 3. Kumar K, Lu YH (2010) Cloud computing for mobile users: can offloading computation save energy? Computer 43(4):51–56 4. Fox A et al (2009) Above the clouds: a Berkeley view of cloud computing. In: Technical report UCB/EECS, Department Electrical Engineering and Computer Sciences, University of California, Berkeley, p 28 5. Hashemi SM, Ardakani MRM (2012) Taxonomy of the security aspects of cloud computing systems—a survey. Int J Appl Inf Syst 4(1):21–28 6. Juniper (2010) Technical report: Mobile cloud computing: $ 9.5 billion by 2014 . http://www. juniperresearch.com/reports/mobile_cloud_applications_and_services. Accessed 24 April 2013 7. Subashini S, Kavitha V (2011) A survey on security issues in service delivery models of cloud computing. J Netw Comput Appl 34(1):1–11 8. Santos N, Gummadi KP, Rodrigues R (2009) Towards trusted cloud computing. In: Proceedings of the 2009 conference on Hot topics in cloud computing. USENIX Association 9. Khan AN et al (2013) Enhanced dynamic credential generation scheme for protection of user identity in mobile-cloud computing. J Supercomput 66(3):1687–1706 10. Jia W et al (2011) SDSM: a secure data service mechanism in mobile cloud computing, In: IEEE conference on computer communications workshops (INFOCOM ’11). IEEE, Shanghai, pp 1060– 1065 11. Khan AN et al (2014) Incremental proxy re-encryption scheme for mobile cloud computing environment. J Supercomput 68(2):624–651 12. Ren W et al (2011) Lightweight and compromise resilient storage outsourcing with distributed secure accessibility in mobile cloud computing. Tsinghua Sci Technol 16(5):520–528
123
976
A. N. Khan et al.
13. Zhang X et al (2009) Securing elastic applications on mobile devices for cloud computing. In: Proceedings of the 2009 ACM workshop on cloud computing security 14. Xiao S, Gong W (2010) Mobility can help: protect user identity with dynamic credential. In: 2010 IEEE 11th international conference on mobile data management (MDM) 15. Chow R et al (2010) Authentication in the clouds: a framework and its application to mobile users. In: Proceedings of the 2010 ACM workshop on cloud computing security workshop 16. Huang D et al (2010) MobiCloud: building secure cloud framework for mobile computing and communication. In: 5th IEEE international symposium on service oriented system engineering (SOSE ’10), pp 27–34 17. Huang D et al (2011) Secure data processing framework for mobile cloud computing. In: IEEE conference on computer communications workshops (INFOCOM WKSHPS ‘11), pp 614–618 18. Chen YJ, Wang LC (2011) A security framework of group location-based mobile applications in cloud computing. In: 40th IEEE international conference on parallel processing workshops (ICPPW ’11) 19. Bilogrevic I et al (2011) Meetings through the cloud: privacy-preserving scheduling on mobile devices. J Syst Softw 84(11):1910–1927 20. Itani W, Kayssi A, Chehab A (2010) Energy-efficient incremental integrity for securing storage in mobile cloud computing. In: International conference on energy aware computing (ICEAC ’10), IEEE, Cairo, pp 1–2 21. Hsueh SC, Lin JY, Lin MY (2011) Secure cloud storage for convenient data archive of smart phones. In: IEEE 15th international symposium on consumer electronics (ISCE ’11), pp 156–161 22. Yang J et al (2011) Provable data possession of resource-constrained mobile devices in cloud computing. J Netw 6(7):1033–1040 23. Zhou Z, Huang D (2012) Efficient and secure data storage operations for mobile cloud computing. In: 8th international conference on network and service management (CNSM ’12). IEEE, AZ, pp 37–45 24. Yu S et al (2010) Achieving secure, scalable, and fine-grained data access control in cloud computing. In: Proceedings IEEE (INFOCOM ’10) 2010. IEEE, NJ, pp 1–9 25. Shao J, Cao Z (2009) CCA-secure proxy re-encryption without pairings. Public Key Cryptogr PKC 2009:357–376 26. Tysowski PK, Hasan MA (2011) Re-encryption-based key management towards secure and scalable mobile applications in clouds. In: IACR cryptology eprint archive, vol 668 27. Ateniese G et al (2006) Improved proxy re-encryption schemes with applications to secure distributed storage. ACM Trans Inf Syst Secur (TISSEC) 9(1):1–30 28. Bethencourt J, Sahai A, Waters B (2007) Ciphertext-policy attribute-based encryption. In: IEEE symposium on security and privacy (SP ’07) 29. Kim Y et al (2007) Key establishment scheme for sensor networks with low communication cost. Auton Trust Comput 441–448 30. Khan AN, Qureshi K, Khan S (2012) An intelligent approach of sniffer detection. Int Arab J Inf Technol 9(1):9–15 31. Khan AN, Qureshi K, Khan S (2009) Enhanced switched network sniffer detection technique based on IP packet routing. Inf Secur J Glob Perspect 18(4):153–162 32. Remote API for Java (2012) https://developers.google.com/appengine/docs/java/tools/ remoteapiConfiguring_Remote_API_on_an_App_Engine_Client. Accessed 12 August 2012 33. Google Cloud Storage Java API Overview (2012) https://developers.google.com/appengine/docs/java/ googlestorage/overview. Accessed 15 August 2012 34. DeviceInfo API (2012) http://www.blackberry.com/developers/docs/4.3.0api/net/rim/device/ api/system/DeviceInfo.html. http://www.salesforce.com/us/developer/docs/apexcode/index.htm Accessed 02 April 2012 35. Murata T (1989) Petri nets: properties, analysis and applications. Proc IEEE 77(4):541–580 36. de Moura L, Bjørner N (2009) Satisfiability modulo theories: an appetizer. In: Formal methods: foundations and applications. Springer, New York, pp 23–36
123
