Consolidated Identity Management System for ... - Semantic Scholar

2 downloads 0 Views 1MB Size Report
Mar 25, 2014 - ... States c College of Information Technology, United Arab Emirate University, Al Ain, United Arab Emirates ... Mobile devices could be easily lost or stolen and ... In this paper, we discuss the limitations of the state-of-the-art.
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 mobile cloud computing Issa Khalil a,⇑, Abdallah Khreishah b, Muhammad Azeem c a

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

a r t i c l e

i n f o

Article history: Received 29 August 2013 Received in revised form 26 January 2014 Accepted 19 March 2014 Available online 25 March 2014 Keywords: Cloud computing security Privacy Mobile clients Identity Management Systems Security attacks

a b s t r a c t Security issues in cloud computing are shown to be the biggest obstacle that could lower the wide benefits of the cloud systems. This obstacle may be strengthened when cloud services are accessed by mobile devices. Mobile devices could be easily lost or stolen and hence, they are easy to compromise. Additionally, mobile users tend to store access credentials, passwords and other Personal Identifiable Information (PII) in an improperly protected way. We conduct a survey and found that more than 66% of the surveyed users store PIIs in unprotected text files, cookies, or applications. To strengthen the legitimate access process over the clouds and to facilitate authentication and authorization with multiple cloud service providers, third-party Identity Management Systems (IDMs) have been proposed and implemented. In this paper, we discuss the limitations of the state-of-the-art cloud IDMs with respect to mobile clients. Specifically, we show that the current IDMs are vulnerable to three attacks, namely – IDM server compromise, mobile device compromise, and network traffic interception. Most importantly, we propose and validate a new IDM architecture dubbed Consolidated IDM (CIDM) that countermeasures these attacks. We conduct experiments to evaluate the performance and the security guarantees of CIDM and compare them with those of current IDM systems. Our experiments show that CIDM provides its clients with better security guarantees and that it has less energy and communication overhead compared to the current IDM systems. Ó 2014 Elsevier B.V. All rights reserved.

1. Introduction In the early age of computers, computational tasks were performed on mainframe computers. Large companies such as IBM, Amdahl and Hitachi owned these mainframe computers. These companies provided computational services to customers where it takes hours, sometimes, even days, in order to get the results. Cloud computing introduces similar concepts by utilizing hardware pooling ⇑ Corresponding author. Tel.: +974 77495648. E-mail addresses: [email protected] (I. Khalil), [email protected] (A. Khreishah), [email protected] (M. Azeem). http://dx.doi.org/10.1016/j.comnet.2014.03.015 1389-1286/Ó 2014 Elsevier B.V. All rights reserved.

and virtualization concepts to offer computational services over the Internet and other private/public networks [39,40]. It, thus, represents one of the contemporary key technological advances that enable the delivery of computing resources in a way similar to the delivery of utility-based services. Mobility is also considered another important contemporary key technological step that shifts the trend in client devices from PCs to smartphones, laptops, tablets, etc. [1]. There is a dramatic increase in the number of users with wireless smartphone devices and in the number of public access points used to connect to the cloud [2–4,38]. Mobile devices are becoming 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 provide the convenience of anywhere, anytime access. According to Digital buzz, the 2013 mobile growth statistics show that 91% of all people on earth have a mobile phone, 50% of mobile phone users, use mobile as their primary Internet source, and 72% of tablet owners purchase online from their tablets each year [5]. This increase is also contributed to the fact that mobile computing has made business easier and less costly by eliminating the need for on-site information systems [6]. However, the convenience offered by mobile devices is accompanied by many security challenges and introduces wide range of vulnerabilities, especially in the area of access control and identity management. Recent figures show that mobile malicious code has advanced greatly [7] and that the number of incidences of malware injections, especially for credential theft, is on rise [8]. Most enterprises are aware of the security challenges and operational vulnerabilities that could be introduced by allowing access to mobile clients. At the same time, corporate security officers realize that preventing users from using their mobile devices is a losing battle against convenience. Unfortunately, mobile software developers (application/ system software) do not consider mobility threats during the software development life cycle and this is why, organizations and individuals are on their own to secure their information. Users who are not aware of the security threats introduced by mobile devices are evidently at risk. Unauthorized access is one of the major security challenges introduced by mobility, which signifies a serious threat to clouds. Mobile devices increase the probability of unauthorized access due to many different facts. First, mobile devices use wireless communication which is easier to intercept and analyze compared to the wired counterpart. Second, it is relatively easy to lose or steal a mobile device, and hence it is easy to capture and compromise. Third, many mobile users tend to store access credentials, passwords, Personal Identifiable Information (PII), and other valuable digital assets in an improperly protected way and hence, easy to collect. We conduct a survey (Section 4.2) and found that more than 66% of the surveyed users store PIIs either in text files, cookies, or applications in an easily accessible format. Fourth, as mobile devices roam from one network to another, they may connect to improperly protected networks and access remote untrusted sites that could disseminate malware. Combining all these facts with the proliferation of mobile devices make them attractive targets to obtain unauthorized access. Therefore, it is an urgent priority to develop and implement reliable, secure and efficient access management systems that cope with the mobility challenges. Many techniques have been developed to control the unauthorized access to cloud services and data. One of the most widely used security techniques in that direction is the control of user access through proper access management systems. However, proper access management systems rely on proper Identity Management Systems (IDMs) for identity generation, authentication, and authorization. IDMs are mainly designed to maintain the integrity of cyber identities throughout their life cycle to make them and their related data (e.g., authentication and authorization

results) available to different services in a secure, reliable and privacy-protected manner. IDMs are also responsible for identity management tasks such as allowing an identity’s subject to establish links between her various identities. 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 that are responsible for establishing trust among them to cooperate safely in business. The particular type of user’s authentication such as ‘‘Single Sign-On’’ is an example of federated identity systems [10]. However, Single Sign-On service introduces vulnerabilities that can lead to serious attacks if user’s identity has been compromised. With one time successful sign-in, the illegitimate user will not be verified 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, the cloud service provider (CSP), and the IDM provider. The steps involved in acquiring access to a CSP are: (1) The user login to the IDM provider with her pre-assigned username and password, (2) the user requests to access cloud application/data from the CSP, (3) the CSP asks for a token, (4) the user requests a token from the IDM provider, (5) the IDM provider generates a token and sends it to both the user and the CSP, (6) the user forwards the token received from the IDM to the CSP, (7) the CSP compares the tokens received from the user and the IDM provider, and (8) on successful comparison, the cloud allows the user to access the requested data or application. Researchers and practitioners have implemented many flavors of IDMs. However, the security and privacy issues introduced when traditional IDMs are used to serve mobile clients have not been sufficiently addressed. Our analysis and experiments show that the current IDMs do not provide adequate security guarantees for mobile cloud computing. In this paper, we initially discuss the security vulnerabilities and the privacy issues of the current traditional IDMs, especially in mobile client environments. Then, we propose and evaluate a new IDM architecture dubbed Consolidated IDM (CIDM) that addresses the coupled challenges of mobility and identity management in mobile cloud computing. In this work, we assume an attack model in which the attacker’s goal is to gain unauthorized access on behalf of a legitimate user. Therefore, we do not consider DoS or DDoS attacks in which the attacker tries to prevent a legitimate user from being able to prove its identity. Up to our knowledge, we are the first to study and address the security and privacy threats introduced when using traditional IDMs to serve mobile cloud clients. Our contributions can be summarized as follows:  Introduce and investigate the impact of three threats against current IDMs, namely – IDM server compromise, mobile device compromise, and network traffic interception. We explain each threat and show how current 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 that cope with the mobility challenges.

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

