Computer Networks 65 (2014) 99–110

Contents lists available at ScienceDirect

Computer Networks

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

Consolidated Identity Management System for secure mobilecloud computing

http://dx.doi.org/10.1016/j.comnet.2014.03.0151389-1286/� 2014 Elsevier B.V. All rights reserved.

⇑ Corresponding author. Tel.: +974 77495648.E-mail addresses: ikhalil@qf.org.qa (I. Khalil), abdallah@njit.edu

(A. Khreishah), Muhammad.azeem@uaeu.ac.ae (M. Azeem).

Issa Khalil a,⇑, Abdallah Khreishah b, Muhammad Azeem c

a Qatar Computing Research Institute (QCRI), Qatar Foundation, Doha, Qatarb Newark College of Engineering, New Jersey Institute of Technology, University Heights, Newark, NJ 07102, United Statesc College of Information Technology, United Arab Emirate University, Al Ain, United Arab Emirates

a r t i c l e i n f o

Article history:Received 29 August 2013Received in revised form 26 January 2014Accepted 19 March 2014Available online 25 March 2014

Keywords:Cloud computing securityPrivacyMobile clientsIdentity Management SystemsSecurity attacks

a b s t r a c t

Security issues in cloud computing are shown to be the biggest obstacle that could lowerthe wide benefits of the cloud systems. This obstacle may be strengthened when cloud ser-vices are accessed by mobile devices. Mobile devices could be easily lost or stolen andhence, they are easy to compromise. Additionally, mobile users tend to store access creden-tials, passwords and other Personal Identifiable Information (PII) in an improperly pro-tected way. We conduct a survey and found that more than 66% of the surveyed usersstore PIIs in unprotected text files, cookies, or applications. To strengthen the legitimateaccess process over the clouds and to facilitate authentication and authorization with mul-tiple cloud service providers, third-party Identity Management Systems (IDMs) have beenproposed and implemented. In this paper, we discuss the limitations of the state-of-the-artcloud IDMs with respect to mobile clients. Specifically, we show that the current IDMs arevulnerable to three attacks, namely – IDM server compromise, mobile device compromise,and network traffic interception. Most importantly, we propose and validate a new IDMarchitecture dubbed Consolidated IDM (CIDM) that countermeasures these attacks. Weconduct experiments to evaluate the performance and the security guarantees of CIDMand compare them with those of current IDM systems. Our experiments show that CIDMprovides its clients with better security guarantees and that it has less energy and commu-nication overhead compared to the current IDM systems.

� 2014 Elsevier B.V. All rights reserved.

1. Introduction

In the early age of computers, computational tasks wereperformed on mainframe computers. Large companiessuch as IBM, Amdahl and Hitachi owned these mainframecomputers. These companies provided computational ser-vices to customers where it takes hours, sometimes, evendays, in order to get the results. Cloud computingintroduces similar concepts by utilizing hardware pooling

and virtualization concepts to offer computational servicesover the Internet and other private/public networks[39,40]. It, thus, represents one of the contemporary keytechnological advances that enable the delivery ofcomputing resources in a way similar to the deliveryof utility-based services. Mobility is also consideredanother important contemporary key technological stepthat shifts the trend in client devices from PCs to smart-phones, laptops, tablets, etc. [1]. There is a dramatic in-crease in the number of users with wireless smartphonedevices and in the number of public access points used toconnect to the cloud [2–4,38]. Mobile devices are becom-ing more sophisticated and soon will replace PCs to

100 I. Khalil et al. / Computer Networks 65 (2014) 99–110

perform traditional and cloud computations as they pro-vide the convenience of anywhere, anytime access. Accord-ing to Digital buzz, the 2013 mobile growth statistics showthat 91% of all people on earth have a mobile phone, 50% ofmobile phone users, use mobile as their primary Internetsource, and 72% of tablet owners purchase online fromtheir tablets each year [5]. This increase is also contributedto the fact that mobile computing has made business easierand less costly by eliminating the need for on-site informa-tion systems [6].

However, the convenience offered by mobile devices isaccompanied by many security challenges and introduceswide range of vulnerabilities, especially in the area of ac-cess control and identity management. Recent figuresshow that mobile malicious code has advanced greatly[7] and that the number of incidences of malware injec-tions, especially for credential theft, is on rise [8]. Mostenterprises are aware of the security challenges and oper-ational vulnerabilities that could be introduced by allow-ing access to mobile clients. At the same time, corporatesecurity officers realize that preventing users from usingtheir mobile devices is a losing battle against convenience.Unfortunately, mobile software developers (application/system software) do not consider mobility threats duringthe software development life cycle and this is why, orga-nizations and individuals are on their own to secure theirinformation. Users who are not aware of the securitythreats introduced by mobile devices are evidently at risk.

Unauthorized access is one of the major security chal-lenges introduced by mobility, which signifies a seriousthreat to clouds. Mobile devices increase the probabilityof unauthorized access due to many different facts. First,mobile devices use wireless communication which is eas-ier to intercept and analyze compared to the wired coun-terpart. Second, it is relatively easy to lose or steal amobile device, and hence it is easy to capture and compro-mise. Third, many mobile users tend to store access cre-dentials, passwords, Personal Identifiable Information(PII), and other valuable digital assets in an improperlyprotected way and hence, easy to collect. We conduct asurvey (Section 4.2) and found that more than 66% of thesurveyed users store PIIs either in text files, cookies, orapplications in an easily accessible format. Fourth, as mo-bile devices roam from one network to another, they mayconnect to improperly protected networks and access re-mote untrusted sites that could disseminate malware.Combining all these facts with the proliferation of mobiledevices make them attractive targets to obtain unautho-rized access. Therefore, it is an urgent priority to developand implement reliable, secure and efficient access man-agement systems that cope with the mobility challenges.

Many techniques have been developed to control theunauthorized access to cloud services and data. One ofthe most widely used security techniques in that directionis the control of user access through proper access manage-ment systems. However, proper access management sys-tems rely on proper Identity Management Systems (IDMs)for identity generation, authentication, and authorization.IDMs are mainly designed to maintain the integrity of cyberidentities throughout their life cycle to make them andtheir related data (e.g., authentication and authorization

results) available to different services in a secure, reliableand privacy-protected manner. IDMs are also responsiblefor identity management tasks such as allowing an iden-tity’s subject to establish links between her various identi-ties. These links can further be used for different services,across geographical, temporal and organizational borders.This IDM feature has been called an identity federation[9]. The federation refers to the group of organizations thatare responsible for establishing trust among them tocooperate safely in business. The particular type of user’sauthentication such as ‘‘Single Sign-On’’ is an example offederated identity systems [10]. However, Single Sign-Onservice introduces vulnerabilities that can lead to seriousattacks if user’s identity has been compromised. With onetime successful sign-in, the illegitimate user will not be ver-ified again, resulting in higher level of information leakage.