101

Fig. 1. Generic IDM architecture.

 Propose a new IDM architecture dubbed Consolidated IDM (CIDM) that eliminates the vulnerabilities of the current IDMs and addresses the unique security challenges introduced when traditional IDMs are used to serve mobile clients.  Evaluate the performance, the overhead, and the security guarantees of CIDM through practical experiments. In these experiments, we intentionally inject malicious code into the IDM server, intercept and analyze network traffic, and compromise mobile client devices that contain sensitive credentials. The rest of the paper is organized as follows. In Section 2, we present the related work. In Section 3, we discuss the security vulnerabilities of the current IDMs in mobile cloud computing environments. In Section 4, we present our proposed IDM architecture. In Section 5, we present our experimental setup and results. Finally, Section 6 concludes the paper. 2. Related work OAuth [11] and OpenId [12] are two widely used implementations of IDMs. In OAuth, the client obtains a token (string denoting a specific scope and limited lifetime) from the authorization server to access a resource, hosted on a resource server. For example, an end-user (resource owner) can grant printing service (client) access to her protected data, which is stored at a data-storage-server (resource server) without sharing her credentials (username/password). OAuth consists of four modules (roles): (1) resource owner (person/server that grant the access of a protected resource), (2) resource server (the server that hosts the protected resource), (3) client (user/application that make request to access resource on behalf of

resource owner) and (4) authorization server (the server responsible to issue the token to the client). Fig. 2 represents the following communication flow of OAuth: 1. The client requests authorization from the resource owner. 2. The client receives an authorization grant (credentials that represents the resource owner’s authentication). 3. The client provides authorization grant to authorization server and request for access token. 4. The authorization server authenticate the access token and after successful validation provides access token. 5. The client request the protected resource from a resource server by providing access token. 6. The server validates the token and on successful validation, grants an access to the requested resource. In [13], Khash Kiani presents four attacks against OAuth and its various implementations. The attacks are: Lack of data confidentiality and server trust, insecure storage of secrets, implementations with flawed session managements, and session fixation attack. Moreover, it has been shown in [14] that OAuth is vulnerable to the timing attacks. Furthermore, in the official specifications of OAuth, all the communications among OAuth modules (A–C in Fig. 2) occur through the client [11]. Other communications among OAuth modules are beyond the scope and irrelevant to the issues we address in this work. In mobile client environments, the client is considered a serious single security point of failure due to being relatively easy to compromise. This problem may render the whole OAuth process as vulnerable and useless. Even in non-mobile environments, threats arise in case one or more of the communication paths between the client and other OAuth

102

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

Fig. 2. OAuth protocol .

modules are compromised. The situation gets even worse in the case of mobile resource owners due to the higher probability of compromise of the resource owner itself. The compromise of the resource owner or OAuth communication paths could expose all the private data of the resource owner whether stored locally or on the cloud. In OAuth specification [11], the attacker is assumed to have no access to the communication between the authorization server and the resource owner. If this assumption does not hold, the whole system becomes vulnerable. However, if the communication between the authorization server and the resource owner is secured by encryption and authentication mechanisms, the issue is alleviated and the assumption becomes irrelevant. In case of mobile device being stolen, OAuth does not provide any mechanism to secure the data except that it encourages users to put key locks on their mobiles [11]. While OAuth provides authorization services (granting an access of resource to a third party on behalf of the resource owner), authentication services (providing the evidence who you are) are provided by systems like OpenId [12]. OpenId facilitates login into multiple sites through Single Sign-On. It has been shown in the literatures [15–17] that OpenId has many security weaknesses and vulnerable to malicious code attack. A malicious code injected on a server that uses OpenId can be used to forward the user to bogus identity provider authentication page that asks for credentials [16,17]. Similar to OAuth, OpenId is also vulnerable to the timing attacks [14]. Many practitioners are promoting the use of OpenId with OAuth for better security. However, we claim that this combination could be lethal to user’s private data. If the authorization server (OAuth) is compromised, the Single Sign-On feature of OpenId becomes an advantage to the attacker since he can access all resources/data on multiple sites. Security vulnerabilities in IDMs are especially dangerous in mobile cloud computing paradigms. Xiao and Gong in [18] claims that the current security mechanisms in mobile cloud computing environments are insufficient because if the attacker is capable of faking/stealing user’s credentials then the cloud data is on stake for a large class of users. To alleviate the threat in mobile cloud