Fig. 1 represents a generic architecture of current IDMs.The architecture consists of three players – the client, thecloud service provider (CSP), and the IDM provider. Thesteps involved in acquiring access to a CSP are: (1) The userlogin to the IDM provider with her pre-assigned usernameand password, (2) the user requests to access cloud appli-cation/data from the CSP, (3) the CSP asks for a token, (4)the user requests a token from the IDM provider, (5) theIDM provider generates a token and sends it to both theuser and the CSP, (6) the user forwards the token receivedfrom the IDM to the CSP, (7) the CSP compares the tokensreceived from the user and the IDM provider, and (8) onsuccessful comparison, the cloud allows the user to accessthe requested data or application.

Researchers and practitioners have implemented manyflavors of IDMs. However, the security and privacy issuesintroduced when traditional IDMs are used to serve mobileclients have not been sufficiently addressed. Our analysisand experiments show that the current IDMs do not provideadequate security guarantees for mobile cloud computing.In this paper, we initially discuss the security vulnerabilitiesand the privacy issues of the current traditional IDMs, espe-cially in mobile client environments. Then, we propose andevaluate a new IDM architecture dubbed Consolidated IDM(CIDM) that addresses the coupled challenges of mobilityand identity management in mobile cloud computing. Inthis work, we assume an attack model in which the attack-er’s goal is to gain unauthorized access on behalf of a legiti-mate user. Therefore, we do not consider DoS or DDoSattacks in which the attacker tries to prevent a legitimateuser from being able to prove its identity.

Up to our knowledge, we are the first to study and ad-dress the security and privacy threats introduced whenusing traditional IDMs to serve mobile cloud clients. Ourcontributions can be summarized as follows:

� Introduce and investigate the impact of three threatsagainst current IDMs, namely – IDM server compro-mise, mobile device compromise, and network trafficinterception. We explain each threat and show howcurrent IDMs are vulnerable to that threat.� Conduct extensive experiments and surveys to motivate

the need for developing and implementing reliable,secure and efficient access management systems thatcope with the mobility challenges.

Fig. 1. Generic IDM architecture.

I. Khalil et al. / Computer Networks 65 (2014) 99–110 101

� Propose a new IDM architecture dubbed ConsolidatedIDM (CIDM) that eliminates the vulnerabilities of thecurrent IDMs and addresses the unique security chal-lenges introduced when traditional IDMs are used toserve mobile clients.� Evaluate the performance, the overhead, and the secu-

rity guarantees of CIDM through practical experiments.In these experiments, we intentionally inject maliciouscode into the IDM server, intercept and analyze networktraffic, and compromise mobile client devices that con-tain sensitive credentials.

The rest of the paper is organized as follows. In Section2, we present the related work. In Section 3, we discuss thesecurity vulnerabilities of the current IDMs in mobile cloudcomputing environments. In Section 4, we present our pro-posed IDM architecture. In Section 5, we present ourexperimental setup and results. Finally, Section 6 con-cludes the paper.

2. Related work

OAuth [11] and OpenId [12] are two widely used imple-mentations of IDMs. In OAuth, the client obtains a token(string denoting a specific scope and limited lifetime) fromthe authorization server to access a resource, hosted on aresource server. For example, an end-user (resource own-er) can grant printing service (client) access to her pro-tected data, which is stored at a data-storage-server(resource server) without sharing her credentials (user-name/password). OAuth consists of four modules (roles):(1) resource owner (person/server that grant the accessof a protected resource), (2) resource server (the serverthat hosts the protected resource), (3) client (user/applica-tion that make request to access resource on behalf of

resource owner) and (4) authorization server (the serverresponsible to issue the token to the client).

Fig. 2 represents the following communication flow ofOAuth:

1. The client requests authorization from the resourceowner.

2. The client receives an authorization grant (credentialsthat represents the resource owner’s authentication).

3. The client provides authorization grant to authorizationserver and request for access token.

4. The authorization server authenticate the access tokenand after successful validation provides access token.

5. The client request the protected resource from aresource server by providing access token.

6. The server validates the token and on successful valida-tion, grants an access to the requested resource.

In [13], Khash Kiani presents four attacks against OAuthand its various implementations. The attacks are: Lack ofdata confidentiality and server trust, insecure storage ofsecrets, implementations with flawed session manage-ments, and session fixation attack. Moreover, it has beenshown in [14] that OAuth is vulnerable to the timing at-tacks. Furthermore, in the official specifications of OAuth,all the communications among OAuth modules (A–C inFig. 2) occur through the client [11]. Other communica-tions among OAuth modules are beyond the scope andirrelevant to the issues we address in this work. In mobileclient environments, the client is considered a serious sin-gle security point of failure due to being relatively easy tocompromise. This problem may render the whole OAuthprocess as vulnerable and useless. Even in non-mobileenvironments, threats arise in case one or more of thecommunication paths between the client and other OAuth

Fig. 2. OAuth protocol .

102 I. Khalil et al. / Computer Networks 65 (2014) 99–110

modules are compromised. The situation gets even worsein the case of mobile resource owners due to the higherprobability of compromise of the resource owner itself.The compromise of the resource owner or OAuth commu-nication paths could expose all the private data of theresource owner whether stored locally or on the cloud. InOAuth specification [11], the attacker is assumed to haveno access to the communication between the authorizationserver and the resource owner. If this assumption does nothold, the whole system becomes vulnerable. However, ifthe communication between the authorization server andthe resource owner is secured by encryption and authenti-cation mechanisms, the issue is alleviated and the assump-tion becomes irrelevant. In case of mobile device beingstolen, OAuth does not provide any mechanism to securethe data except that it encourages users to put key lockson their mobiles [11].

While OAuth provides authorization services (grantingan access of resource to a third party on behalf of theresource owner), authentication services (providing theevidence who you are) are provided by systems like Ope-nId [12]. OpenId facilitates login into multiple sitesthrough Single Sign-On. It has been shown in the litera-tures[15–17] that OpenId has many security weaknesses andvulnerable to malicious code attack. A malicious code in-jected on a server that uses OpenId can be used to forwardthe user to bogus identity provider authentication pagethat asks for credentials [16,17]. Similar to OAuth, OpenIdis also vulnerable to the timing attacks [14]. Many practi-tioners are promoting the use of OpenId with OAuth forbetter security. However, we claim that this combinationcould be lethal to user’s private data. If the authorizationserver (OAuth) is compromised, the Single Sign-On featureof OpenId becomes an advantage to the attacker since hecan access all resources/data on multiple sites.

Security vulnerabilities in IDMs are especially danger-ous in mobile cloud computing paradigms. Xiao and Gongin [18] claims that the current security mechanisms inmobile cloud computing environments are insufficient be-cause if the attacker is capable of faking/stealing user’scredentials then the cloud data is on stake for a largeclass of users. To alleviate the threat in mobile cloud

environments, the authors propose an algorithm that gen-erates dynamic identities. The algorithm performs well ifadequate security measures are implemented at serverlevel such as antiviruses, network firewalling and intrusiondetection systems. However, the algorithm fails if the sys-tem is compromised. Leandro et al. in [10] promoted theuse of Shibboleth as an access control system in cloudswithout the use of trusted third party (i.e., IDM server). Itprovides strong authorization but does not provide strongauthentication since once the user is authenticated, nomechanism is proposed to ensure the legitimacy of theconnected users. Therefore, an illegitimate user holding va-lid username and password can access the cloud servicesfor long periods of time without being verified. Moreover,Shibboleth does not guarantee secure transactions.

Some researchers (e.g., [10,19]) proposed an applica-tion-centric approach for users’ authentication. Thisapproach allows IDM server to keep track of users’ activi-ties to be able to authenticate users without revealing theiractual identities. Other researchers [2,6,20–22] modifyPC-based IDMs to secure user’s data on cloud, however,these modification fail to address the mobile securitychallenges.

3. Current IDMs vulnerabilities

We have identified three vulnerabilities in the architec-ture of the current IDMs (Fig. 1). The first vulnerability liesin the possibility of compromising IDM servers. ThroughIDM server compromise, we assume that the attacker cancapture any token from within the IDM servers. However,we assume that the attacker cannot affect the integrity ofthe tokens or generate new valid tokens. IDM server com-promise is a serious vulnerability that could create widescale attacks against all the clients of the compromisedIDM provider. This threat can be realized by various wayssuch as malicious insider involvement or malicious codeinjection.

In general, IDM servers are supposed to be hard to com-promise because they are likely to be protected by physicalsecurity measures, insider activity monitoring, tight accesscontrol measures, and regular logs and auditing practices.In spite of that, there were many recent practical attacks

Fig. 3. IDM communication paths that can be compromised.

I. Khalil et al. / Computer Networks 65 (2014) 99–110 103

against IDMs which resulted in devastating consequences.The most notable attack was the compromise of the RSA(the security division of EMC) SecurID two-way authenti-cation tokens. The attack costs EMC $81.3 to replace Secu-rID tokens, monitor customers, harden internal systems,and handle fallout from the security breach [23]. Moreimportantly, the attack leads to security breaches on manyhigh profile SecurID customers such as Lockheed Martin,Raytheon Co. (RTN), and Northrop Grumman Corp. (NOC).In another more recent attack (November 2013), hackersinfiltrated Adobe’s network and stole millions of customeremails and encrypted passwords [24]. The detection of theIDM server compromise could be complicated by the lackof human interaction among the CSP, the user and theIDM provider to continuously monitor and determine thelegitimacy of users. The lack of human interaction helpsmalicious users or code to get unauthorized access for rel-atively long periods of time before being possibly detected.

The second vulnerability lies in the ease of mobile devicecapture/compromise through theft, lost, or malicious mo-bile code injection. Mobile malicious malware becomes avery severe fast growing threat. This is obvious from the2013 mobile security report of ABI Research (a technologyintelligence firm) [8]. The report shows that 62,950 mobilemalware samples were identified by various security ven-dors (such as Kaspersky and MacAfee) in 2011 and 2012.This is not a passing phenomenon as many researchersand practitioners provide different ways to breach thesecurity of mobile devices and present practical examplesof successful attacks against various mobile platforms[4,7,25]. In [26], researchers at Georgia Tech presentedways to bypass the vetting process of Apple’s App Storeand subsequently showed how malicious USB chargerscan be used to infect Apple iOS devices [27]. In [28],researchers practically show how easy it is to fool AndroidOS by replacing a legitimate code with a malicious onewithout affecting the signature of the legitimate code.

Modern mobile devices facilitate Internet browsing,email exchange and provide a virtual work environment.However, many users may leave the virtual door open sothe work can be more flexible and beneficial, which maycreate serious threats. Virtual doors are becoming easierto access and abuse in mobile clients due mainly to thelack of physical protection. The proliferation of mobile de-vices force corporates to allow mobile device access to dataand services both to employees and customers since theyrealized that blocking them is a losing battle against con-venience. The negative impact on user’s security in thecase of illegal mobile device capture/compromise is two-fold: (1) Local private data stored on the device is exposed(most of the users usually save passwords and other sensi-tive data in their mobiles, refer to Section 4 for moredetails), and (2) any data or service (e.g., over the cloudor private corporates) that can be accessed by the creden-tials stored on the stolen device becomes vulnerable. Weclaim that enforcing simple real time human interactionssuch as answering the date-of-birth or any other securityquestion, during access, would boost the security of mobileclients. The required interaction hinders perpetratorswhen they try to access or use the sensitive data in a lostor stolen mobile device.

The third vulnerability lies in the possibility of inter-cepting and cryptanalyzing IDM messages while being ex-changed during the process of trust establishmentbetween the user and the CSP. If an attacker interceptsthe network traffic exchanged among the IDM provider,the CSP and the user, he can gain unauthorized access touser’s credentials. These credentials can further be usedto gain unauthorized access to cloud services and data.Fig. 3 shows the possible communication paths that couldbe compromised. Depending on the specific IDM imple-mentation (see the related work section, Section 2), someof these paths may not be sufficiently secure and therefore,traffic could be easily captured and cryptanalyzed. Even inthe case of properly encrypted communication paths, re-play attacks are still possible since the tokens could bemade valid for a relatively long period of time (8 h) as inthe case of Hadoop [28]. Additionally, tokens could be sto-len and used by Man-in-the-middle even if they are en-crypted [29,30]. The perpetrator intercepts the encryptedtoken and uses it on behalf of the legitimate user to provehis identity. In our experiments, we successfully inter-cepted OAuth tokens and used them to masquerade legit-imate users. In Fig. 3, if the attacker intercepts the trafficon path 1 (the communication between the user and thecloud provider), he can access the token sent by the userto the cloud provider. Similarly, if the attacker interceptsthe traffic on paths 2 and 3, he will be able to acquire theaccess token while being sent by the IDM provider to theuser and the cloud service provider. Additionally, attacksagainst other wireless networks such as ad hoc and sensornetworks can also be lunched in many cases against mobiledevices due to the common characteristics of the commu-nication medium [31–33].

In this paper, we evaluate the security levels and guar-antees that need to exist over each of these communicationpaths to protect them against possible cryptanalysisattacks. We also evaluate the amount of damage createdby compromising each path. Finally, we propose a novelsolution that secures the communication paths withoutintroducing more sophistication to the encryption

Fig. 4. Separation of privileges to defeat IDM server compromise(CIDM.1).