environments, the authors propose an algorithm that generates dynamic identities. The algorithm performs well if adequate security measures are implemented at server level such as antiviruses, network firewalling and intrusion detection systems. However, the algorithm fails if the system is compromised. Leandro et al. in [10] promoted the use of Shibboleth as an access control system in clouds without the use of trusted third party (i.e., IDM server). It provides strong authorization but does not provide strong authentication since once the user is authenticated, no mechanism is proposed to ensure the legitimacy of the connected users. Therefore, an illegitimate user holding valid username and password can access the cloud services for long periods of time without being verified. Moreover, Shibboleth does not guarantee secure transactions. Some researchers (e.g., [10,19]) proposed an application-centric approach for users’ authentication. This approach allows IDM server to keep track of users’ activities to be able to authenticate users without revealing their actual identities. Other researchers [2,6,20–22] modify PC-based IDMs to secure user’s data on cloud, however, these modification fail to address the mobile security challenges. 3. Current IDMs vulnerabilities We have identified three vulnerabilities in the architecture of the current IDMs (Fig. 1). The first vulnerability lies in the possibility of compromising IDM servers. Through IDM server compromise, we assume that the attacker can capture any token from within the IDM servers. However, we assume that the attacker cannot affect the integrity of the tokens or generate new valid tokens. IDM server compromise is a serious vulnerability that could create wide scale attacks against all the clients of the compromised IDM provider. This threat can be realized by various ways such as malicious insider involvement or malicious code injection. In general, IDM servers are supposed to be hard to compromise because they are likely to be protected by physical security measures, insider activity monitoring, tight access control measures, and regular logs and auditing practices. In spite of that, there were many recent practical attacks

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

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 authentication tokens. The attack costs EMC $81.3 to replace SecurID tokens, monitor customers, harden internal systems, and handle fallout from the security breach [23]. More importantly, the attack leads to security breaches on many high profile SecurID customers such as Lockheed Martin, Raytheon Co. (RTN), and Northrop Grumman Corp. (NOC). In another more recent attack (November 2013), hackers infiltrated Adobe’s network and stole millions of customer emails and encrypted passwords [24]. The detection of the IDM server compromise could be complicated by the lack of human interaction among the CSP, the user and the IDM provider to continuously monitor and determine the legitimacy of users. The lack of human interaction helps malicious users or code to get unauthorized access for relatively long periods of time before being possibly detected. The second vulnerability lies in the ease of mobile device capture/compromise through theft, lost, or malicious mobile code injection. Mobile malicious malware becomes a very severe fast growing threat. This is obvious from the 2013 mobile security report of ABI Research (a technology intelligence firm) [8]. The report shows that 62,950 mobile malware samples were identified by various security vendors (such as Kaspersky and MacAfee) in 2011 and 2012. This is not a passing phenomenon as many researchers and practitioners provide different ways to breach the security of mobile devices and present practical examples of successful attacks against various mobile platforms [4,7,25]. In [26], researchers at Georgia Tech presented ways to bypass the vetting process of Apple’s App Store and subsequently showed how malicious USB chargers can be used to infect Apple iOS devices [27]. In [28], researchers practically show how easy it is to fool Android OS by replacing a legitimate code with a malicious one without 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 so the work can be more flexible and beneficial, which may create serious threats. Virtual doors are becoming easier to access and abuse in mobile clients due mainly to the lack of physical protection. The proliferation of mobile devices force corporates to allow mobile device access to data and services both to employees and customers since they realized that blocking them is a losing battle against convenience. The negative impact on user’s security in the case of illegal mobile device capture/compromise is twofold: (1) Local private data stored on the device is exposed (most of the users usually save passwords and other sensitive data in their mobiles, refer to Section 4 for more details), and (2) any data or service (e.g., over the cloud or private corporates) that can be accessed by the credentials stored on the stolen device becomes vulnerable. We claim that enforcing simple real time human interactions such as answering the date-of-birth or any other security question, during access, would boost the security of mobile clients. The required interaction hinders perpetrators when they try to access or use the sensitive data in a lost or stolen mobile device.

103

The third vulnerability lies in the possibility of intercepting and cryptanalyzing IDM messages while being exchanged during the process of trust establishment between the user and the CSP. If an attacker intercepts the network traffic exchanged among the IDM provider, the CSP and the user, he can gain unauthorized access to user’s credentials. These credentials can further be used to gain unauthorized access to cloud services and data. Fig. 3 shows the possible communication paths that could be compromised. Depending on the specific IDM implementation (see the related work section, Section 2), some of these paths may not be sufficiently secure and therefore, traffic could be easily captured and cryptanalyzed. Even in the case of properly encrypted communication paths, replay attacks are still possible since the tokens could be made valid for a relatively long period of time (8 h) as in the case of Hadoop [28]. Additionally, tokens could be stolen and used by Man-in-the-middle even if they are encrypted [29,30]. The perpetrator intercepts the encrypted token and uses it on behalf of the legitimate user to prove his identity. In our experiments, we successfully intercepted OAuth tokens and used them to masquerade legitimate users. In Fig. 3, if the attacker intercepts the traffic on path 1 (the communication between the user and the cloud provider), he can access the token sent by the user to the cloud provider. Similarly, if the attacker intercepts the traffic on paths 2 and 3, he will be able to acquire the access token while being sent by the IDM provider to the user and the cloud service provider. Additionally, attacks against other wireless networks such as ad hoc and sensor networks can also be lunched in many cases against mobile devices due to the common characteristics of the communication medium [31–33]. In this paper, we evaluate the security levels and guarantees that need to exist over each of these communication paths to protect them against possible cryptanalysis attacks. We also evaluate the amount of damage created by compromising each path. Finally, we propose a novel solution that secures the communication paths without introducing more sophistication to the encryption

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