104 I. Khalil et al. / Computer Networks 65 (2014) 99–110

processes in use. Our solution to countermeasure this vul-nerability utilizes the separation of privileges principle.The idea is to distribute the authentication informationin the token into two related but different parts – one partis sent to the CSP over path 3 through path 2 while theother is sent to the CSP directly over path 1. Only the cor-rect relation of the two parts would grant access to thecloud services and data. The two parts have to be relatedand the cloud provider should be able to verify the correctrelation between the two parts. If both path 1 and path 2 orpath 3 are compromised, then all the authentication com-ponents can be intercepted by the attacker. That would befine as security methods are trying to increase the diffi-culty of breaking rather than completely eliminating theprobability of breach.

4. Consolidated Identity Management System (CIDM)

In this section, we present the architecture of our IDMsystem which we dubbed Consolidated IDM (CIDM). Wealso show how CIDM controls each of the vulnerabilitiesmentioned earlier and countermeasures the resultingthreats.

4.1. Vulnerability #1: IDM server compromise

As mentioned earlier, if the IDM server gets compro-mised (through, for example, malicious insider or injectedmalicious code), intruders may capture users’ tokens andfurther use them to illegally access users’ private dataand consume their paid services over the cloud. To allevi-ate the possibility of capturing tokens through IDM servercompromise, we utilize the separation of privileges princi-ple. In separation of privileges, the successful access to anobject depends on more than one condition. For example,ATM machine login requires the ATM card and the pinnumber. Therefore, we propose that user access to theCSP should only be allowed upon the successful receptionof two different but related pieces of information. The firstpiece of information comes to the CSP directly from the cli-ent and is called the session commit value (M). The secondpiece of information is passed to the CSP from the clientthrough the IDM and is called the encrypted session com-mit value (C). The idea is to keep the first piece of informa-tion (M) out of the access of possible IDM insiders.

Fig. 4 presents the separation of privilege steps used todefeat the threat of IDM server compromise. The user gen-erates, encrypts, signs and sends the session commit valueto the IDM server during the login process with the IDMprovider. The IDM provider attaches the encrypted sessioncommit value (C) with the token generated for the user toaccess the CSP. The IDM provider then sends the token to-gether with the encrypted session commit value to the CSP.The user then proves to the CSP that he is the owner of theencrypted session commit value (C) by sending to the CSPthe session commit value (M) and the key (K) used to gen-erate C. This proof (M and K) is sent to the CSP confiden-tially by encrypting it using the public key of the CSP.The CSP then verifies that C is equivalent to the encryptionof M using K before granting access to the user. Note thatan IDM insider may only possess C but cannot possess M

since M is not available to the IDM. Therefore, our use ofthe separation of privileges principle perfectly protectsthe IDM process against possible IDM server compromisevulnerabilities.

Following are the detailed steps of the first version ofour CIDM protocol (CIDM.1) which are illustrated in Fig. 4:

1. The user generates a random symmetric key (K). Theuser then generates a session commit value (M) thatincludes her ID, the ID of the service provider, the IDof the IDM and a random nonce. The random nonce isincluded to prevent replay attacks. The user encryptsM using the key K to compute C (C = E(K, M)).

2. The user login to the IDM provider using her loginaccount with the IDM provider. The user sends C confi-dentially to the IDM provider (for example by encrypt-ing it using his login password) and requests an accesstoken to the CSP.

3. The IDM provider generates a token, attaches C to thetoken, and sends the compound message to the CSP.

4. The IDM provider sends the token to the user.5. The user encrypts M and K using the public key of the