104

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

processes in use. Our solution to countermeasure this vulnerability utilizes the separation of privileges principle. The idea is to distribute the authentication information in the token into two related but different parts – one part is sent to the CSP over path 3 through path 2 while the other is sent to the CSP directly over path 1. Only the correct relation of the two parts would grant access to the cloud services and data. The two parts have to be related and the cloud provider should be able to verify the correct relation between the two parts. If both path 1 and path 2 or path 3 are compromised, then all the authentication components can be intercepted by the attacker. That would be fine as security methods are trying to increase the difficulty of breaking rather than completely eliminating the probability of breach. 4. Consolidated Identity Management System (CIDM) In this section, we present the architecture of our IDM system which we dubbed Consolidated IDM (CIDM). We also show how CIDM controls each of the vulnerabilities mentioned earlier and countermeasures the resulting threats. 4.1. Vulnerability #1: IDM server compromise As mentioned earlier, if the IDM server gets compromised (through, for example, malicious insider or injected malicious code), intruders may capture users’ tokens and further use them to illegally access users’ private data and consume their paid services over the cloud. To alleviate the possibility of capturing tokens through IDM server compromise, we utilize the separation of privileges principle. In separation of privileges, the successful access to an object depends on more than one condition. For example, ATM machine login requires the ATM card and the pin number. Therefore, we propose that user access to the CSP should only be allowed upon the successful reception of two different but related pieces of information. The first piece of information comes to the CSP directly from the client and is called the session commit value (M). The second piece of information is passed to the CSP from the client through the IDM and is called the encrypted session commit value (C). The idea is to keep the first piece of information (M) out of the access of possible IDM insiders. Fig. 4 presents the separation of privilege steps used to defeat the threat of IDM server compromise. The user generates, encrypts, signs and sends the session commit value to the IDM server during the login process with the IDM provider. The IDM provider attaches the encrypted session commit value (C) with the token generated for the user to access the CSP. The IDM provider then sends the token together with the encrypted session commit value to the CSP. The user then proves to the CSP that he is the owner of the encrypted session commit value (C) by sending to the CSP the session commit value (M) and the key (K) used to generate C. This proof (M and K) is sent to the CSP confidentially by encrypting it using the public key of the CSP. The CSP then verifies that C is equivalent to the encryption of M using K before granting access to the user. Note that an IDM insider may only possess C but cannot possess M

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

since M is not available to the IDM. Therefore, our use of the separation of privileges principle perfectly protects the IDM process against possible IDM server compromise vulnerabilities. Following are the detailed steps of the first version of our CIDM protocol (CIDM.1) which are illustrated in Fig. 4: 1. The user generates a random symmetric key (K). The user then generates a session commit value (M) that includes her ID, the ID of the service provider, the ID of the IDM and a random nonce. The random nonce is included to prevent replay attacks. The user encrypts M using the key K to compute C (C = E(K, M)). 2. The user login to the IDM provider using her login account with the IDM provider. The user sends C confidentially to the IDM provider (for example by encrypting it using his login password) and requests an access token to the CSP. 3. The IDM provider generates a token, attaches C to the token, 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 M and K. Then, the CSP computes Ct = E(M, K). Finally, the CSP verifies the token received from the IDM and verifies that Ct = C. 7. If the previous two checks pass, the CSP grants the requested access to the user.

4.2. Vulnerability #2: Mobile client compromise Many mobile cloud users save credentials and other sensitive data on their mobile devices for fast and ease of

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

access. Moreover, many users enable browser cookies to remember credentials for automatic access to information and services on the cloud instead of entering it with every login. We conducted a survey to draw insights about the percentage of people who store their sensitive information on their mobile devices. The survey involves a random sample of 67 mobile users. The results of the survey are presented in Fig. 5. The survey results show that more than 50% of the surveyed customers store passwords in cookies, more than 25% store passwords in text files, more than 15% store passwords in applications, and more than 66% store passwords in either format. These results are astonishing as it reveals the severity of mobile client compromise on the privacy of users and the security of their data and computations. Combining these results with the relative easiness of mobile device capture emphasizes the necessity to control mobile device capture vulnerabilities and to neutralize possible attacks that may utilize it. An example of such attacks is the session hijacking that can result in information leakage of sensitive data [34] and many other attacks presented in [7]. The habits of storing sensitive information locally are especially dangerous in the case of mobile clients due to: (i) the lack of physical security on mobile devices since they could be easily lost or stolen, (ii) being confined to non-sophisticated security measures due to space, computation, and power limitations, and (iii) the relative easiness of mobile applications compromise since they may access remote untrusted sites that could disseminate malware [7]. To defeat mobile device compromise vulnerability and countermeasure illegal access to sensitive data and cloud services, we add a human interaction layer before the access is granted. The user must provide an answer for a security question (e.g., date of birth, maiden name, etc.) before being granted the requested access. A similar approach is being used by Apple mobile devices (e.g., iPhones and iPads) when users download or update new applications through the App Store. Even when the user has already saved his credit card information and access credentials on the system before, App Store always ask for the password every time a new application is downloaded or an old application is updated. This means that the App Store password is not stored locally. On the other hand, running an application such as E-mail or Facebook does not require human interaction if the username/

105

password have been set and saved before. Note that the security questions and answers are specific to a certain service or cloud provider and they are stored within the provider servers and not on the mobile device. By doing this, we perfectly protect the sensitive data and services from illegal accesses through lost or stolen mobile devices. Capturing the mobile device does not provide the perpetrator with all the information required to successfully perform the illegal access. Combining the solution for this threat with the first version of CIDM results in the following second version for CIDM protocol (CIDM.2): 1. The user generates a random symmetric key (K). The user then generates a session commit value (M) that includes her ID, the ID of the service provider, the ID of the IDM and a random nonce. The random nonce is included to prevent replay attacks. The user encrypts M using the key K to compute C (C = E(K, M)). 2. The user login to the IDM provider using her login account with the IDM provider. The user sends C confidentially to the IDM provider (for example by encrypting it using his login password) and requests an access token to the CSP. 3. The IDM provider generates a token, attaches C to the token, 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 user 6. 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 question, and the token to the CSP. 7. The CSP uses his private key (Kr) to decrypt R and get M and K. Then, the CSP computes Ct = E(M, K). Finally, the CSP verifies the token received from the IDM, verifies that Ct = C, and verifies the answer to the security question. 8. If all the previous checks pass, the user is granted the requested 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 result in illegal access. On the other hand, the authorization data exchanged over the communication medium among the various parties in CIDM (Fig. 6) can be summarized as follows:  The link between the client and the CSP (link 1 in Fig. 3) caries the proof of ownership of the session commit value (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.

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

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

106

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

Fig. 6. Consolidated IDM (CIDM).

user and illegally access his data and services. Compromising either link 2 or link 3 allows the culprit to get only C and the token. Second, note that link 3 can afford more sophisticated security techniques to be hardened against compromise. On the other hand, links 1 and 2 may use lightweight security techniques due to the involvement of mobile devices at one end of the link. Mobile devices are usually limited in processing capabilities and in the sophistication of the algorithms they run, mainly due to energy considerations (battery operated). Recent access network technology standards such as Long Term Evolution (LTE) provide high speed and robust communication services similar to broadband networks since it is an all IP network. LTE enables the use of more sophisticated security techniques on links 1 and 2, which make the links more difficult to compromise. However, being an all IP network adds more stress on security as LTE networks become exposed to both threats of a broadband network and those unique to mobile [2]. LTE adds myriad of security vulnerabilities [35], which include, but not limited to, (i) LTE is more susceptible to DoS and DDoS attacks as the Mobility Management Entity (MME) must forward the User Equipment’s (UE) requests to the Home Subscriber Server (HSS) even before the UE has been authenticated by the MME, (ii) LTE has high bandwidth consumption and authentication overhead, (iii) the authentication protocol used (EPS-AKA) lacks the ability of online authentication, (iv) LTE considerably increases the UE’s energy consumption and the system’s complexity, and (v) the IMS AKA protocol is vulnerable to the Man-inthe-middle attack. In addition to the security concerns of LTE, the original equipment manufacturers (OEMs) and the users may hesitate to implement/use sophisticated security techniques to avoid fast battery depletion. Based on all these concerns, we believe that links 1 and 2 may

continue to use lightweight security techniques and remain susceptible to compromise with non-negligible probability even with LTE. CIDM’s mitigation strategy of the network traffic interception threat is two-fold: First, we distribute the authorization information over multiple communication links instead of concentrating it over one link (link 1). CIDM only sends the token over link 3. Doing this spares us the complete capture of all the authorization information by just compromising one link (link 1). Second, we strengthen the security of the communication link between the CIDM provider and the CSP by using more sophisticated encryption algorithms. By doing this, the interceptor needs to compromise both links 1 and 3 to be able to get all the necessary information to illegally access the cloud provider. Therefore, adding extra sophistication to link 3 without changing the status of links 1 and 2 will be sufficient to deter the attacker and prevent the attack. Following are the detailed steps of the final version of our CIDM protocol which are illustrated in Fig. 6. 1. The user generates a random symmetric key (K). The user then generates a session commit value (M) that includes her ID, the ID of the service provider, the ID of the IDM and a random nonce. The random nonce is included to prevent replay attacks. The user encrypts M using the key K to compute C (C = E(K, M)). 2. The user login to the IDM provider using her login account with the IDM provider. The user sends C confidentially to the IDM provider (for example by encrypting it using his login password) and requests an access token to the CSP. 3. The IDM provider generates a token, attaches C to the token, 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

5. The user encrypts M, K, and the answer to the security question (ASQ) using the public key of the CSP (Ku) to compute R (R = E(Ku, M||K||ASQ). The user then sends R 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 the IDM, verifies that Ct = C, and verifies the ASQ. 7. If all the previous checks pass, the user is granted the requested data or service. 5. Experiments and discussions Recall that we discuss three attacks against the current IDM systems, namely – IDM server compromise, mobile device compromise and network traffic interception. We also propose a new IDM architecture (CIDM) that countermeasures these attacks. To evaluate the performance of CIDM, we conducted experiments in our security lab using Android Galaxy Nexus as a mobile client and two dedicated high-speed web-servers as cloud service providers. We develop and install cloud service providers on web-servers. 5.1. Security analysis and discussion The main goal of these experiments is to evaluate and compare the security strength of our CIDM and the generic IDM architecture. The security strength is determined by the ability of a culprit to gain illegal access to the CSP on behalf of the legitimate user under the following three experimental setups.  In the first setup, we inject malicious code into the IDM server. The malicious code sends a copy of each new token generated to the attacker.  In the second setup, we emulate capture of a mobile device by a culprit who is capable to extract all the stored information on the device.  In the third setup, we allow the culprit to intercept the traffic over one/two/three of the communication links among the parties involved. 5.1.1. Experiment #1: IDM server compromise In current IDM systems, if the IDM server gets compromised, attackers can steal tokens and hence use them to illegally access cloud services and data on behalf of legitimate users. To show this, we conducted the following experiment. We implemented a CSP from which authenticated users can access their Gmail contacts’ list using mobile clients. The CSP uses IDM system to authenticate the clients. For this purpose, we deployed two IDM servers that authenticate users using their Gmail accounts. The first IDM server implements the generic architecture Fig. 1 which we simply refer to by IDM while the second IDM server implements CIDM. The CSP authenticates a user by comparing the token sent by her to that sent by the IDM server. Both IDM and CIDM work perfectly and provide proper authentication for legitimate users in attack free scenarios. Next, we compromised the IDM and the CIDM servers by injecting malicious code that copies users’ tokens and

107

sends them to the attacker. With the stolen tokens, we try to access the CSP on behalf of the legitimate users. In the IDM case, the CSP matches these tokens with tokens sent by the IDM server and the illegal access was successful for all the stolen tokens. In the case of CIDM, the client generates a session commit value (M), encrypts M with a random key (K) and then sends the encrypted message (C) with the login information to the CIDM server. The CIDM server authenticates the client and generates a token and sends it along with C to the CSP. Upon reception of this message, CSP presents the user with SQ. The user then sends to the CSP M, K, and ASQ encrypted using the public key of the CSP. When the CSP receives the message from the client, it decrypts the message to get M, K, and ASQ. Then the CSP encrypts M by K and compares it with C sent by the CIDM. If they match, the CSP grants access to the client. The further communication between the CSP and the authenticated client can be encrypted by K to guard the traffic against Man-in-the-middle attacks. The attacker gets C and the token through the injected malicious code in the CIDM server. To successfully finalize the access process, the attacker also needs to provide the CSP with M and K. However, the attacker fails to send the correct (M, K) message to the CSP since the information is not available in the compromised CIDM server. Therefore, all the illegal accesses fail in the CIDM case. 5.1.2. Experiment #2: Mobile client compromise Many mobile users save their credentials and other sensitive information in their devices in the form of text, browser cookies, sticky note applications, etc. for fast and ease of access. In this experiment, we used a mobile device which contains the login credentials of a cloud service user in the form of cookies and assumed that this phone is captured by an attacker. Recall that in the case of CIDM, the user needs the login password, the session commit value (M and K), and the correct answer to the security question to successfully access the CSP. In the case of IDM, with the stolen mobile device in hand, the attacker can easily login to the IDM server, get a token, and successfully access the CSP. In the CIDM case, the attacker can get all the necessary information from the captured device except the answer to the security question. Recall that the answers to the security questions are not stored on the mobile device. The security questions and their answers are stored on the CSP. In this case, even though the attacker possesses the login password and can generate proper session commit values, he still needs to correctly answer a security question before being granted the access. Our experiments clearly show that CIDM defeats the mobile compromise attack by disallowing the illegal access while in the IDM case; the attacker successfully obtains illegal access on behalf of the owner of the captured device. 5.1.3. Experiment #3: Network traffic interception In this experiment, we implemented link compromise by enabling the attacker to intercept all the traffic over that link [30]. In the case of IDM, when the attacker comprises any of the three links (link 1, link 2, or link 3) in Fig. 3, he successfully obtains the token and successfully gets illegal access 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 is compromised, the attacker obtains C and the login password to the CIDM provider. After successful user authentication, the CIDM provider sends C along with the token over link 3. If the attacker compromises link 3, he also obtains the token. Since the attacker has both token and encrypted session commit value, he may present himself as the legitimate user and tries to illegally access the CSP. However, the CSP requires the session commit value message (M and K) and the answer to a security question which the attacker does not possess. Therefore, while compromising either link 2 or link 3 would lend current IDM systems insecure, compromising both link 2 and link 3 have no impact on the security of CIDM. To finalize the access, the user sends the session commit message (M and K) to the CSP over link 1. If the attacker intercepts traffic over link 1, he may obtain the message sent by user. However, this message is encrypted using the public key of the CSP. In order to decrypt this message, the attacker needs the private key of the CSP which is only known to the CSP. Therefore, intercepting link 1 does not help the attacker to complete the collection of all the necessary information required for the successful access. Therefore, CIDM is completely secure and prevents illegal access even if all the communication links get compromised. On the other hand, recall that compromising any of the communication links in IDM always result in successful illegal access. Similar to traditional IDMs, CIDM’s vulnerability to the Man-in-the-middle attack depends on the implementation. For example, in many OpenID implementations, the connection is negotiated over Diffie–Hellman (DH) protocol which is subject to the Man-in-the-middle attack. In the DH association session, the user of ephemeral-ephemeral DH without built-in authentication is non-conformant with RFC 2631 and introduces a serious risk of IDM masquerade [29]. However, other implementations that do not use DH are not vulnerable to the Man-in-the-middle attack. Therefore, we strongly recommend avoiding the use of DH on any of the link associations to eliminate the impact of possible Man-in-the-middle attacks. Beyond the one-time initial associations (establishing login credentials) among the three parties (user, CSP and CIDM), we claim that CIDM is robust against Man-in-the-middle attacks. Table 1 summarizes the results of our previous three experiments.

overhead of CIDM and the current generic IDM architecture. For symmetric encryptions we use AES algorithm and for asymmetric encryptions we use RSA. For both RSA and AES, we use the implementations which are included in the Java SDK 1.7 library [36]. According to the generic IDM architecture (Fig. 1), the estimated amount of 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 + 20 to 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 exchange in the case of IDM. The estimated amount of authorization data exchange in the case of CIDM is detailed below: 1. User logs in with CIDM and sends C along with login information (encrypted commit value size is 16 bytes + 20 password and username + 4 to reach minimum 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 exchange in the case of CIDM. The estimated results presented in Tables 2 and 3 show that CIDM consumes less bandwidth compared to IDM. This adds to the security benefits of CIDM, especially for mobile users as they consume less energy (due to lower amounts of send/receive data) in authorizing themselves to the CSP. However, note that the client in CIDM computes an AES encryption of 16 bytes and an RSA encryption of 64 bytes. On the other hand, the client in IDM transmits 26 more bytes and receives 50 more bytes compared to the client in CIDM. To estimate the energy impact of these operations on mobile clients, we run experiments on Android Galaxy Nexus smart phone. On the smartphone, we calculate the

5.2. Overhead analysis In this part, we conducted experiments to analyze and compare the energy overhead and the communication Table 1 Summary of experimental results. Successful illegal access in the case of

IDM CIDM

IDM server compromise

Smartphone compromise

Network interception

Yes No

Yes No

Yes No

Table 2 Estimated data exchange in the case of IDM.

Step Step Step Step Step Step Total

1 2 3 4 5 6

User (bytes)

IDM (bytes)

CSP (bytes)

Send

Send

Send

RCV.

RCV.

40

40 40

40

40

40 50

50 50

50 50

50 130

RCV.

90

100

40

40

140

I. Khalil et al. / Computer Networks 65 (2014) 99–110 Table 3 Estimated data exchange in the case of CIDM.

Step Step Step Step Total

1 2 3 4

User (bytes)

CIDM (bytes)

CSP (bytes)

Send

Send

Send

RCV.

40

RCV.

66

66

40

40

64 104

RCV.

40

64 40

66

40

40

109

In a future work, we plan to investigate the possibilities, consequences and countermeasures of cloud provider compromise, through for example tampered binaries, injected malicious code, or malicious insiders. Also, we plan to investigate the issue of inadequate dynamic federation and agile mechanisms in current IDM systems [37], which is an architectural concern and should be addressed at design level.

130

References energy consumed per byte transmission, byte reception, AES computation, and RSA computation. We consider the energy consumed in the computation of one byte in AES as the baseline energy unit (E). Our experiments show that the computation of one byte in RSA takes 1.03E, transmission of one byte takes 3.71E, and reception of one byte takes 1.85E. The extra energy consumed by the client in IDM 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 one AES and one RSA computations, it communicates less data compared to the client in IDM. In CIDM client, the extra energy consumed in the encryptions is compensated by the reduced energy in communications. This shows that the energy and communications overhead in CIDM is less than that in IDM. 6. Conclusions IDM systems are third party systems that have been introduced to manage digital identities of users on behalf of service providers. It is similar to outsourcing parts of project work to another company to share the load. The current implementations of IDM systems suffer from many security vulnerabilities. In this work, we have identified three security vulnerabilities in the current IDM systems, namely: IDM server compromise, mobile device compromise, and traffic interception. Most importantly, we develop a new IDM architecture dubbed consolidated IDM (CIDM) that countermeasures these vulnerabilities. Our countermeasures include: (1) separating the authorization credentials and distributing them among all the IDM parties (the user, the IDM provider, and the CSP) to prevent illegal access in case of IDM compromise or traffic interception, (2) adding a second layer of authentication using human-based challenge-response to guard against mobile device compromise, and (3) consolidation the security of the communication link between the CIDM and the CSP to decrease the probability of successful compromise of that link. Finally, we conducted experiments to evaluate and compare the possibility of successful illegal accesses to the CSP on behalf of legitimate users for both IDM and CIDM. Our experiments show that the security provided by CIDM outperforms that provided by the current IDM systems without incurring significant computation or communication overhead.

[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: the perspective of the telecommunication industry, in: The 9th International Conference on Ubiquitous Intelligence Computing and the 9th International Conference on Autonomic Trusted Computing (UIC/ATC), 2012, pp. 627–632. [3] B. Markelj, I. Bernik, To use or not to use mobile devices, J. Internet Technol. Secured Trans. (JITST) 1 (1/2) (2012). . [4] I. Khalil, A. Khreishah, S. Bouktif, A. Ahmad, Security concerns in cloud computing, in: Proceedings of the 10th International Conference on Information Technology: New Generations, Las Vegas, Nevada, USA, April 15–17, 2013. [5] http://www.digitalbuzzblog.com/infographic-2013-mobile-growthstatistics/ (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 for mobile devices, IEEE Commun. Surv. Tutorials 15 (1) (2013) (First Quarter). [8] http://www.abiresearch.com/research/product/1012083-mobiledevice-security (accessed 10.01.14). [9] M. Bishop, Computer Security: Art and Science, Addison-Wesley Professional, Reading, MA, 2002. [10] M. Leandro, T. Nascimento, D. Santos, M. Westphall, C. Westphall, Multi-tenancy authorization system with federated identity for cloud-based environments using shibboleth, in: The Eleventh International Conference on Network (ICN), 2012, pp. 88–93. [11] D. Hardt, The OAuth 2.0 Authorization Framework, Ed. Microsoft. July 31, 2012. (accessed 10.01.14). [12] http://openid.net/specs/openid-authentication-2_0.html (accessed 10.01.14). [13] https://www.sans.org/reading-room/whitepapers/application/attacksoauth-secure-oauth-implementation-33644 (accessed 10.01.14). [14] http://thenextweb.com/socialmedia/2010/07/17/oauth-and-openidauthentication-vulnerable-to-timing-attack/#!q0tFt (accessed 10.01.14). [15] R. Wang, S. Chen, X. Wang, Signing me onto your accounts through Facebook and Google: a traffic-guided security study of commercially deployed single-sign-on web services, in: The Proceedings of the IEEE Symposium on Security and Privacy, USA, 2012, pp. 365–379. [16] OpenID Still Open To Abuse. (accessed 10.01.14). [17] http://lists.danga.com/pipermail/yadis/2005-June/000472.html (accessed 10.01.14). [18] S. Xiao, W. Gong, Mobility can help: protect user identity with dynamic credential, in: The Eleventh International Conference on Mobile 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 and identity management in cloud computing, in: The 29th IEEE Symposium on Reliable Distributed Systems, 2010, pp. 177–183. [20] R. Guerrero, P. Cabarcos, F. Mendoza, D. Diaz-Sanchez, Trust-aware federated IdM in consumer cloud computing, in: The Proceedings of the IEEE International Conference on Consumer Electronics (ICCE), 2012, pp. 53–54. [21] M. Stihler, A. Santin, A. Marcon, J. Fraga, Integral federated identity management for cloud computing, in: The 5th International

110

[22]

[23] [24] [25]

[26] [27]

[28] [29] [30]

[31]

[32]

[33]

[34]

[35] [36] [37]

[38]

[39]

[40]

I. Khalil et al. / Computer Networks 65 (2014) 99–110 Conference on New Technologies, Mobility and Security (NTMS), 2012, pp. 1–5. P. Zhang, H. Sun, Z. Yan, Building up trusted identity management in mobile heterogeneous environment, in: 10th IEEE International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom), 2011, pp. 873–877. https://blogs.rsa.com/anatomy-of-an-attack/ (accessed 10.01.14). www.lastpass.com/adobe (accessed 10.01.14). 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. http://www.gtcybersecuritysummit.com/2014Report.pdf (accessed 10.01.14). http://www.newscenter.gatech.edu/2013/11/06/georgia-tech-warnsthreats-cloud-data-storage-mobile-devices-latest-%E2%80%98emerging-cyber (accessed 10.01.14). http://resources.infosecinstitute.com/android-master-key-vulnerability-poc/ (accessed 10.01.14). https://sites.google.com/site/openidreview/issues (accessed 10. 01.14). T. Han, N. Zhang, K. Liu, B. Tang, Y. Liu, Analysis of mobile WiMAX security: vulnerabilities and solutions, in: IEEE International Conference on Mobile Ad Hoc and Sensor Systems (MASS), Atlanta, Georgia, 2008, pp. 828–833. I. Khalil, ELMO: energy aware local monitoring in sensor networks, IEEE Trans. Dependable Secure Comput. 8 (4) (2011) 523–536. I. Khalil, MCC: mitigating colluding collision attacks in wireless sensor networks, in: Proceedings of the IEEE Global Communications Conference (IEEE GLOBECOM’10), Miami, Florida, USA, December 6– 10, 2010, pp. 1–5. I. Khalil, MPC: mitigating stealthy power control attacks in wireless ad hoc networks, in: Proceedings of the IEEE Global Communications Conference (IEEE GLOBECOM’09), Honolulu, Hawaii, USA, November 30–December 4, 2009, pp. 1–6. I. Dacosta, S. Chakradeo, M. Ahamad, P. Traynor, One-time cookies: preventing session hijacking attacks with stateless authentication tokens, ACM Trans. Internet Technol. 12 (1) (2012) 1:1–1:24. http://www.ieee-globecom.org/2012/private/T10F.pdf (accessed 10.01.14). http://www.oracle.com/technetwork/java/javase/overview/index. html (accessed 10.01.14). R. Sanchez, F. Almenares, P. Arias, D. Diaz-Sanchez, A. Marin, Enhancing privacy and dynamic federation in IdM for consumer cloud computing, IEEE Trans. Consum. Electron. 58 (1) (2012) 95–103. I. Hababeh, I. Khalil, A. Khreishah, Designing high performance webbased computing services to promote telemedicine database management system, IEEE Trans. Serv. Comput. (2) (2014). 10.1109/TSC.2014.2300499. J. Shi, M. Taifi, A. Khreishah, J. Wu, Sustainable GPU computing at scale, in: 14th IEEE International Conference in Computational Science and Engineering, 2011, pp. 263–272. J.Y. Shi, M. Taifi, A. Khreishah, Resource planning for parallel processing in the cloud, in: 2011 IEEE International Conference on High Performance Computing and Communications.

Issa Khalil received the B.Sc. and the M.Sc. degrees from Jordan University of Science and Technology in 1994 and 1996 and the PhD degree from Purdue University, USA in 2006, all in Computer Engineering. Immediately thereafter he worked as a post-doctoral researcher in the Dependable Computing Systems Lab of Purdue University until he joined the College of Information Technology (CIT) of the United Arab Emirates University (UAEU) in August 2007. In June 2013, Khalil joined Qatar Computing Research Institute (QCRI) of Qatar Foundation as a Senior Scientist. Khalil’s research interests span the areas of wireless and wireline communication networks. He is especially interested in security, routing, and performance of wireless Sensor, Ad Hoc and Mesh networks. Khalil’s recent research interests include 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 International Conference on Innovations in Information Technology and was appointed as a Technical Program Committee member and reviewer for many international conferences and journals. In June 2011, Khalil was granted the CIT outstanding professor award for outstanding performance in research, teaching, and service.

Abdallah Khreishah received his Ph.D. and M.S. degrees in Electrical and Computer Engineering from Purdue University in 2010 and 2006, respectively. Prior to that, he received his B.S. degree with honors from Jordan University of Science & Technology in 2004. In Fall 2012, he joined the ECE department of New Jersey Institute of Technology as an Assistant Professor. His research spans the areas of network coding, wireless networks, cloud computing, and network security.

Muhammad Azeem received his B.S in Information Technology from National University of Science and Technology, Pakistan. Currently, he is working as Research Assistant in College of IT, UAE University. His primary research interest is in Information Security and Data Mining.