service provider (Ku) to compute R (R = E(M||K, Ku).The user then sends R and the token to the CSP.

6. The CSP uses his private key (Kr) to decrypt R and get Mand K. Then, the CSP computes Ct = E(M, K). Finally, theCSP verifies the token received from the IDM and veri-fies that Ct = C.

7. If the previous two checks pass, the CSP grants therequested access to the user.

4.2. Vulnerability #2: Mobile client compromise

Many mobile cloud users save credentials and othersensitive data on their mobile devices for fast and ease of

I. Khalil et al. / Computer Networks 65 (2014) 99–110 105

access. Moreover, many users enable browser cookies toremember credentials for automatic access to informationand services on the cloud instead of entering it with everylogin. We conducted a survey to draw insights about thepercentage of people who store their sensitive informationon their mobile devices. The survey involves a randomsample of 67 mobile users. The results of the survey arepresented in Fig. 5.

The survey results show that more than 50% of the sur-veyed customers store passwords in cookies, more than25% store passwords in text files, more than 15% storepasswords in applications, and more than 66% store pass-words in either format. These results are astonishing as itreveals the severity of mobile client compromise on theprivacy of users and the security of their data and compu-tations. Combining these results with the relative easinessof mobile device capture emphasizes the necessity to con-trol mobile device capture vulnerabilities and to neutralizepossible attacks that may utilize it. An example of such at-tacks is the session hijacking that can result in informationleakage of sensitive data [34] and many other attacks pre-sented in [7]. The habits of storing sensitive information lo-cally are especially dangerous in the case of mobile clientsdue to: (i) the lack of physical security on mobile devicessince they could be easily lost or stolen, (ii) being confinedto non-sophisticated security measures due to space, com-putation, and power limitations, and (iii) the relative easi-ness of mobile applications compromise since they mayaccess remote untrusted sites that could disseminate mal-ware [7].

To defeat mobile device compromise vulnerability andcountermeasure illegal access to sensitive data and cloudservices, we add a human interaction layer before the ac-cess is granted. The user must provide an answer for asecurity question (e.g., date of birth, maiden name, etc.) be-fore being granted the requested access. A similar ap-proach is being used by Apple mobile devices (e.g.,iPhones and iPads) when users download or update newapplications through the App Store. Even when the userhas already saved his credit card information and accesscredentials on the system before, App Store always askfor the password every time a new application is down-loaded or an old application is updated. This means thatthe App Store password is not stored locally. On the otherhand, running an application such as E-mail or Facebookdoes not require human interaction if the username/

Fig. 5. Survey results bout the percentage of people who store sensitiveinformation on their mobile devices.

password have been set and saved before. Note that thesecurity questions and answers are specific to a certain ser-vice or cloud provider and they are stored within the pro-vider servers and not on the mobile device. By doing this,we perfectly protect the sensitive data and services fromillegal accesses through lost or stolen mobile devices. Cap-turing the mobile device does not provide the perpetratorwith all the information required to successfully performthe illegal access.

Combining the solution for this threat with the first ver-sion of CIDM results in the following second version forCIDM protocol (CIDM.2):

1. The user generates a random symmetric key (K). Theuser then generates a session commit value (M) thatincludes her ID, the ID of the service provider, the IDof the IDM and a random nonce. The random nonce isincluded to prevent replay attacks. The user encryptsM using the key K to compute C (C = E(K, M)).

2. The user login to the IDM provider using her loginaccount with the IDM provider. The user sends C confi-dentially to the IDM provider (for example by encrypt-ing it using his login password) and requests an accesstoken to the CSP.

3. The IDM provider generates a token, attaches C to thetoken, and sends the compound message to the CSP.

4. The IDM provider sends the token to the user.5. The CSP presents a security question to the user6. The user encrypts M and K using the public key of the

service provider (Ku) to compute R (R = E(M||K, Ku).The user then sends R, the answer to the security ques-tion, and the token to the CSP.

7. The CSP uses his private key (Kr) to decrypt R and get Mand K. Then, the CSP computes Ct = E(M, K). Finally, theCSP verifies the token received from the IDM, verifiesthat Ct = C, and verifies the answer to the securityquestion.

8. If all the previous checks pass, the user is granted therequested data or service.

4.3. Vulnerability #3: Network traffic interception

As noted in Fig. 3 and from the generic IDM architecture(Fig. 1), all the links among the parties carry the token.Therefore, compromising any of the three links would re-sult in illegal access. On the other hand, the authorizationdata exchanged over the communication medium amongthe various parties in CIDM (Fig. 6) can be summarizedas follows:

� The link between the client and the CSP (link 1 in Fig. 3)caries the proof of ownership of the session commitvalue (M) and the token.� The link between the client and the CIDM provider (link

2 in Fig. 3) carries the encrypted session commit value(C) and the token.� The link between the CIDM provider and the CSP (link 3

in Fig. 3) carries the token and C.

First, note that if link 1 is compromised, the perpetratorcan get all the information required to mask the legitimate

Fig. 6. Consolidated IDM (CIDM).

106 I. Khalil et al. / Computer Networks 65 (2014) 99–110

user and illegally access his data and services. Compromis-ing either link 2 or link 3 allows the culprit to get only Cand the token. Second, note that link 3 can afford moresophisticated security techniques to be hardened againstcompromise. On the other hand, links 1 and 2 may uselightweight security techniques due to the involvementof mobile devices at one end of the link. Mobile devicesare usually limited in processing capabilities and in thesophistication of the algorithms they run, mainly due toenergy considerations (battery operated).

Recent access network technology standards such asLong Term Evolution (LTE) provide high speed and robustcommunication services similar to broadband networkssince it is an all IP network. LTE enables the use of moresophisticated security techniques on links 1 and 2, whichmake the links more difficult to compromise. However,being an all IP network adds more stress on security asLTE networks become exposed to both threats of a broad-band network and those unique to mobile [2]. LTE addsmyriad of security vulnerabilities [35], which include, butnot limited to, (i) LTE is more susceptible to DoS and DDoSattacks as the Mobility Management Entity (MME) mustforward the User Equipment’s (UE) requests to the HomeSubscriber Server (HSS) even before the UE has beenauthenticated by the MME, (ii) LTE has high bandwidthconsumption and authentication overhead, (iii) theauthentication protocol used (EPS-AKA) lacks the abilityof online authentication, (iv) LTE considerably increasesthe UE’s energy consumption and the system’s complexity,and (v) the IMS AKA protocol is vulnerable to the Man-in-the-middle attack. In addition to the security concerns ofLTE, the original equipment manufacturers (OEMs) andthe users may hesitate to implement/use sophisticatedsecurity techniques to avoid fast battery depletion. Basedon all these concerns, we believe that links 1 and 2 may

continue to use lightweight security techniques and re-main susceptible to compromise with non-negligible prob-ability even with LTE.

CIDM’s mitigation strategy of the network traffic inter-ception threat is two-fold: First, we distribute the authori-zation information over multiple communication linksinstead of concentrating it over one link (link 1). CIDM onlysends the token over link 3. Doing this spares us the com-plete capture of all the authorization information by justcompromising one link (link 1). Second, we strengthenthe security of the communication link between the CIDMprovider and the CSP by using more sophisticated encryp-tion algorithms. By doing this, the interceptor needs tocompromise both links 1 and 3 to be able to get all the nec-essary information to illegally access the cloud provider.Therefore, adding extra sophistication to link 3 withoutchanging the status of links 1 and 2 will be sufficient to de-ter the attacker and prevent the attack.

Following are the detailed steps of the final version ofour CIDM protocol which are illustrated in Fig. 6.

1. The user generates a random symmetric key (K). Theuser then generates a session commit value (M) thatincludes her ID, the ID of the service provider, the IDof the IDM and a random nonce. The random nonce isincluded to prevent replay attacks. The user encryptsM using the key K to compute C (C = E(K, M)).

2. The user login to the IDM provider using her loginaccount with the IDM provider. The user sends C confi-dentially to the IDM provider (for example by encrypt-ing it using his login password) and requests an accesstoken to the CSP.

3. The IDM provider generates a token, attaches C to thetoken, and sends the compound message to the CSP.

4. The CSP presents a security question (SQ) for the user.

I. Khalil et al. / Computer Networks 65 (2014) 99–110 107

5. The user encrypts M, K, and the answer to the securityquestion (ASQ) using the public key of the CSP (Ku) tocompute R (R = E(Ku, M||K||ASQ). The user then sendsR to the CSP.

6. The CSP uses his private key (Kr) to decrypt R and get M,K, and ASQ. Then, the CSP computes Ct = E(K, M).Finally, the CSP verifies the token received from theIDM, verifies that Ct = C, and verifies the ASQ.

7. If all the previous checks pass, the user is granted therequested data or service.

5. Experiments and discussions

Recall that we discuss three attacks against the currentIDM systems, namely – IDM server compromise, mobiledevice compromise and network traffic interception. Wealso propose a new IDM architecture (CIDM) that counter-measures these attacks. To evaluate the performance ofCIDM, we conducted experiments in our security lab usingAndroid Galaxy Nexus as a mobile client and two dedicatedhigh-speed web-servers as cloud service providers. We de-velop and install cloud service providers on web-servers.

5.1. Security analysis and discussion

The main goal of these experiments is to evaluate andcompare the security strength of our CIDM and the genericIDM architecture. The security strength is determined bythe ability of a culprit to gain illegal access to the CSP onbehalf of the legitimate user under the following threeexperimental setups.

� In the first setup, we inject malicious code into the IDMserver. The malicious code sends a copy of each newtoken generated to the attacker.� In the second setup, we emulate capture of a mobile

device by a culprit who is capable to extract all thestored information on the device.� In the third setup, we allow the culprit to intercept the

traffic over one/two/three of the communication linksamong the parties involved.

5.1.1. Experiment #1: IDM server compromiseIn current IDM systems, if the IDM server gets compro-

mised, attackers can steal tokens and hence use them toillegally access cloud services and data on behalf of legiti-mate users. To show this, we conducted the followingexperiment. We implemented a CSP from which authenti-cated users can access their Gmail contacts’ list using mo-bile clients. The CSP uses IDM system to authenticate theclients. For this purpose, we deployed two IDM servers thatauthenticate users using their Gmail accounts. The firstIDM server implements the generic architecture Fig. 1which we simply refer to by IDM while the second IDMserver implements CIDM. The CSP authenticates a user bycomparing the token sent by her to that sent by the IDMserver. Both IDM and CIDM work perfectly and provideproper authentication for legitimate users in attack freescenarios.

Next, we compromised the IDM and the CIDM serversby injecting malicious code that copies users’ tokens and

sends them to the attacker. With the stolen tokens, wetry to access the CSP on behalf of the legitimate users. Inthe IDM case, the CSP matches these tokens with tokenssent by the IDM server and the illegal access was successfulfor all the stolen tokens. In the case of CIDM, the client gen-erates a session commit value (M), encrypts M with a ran-dom key (K) and then sends the encrypted message (C)with the login information to the CIDM server. The CIDMserver authenticates the client and generates a token andsends it along with C to the CSP. Upon reception of thismessage, CSP presents the user with SQ. The user thensends to the CSP M, K, and ASQ encrypted using the publickey of the CSP. When the CSP receives the message fromthe client, it decrypts the message to get M, K, and ASQ.Then the CSP encrypts M by K and compares it with C sentby the CIDM. If they match, the CSP grants access to the cli-ent. The further communication between the CSP and theauthenticated client can be encrypted by K to guard thetraffic against Man-in-the-middle attacks. The attackergets C and the token through the injected malicious codein the CIDM server. To successfully finalize the access pro-cess, the attacker also needs to provide the CSP with M andK. However, the attacker fails to send the correct (M, K)message to the CSP since the information is not availablein the compromised CIDM server. Therefore, all the illegalaccesses fail in the CIDM case.

5.1.2. Experiment #2: Mobile client compromiseMany mobile users save their credentials and other sen-

sitive information in their devices in the form of text,browser cookies, sticky note applications, etc. for fast andease of access. In this experiment, we used a mobile devicewhich contains the login credentials of a cloud service userin the form of cookies and assumed that this phone is cap-tured by an attacker. Recall that in the case of CIDM, theuser needs the login password, the session commit value(M and K), and the correct answer to the security questionto successfully access the CSP. In the case of IDM, with thestolen mobile device in hand, the attacker can easily loginto the IDM server, get a token, and successfully access theCSP. In the CIDM case, the attacker can get all the necessaryinformation from the captured device except the answer tothe security question. Recall that the answers to the secu-rity questions are not stored on the mobile device. Thesecurity questions and their answers are stored on theCSP. In this case, even though the attacker possesses the lo-gin password and can generate proper session commit val-ues, he still needs to correctly answer a security questionbefore being granted the access. Our experiments clearlyshow that CIDM defeats the mobile compromise attackby disallowing the illegal access while in the IDM case;the attacker successfully obtains illegal access on behalfof the owner of the captured device.

5.1.3. Experiment #3: Network traffic interceptionIn this experiment, we implemented link compromise

by enabling the attacker to intercept all the traffic over thatlink [30]. In the case of IDM, when the attacker comprisesany of the three links (link 1, link 2, or link 3) in Fig. 3, hesuccessfully obtains the token and successfully gets illegalaccess to the CSP on behalf of the legitimate user. In CIDM,

108 I. Khalil et al. / Computer Networks 65 (2014) 99–110

the user sends the encrypted session commit value ‘‘C’’along with login details over link 2 (Fig. 3). If this link iscompromised, the attacker obtains C and the login pass-word to the CIDM provider. After successful user authenti-cation, the CIDM provider sends C along with the tokenover link 3. If the attacker compromises link 3, he also ob-tains the token. Since the attacker has both token and en-crypted session commit value, he may present himself asthe legitimate user and tries to illegally access the CSP.However, the CSP requires the session commit value mes-sage (M and K) and the answer to a security questionwhich the attacker does not possess. Therefore, while com-promising either link 2 or link 3 would lend current IDMsystems insecure, compromising both link 2 and link 3have no impact on the security of CIDM. To finalize the ac-cess, the user sends the session commit message (M and K)to the CSP over link 1. If the attacker intercepts traffic overlink 1, he may obtain the message sent by user. However,this message is encrypted using the public key of theCSP. In order to decrypt this message, the attacker needsthe private key of the CSP which is only known to theCSP. Therefore, intercepting link 1 does not help the attack-er to complete the collection of all the necessary informa-tion required for the successful access. Therefore, CIDM iscompletely secure and prevents illegal access even if allthe communication links get compromised. On the otherhand, recall that compromising any of the communicationlinks in IDM always result in successful illegal access.

Similar to traditional IDMs, CIDM’s vulnerability to theMan-in-the-middle attack depends on the implementa-tion. For example, in many OpenID implementations, theconnection is negotiated over Diffie–Hellman (DH) proto-col which is subject to the Man-in-the-middle attack. Inthe DH association session, the user of ephemeral-ephem-eral DH without built-in authentication is non-conformantwith RFC 2631 and introduces a serious risk of IDM mas-querade [29]. However, other implementations that donot use DH are not vulnerable to the Man-in-the-middleattack. Therefore, we strongly recommend avoiding theuse of DH on any of the link associations to eliminate theimpact of possible Man-in-the-middle attacks. Beyondthe one-time initial associations (establishing login cre-dentials) among the three parties (user, CSP and CIDM),we claim that CIDM is robust against Man-in-the-middleattacks. Table 1 summarizes the results of our previousthree experiments.

Table 2Estimated data exchange in the case of IDM.

5.2. Overhead analysis

In this part, we conducted experiments to analyze andcompare the energy overhead and the communication

Table 1Summary of experimental results.

Successful illegal access in the case of

IDM servercompromise

Smartphonecompromise

Networkinterception

IDM Yes Yes YesCIDM No No No

overhead of CIDM and the current generic IDM architec-ture. For symmetric encryptions we use AES algorithmand for asymmetric encryptions we use RSA. For bothRSA and AES, we use the implementations which are in-cluded in the Java SDK 1.7 library [36]. According to thegeneric IDM architecture (Fig. 1), the estimated amountof authorization data exchange is detailed below:

1. User contacts CSP for service (40 bytes).2. CSP asks for a token (40 bytes).3. User logs in with IDM and sends login information

(username and password is 20 bytes on average + 20to reach minimum packet size).

4. IDM shares token with the user (token size is 50 bytes).5. IDM shares token with CSP.6. User sends token to CSP.

Table 2 presented a summary of the estimated data ex-change in the case of IDM.

The estimated amount of authorization data exchangein the case of CIDM is detailed below:

1. User logs in with CIDM and sends C along with logininformation (encrypted commit value size is 16bytes + 20 password and username + 4 to reach mini-mum packet size).

2. CIDM sends token and C to CSP (50 + 16 bytes).3. CSP asks user for M and K and the security question (40

bytes).4. User sends M, K, and ASQ encrypted with public key of

CSP (64 bytes with 512 bytes public key).

Table 2 presented a summary of the estimated data ex-change in the case of CIDM.

The estimated results presented in Tables 2 and 3 showthat CIDM consumes less bandwidth compared to IDM.This adds to the security benefits of CIDM, especially formobile users as they consume less energy (due to loweramounts of send/receive data) in authorizing themselvesto the CSP.

However, note that the client in CIDM computes an AESencryption of 16 bytes and an RSA encryption of 64 bytes.On the other hand, the client in IDM transmits 26 more by-tes and receives 50 more bytes compared to the client inCIDM. To estimate the energy impact of these operationson mobile clients, we run experiments on Android GalaxyNexus smart phone. On the smartphone, we calculate the

User (bytes) IDM (bytes) CSP (bytes)

Send RCV. Send RCV. Send RCV.

Step 1 40 40Step 2 40 40Step 3 40 40Step 4 50 50Step 5 50 50Step 6 50 50

Total 130 90 100 40 40 140

Table 3Estimated data exchange in the case of CIDM.

User (bytes) CIDM (bytes) CSP (bytes)

Send RCV. Send RCV. Send RCV.

Step 1 40 40Step 2 66 66Step 3 40 40Step 4 64 64

Total 104 40 66 40 40 130

I. Khalil et al. / Computer Networks 65 (2014) 99–110 109

energy consumed per byte transmission, byte reception,AES computation, and RSA computation. We consider theenergy consumed in the computation of one byte in AESas the baseline energy unit (E). Our experiments show thatthe computation of one byte in RSA takes 1.03E, transmis-sion of one byte takes 3.71E, and reception of one bytetakes 1.85E. The extra energy consumed by the client inIDM and CIDM can be computed as follows:

Extra Energy ðCIDMÞ ¼ 16 � 1Eþ 64 � 1:03E ¼ 81:92E

Extra Energy ðIDMÞ ¼ 26 � 3:71Eþ 50 � 1:85E ¼ 188:96E

Therefore, even though the client in CDMA does oneAES and one RSA computations, it communicates less datacompared to the client in IDM. In CIDM client, the extra en-ergy consumed in the encryptions is compensated by thereduced energy in communications. This shows that theenergy and communications overhead in CIDM is less thanthat in IDM.

6. Conclusions

IDM systems are third party systems that have beenintroduced to manage digital identities of users on behalfof service providers. It is similar to outsourcing parts ofproject work to another company to share the load. Thecurrent implementations of IDM systems suffer from manysecurity vulnerabilities. In this work, we have identifiedthree security vulnerabilities in the current IDM systems,namely: IDM server compromise, mobile device compro-mise, and traffic interception. Most importantly, we devel-op a new IDM architecture dubbed consolidated IDM(CIDM) that countermeasures these vulnerabilities. Ourcountermeasures include: (1) separating the authorizationcredentials and distributing them among all the IDM par-ties (the user, the IDM provider, and the CSP) to preventillegal access in case of IDM compromise or traffic inter-ception, (2) adding a second layer of authentication usinghuman-based challenge-response to guard against mobiledevice compromise, and (3) consolidation the security ofthe communication link between the CIDM and the CSPto decrease the probability of successful compromise ofthat link. Finally, we conducted experiments to evaluateand compare the possibility of successful illegal accessesto the CSP on behalf of legitimate users for both IDM andCIDM. Our experiments show that the security providedby CIDM outperforms that provided by the current IDMsystems without incurring significant computation or com-munication overhead.

In a future work, we plan to investigate the possibilities,consequences and countermeasures of cloud providercompromise, through for example tampered binaries, in-jected malicious code, or malicious insiders. Also, we planto investigate the issue of inadequate dynamic federationand agile mechanisms in current IDM systems [37], whichis an architectural concern and should be addressed at de-sign level.

References

[1] R.H. Weber, A. Darbellay, Legal issues in mobile banking, J. Bank.Regul. 11 (2) (2010) 129–145.

[2] L.A. Martucci, A. Zuccato, B. Smeets, S.M. Habib, T. Johansson, N.Shahmehri, Privacy, security and trust in cloud computing: theperspective of the telecommunication industry, in: The 9thInternational Conference on Ubiquitous Intelligence Computingand the 9th International Conference on Autonomic TrustedComputing (UIC/ATC), 2012, pp. 627–632.

[3] B. Markelj, I. Bernik, To use or not to use mobile devices, J. InternetTechnol. Secured Trans. (JITST) 1 (1/2) (2012). <http://www.infonomics-society.org/JITST/ToUseorNottoUseMobileDevices.pdf>.

[4] I. Khalil, A. Khreishah, S. Bouktif, A. Ahmad, Security concerns incloud computing, in: Proceedings of the 10th InternationalConference on Information Technology: New Generations, LasVegas, Nevada, USA, April 15–17, 2013.

[5] http://www.digitalbuzzblog.com/infographic-2013-mobile-growth-statistics/ (accessed 10.01.14).

[6] I. Berni, B. Markelj, Blended threats to mobile devices on the rise, in:The International Conference on Information Society (i-Society),2012, pp. 59–64.

[7] M. La Polla, F. Martinelli, D. Sgandurra, A survey on security formobile devices, IEEE Commun. Surv. Tutorials 15 (1) (2013) (FirstQuarter).

[8] http://www.abiresearch.com/research/product/1012083-mobile-device-security (accessed 10.01.14).

[9] M. Bishop, Computer Security: Art and Science, Addison-WesleyProfessional, Reading, MA, 2002.

[10] M. Leandro, T. Nascimento, D. Santos, M. Westphall, C. Westphall,Multi-tenancy authorization system with federated identity forcloud-based environments using shibboleth, in: The EleventhInternational Conference on Network (ICN), 2012, pp. 88–93.

[11] D. Hardt, The OAuth 2.0 Authorization Framework, Ed. Microsoft.July 31, 2012. <http://tools.ietf.org/html/draft-ietf-oauth-v2-31>(accessed 10.01.14).

[12] http://openid.net/specs/openid-authentication-2_0.html (accessed10.01.14).

[13] https://www.sans.org/reading-room/whitepapers/application/attacks-oauth-secure-oauth-implementation-33644 (accessed 10.01.14).

[14] http://thenextweb.com/socialmedia/2010/07/17/oauth-and-openid-authentication-vulnerable-to-timing-attack/#!q0tFt (accessed10.01.14).

[15] R. Wang, S. Chen, X. Wang, Signing me onto your accounts throughFacebook and Google: a traffic-guided security study ofcommercially deployed single-sign-on web services, in: TheProceedings of the IEEE Symposium on Security and Privacy, USA,2012, pp. 365–379.

[16] OpenID Still Open To Abuse. <http://www.computing.co.uk/ctg/opinion/1824215/openid-abuse> (accessed 10.01.14).

[17] http://lists.danga.com/pipermail/yadis/2005-June/000472.html (accessed10.01.14).

[18] S. Xiao, W. Gong, Mobility can help: protect user identity withdynamic credential, in: The Eleventh International Conference onMobile Data Management (MDM), 2010, pp. 378–380.

[19] P. Angin, B. Bhargava, R. Ranchal, N. Singh, M. Linderman, L.B.Othmane, L. Lilien, An entity-centric approach for privacy andidentity management in cloud computing, in: The 29th IEEESymposium on Reliable Distributed Systems, 2010, pp. 177–183.

[20] R. Guerrero, P. Cabarcos, F. Mendoza, D. Diaz-Sanchez, Trust-awarefederated IdM in consumer cloud computing, in: The Proceedings ofthe IEEE International Conference on Consumer Electronics (ICCE),2012, pp. 53–54.

[21] M. Stihler, A. Santin, A. Marcon, J. Fraga, Integral federated identitymanagement for cloud computing, in: The 5th International

110 I. Khalil et al. / Computer Networks 65 (2014) 99–110

Conference on New Technologies, Mobility and Security (NTMS),2012, pp. 1–5.

[22] P. Zhang, H. Sun, Z. Yan, Building up trusted identity management inmobile heterogeneous environment, in: 10th IEEE InternationalConference on Trust, Security and Privacy in Computing andCommunications (TrustCom), 2011, pp. 873–877.

[23] https://blogs.rsa.com/anatomy-of-an-attack/ (accessed 10.01.14).[24] www.lastpass.com/adobe (accessed 10.01.14).[25] I. Khalil, A. Khreishah, M. Azeem, Cloud computing security: a

survey, Comput. (MDPI J.) 3 (1) (2014) 1–35, http://dx.doi.org/10.3390/computers3010001.

[26] http://www.gtcybersecuritysummit.com/2014Report.pdf (accessed10.01.14).

[27] http://www.newscenter.gatech.edu/2013/11/06/georgia-tech-warns-threats-cloud-data-storage-mobile-devices-latest-%E2%80%98emerg-ing-cyber (accessed 10.01.14).

[28] http://resources.infosecinstitute.com/android-master-key-vulner-ability-poc/ (accessed 10.01.14).

[29] https://sites.google.com/site/openidreview/issues (accessed 10.01.14).

[30] T. Han, N. Zhang, K. Liu, B. Tang, Y. Liu, Analysis of mobile WiMAXsecurity: vulnerabilities and solutions, in: IEEE InternationalConference on Mobile Ad Hoc and Sensor Systems (MASS), Atlanta,Georgia, 2008, pp. 828–833.

[31] I. Khalil, ELMO: energy aware local monitoring in sensornetworks, IEEE Trans. Dependable Secure Comput. 8 (4) (2011)523–536.

[32] I. Khalil, MCC: mitigating colluding collision attacks in wirelesssensor networks, in: Proceedings of the IEEE Global CommunicationsConference (IEEE GLOBECOM’10), Miami, Florida, USA, December 6–10, 2010, pp. 1–5.

[33] I. Khalil, MPC: mitigating stealthy power control attacks in wirelessad hoc networks, in: Proceedings of the IEEE Global CommunicationsConference (IEEE GLOBECOM’09), Honolulu, Hawaii, USA, November30–December 4, 2009, pp. 1–6.

[34] I. Dacosta, S. Chakradeo, M. Ahamad, P. Traynor, One-timecookies: preventing session hijacking attacks with statelessauthentication tokens, ACM Trans. Internet Technol. 12 (1)(2012) 1:1–1:24.

[35] http://www.ieee-globecom.org/2012/private/T10F.pdf (accessed10.01.14).

[36] http://www.oracle.com/technetwork/java/javase/overview/index.html (accessed 10.01.14).

[37] R. Sanchez, F. Almenares, P. Arias, D. Diaz-Sanchez, A. Marin,Enhancing privacy and dynamic federation in IdM for consumercloud computing, IEEE Trans. Consum. Electron. 58 (1) (2012)95–103.

[38] I. Hababeh, I. Khalil, A. Khreishah, Designing high performance web-based computing services to promote telemedicine databasemanagement system, IEEE Trans. Serv. Comput. (2) (2014).10.1109/TSC.2014.2300499.

[39] J. Shi, M. Taifi, A. Khreishah, J. Wu, Sustainable GPU computing atscale, in: 14th IEEE International Conference in ComputationalScience and Engineering, 2011, pp. 263–272.

[40] J.Y. Shi, M. Taifi, A. Khreishah, Resource planning for parallelprocessing in the cloud, in: 2011 IEEE International Conference onHigh Performance Computing and Communications.

Issa Khalil received the B.Sc. and the M.Sc.degrees from Jordan University of Science andTechnology in 1994 and 1996 and the PhDdegree from Purdue University, USA in 2006,all in Computer Engineering. Immediatelythereafter he worked as a post-doctoralresearcher in the Dependable ComputingSystems Lab of Purdue University until hejoined the College of Information Technology(CIT) of the United Arab Emirates University(UAEU) in August 2007. In June 2013, Khaliljoined Qatar Computing Research Institute

(QCRI) of Qatar Foundation as a Senior Scientist. Khalil’s research interestsspan the areas of wireless and wireline communication networks. He isespecially interested in security, routing, and performance of wireless

Sensor, Ad Hoc and Mesh networks. Khalil’s recent research interestsinclude malware analysis, advanced persistent threats, mobile security,cloud security, botnets’ tracking and takedown, and ICS/SCADA security.Dr. Khalil served as the technical program co-chair of the 6th Interna-tional Conference on Innovations in Information Technology and wasappointed as a Technical Program Committee member and reviewer formany international conferences and journals. In June 2011, Khalil wasgranted the CIT outstanding professor award for outstanding performancein research, teaching, and service.

Abdallah Khreishah received his Ph.D. andM.S. degrees in Electrical and ComputerEngineering from Purdue University in 2010and 2006, respectively. Prior to that, hereceived his B.S. degree with honors fromJordan University of Science & Technology in2004. In Fall 2012, he joined the ECE depart-ment of New Jersey Institute of Technology asan Assistant Professor. His research spans theareas of network coding, wireless networks,cloud computing, and network security.

Muhammad Azeem received his B.S inInformation Technology from National Uni-versity of Science and Technology, Pakistan.Currently, he is working as Research Assistantin College of IT, UAE University. His primaryresearch interest is in Information Securityand Data Mining.