Efficient and Secure Mobile Cloud Networking
EEfficient and Secure Mobile Cloud Networking
Jacques Bou Abdo
PhD Manuscript Sorbonne University Université Pierre et Marie Curie
Ecole Doctorale Informatique, Télécommunications et ElectroniquePour obtenir le grade de
DOCTEUR de l’Université Pierre et Marie Curie
Spécialité
SYSTEMES INFORMATIQUES ET RESEAUX
Efficient and Secure Mobile Cloud Networking
Jacques Bou Abdo
Présentée et soutenue publiquement le 18 Déc. 2014.Devant un jury composé de :
Francine Krief Rapporteur Professeur à Université de BordeauxNathalie Mitton Rapporteur Directeur de Recherche à InriaPascal Urien Examinateur Professeur à Telecom ParisTechStefano Secci Examinateur Maître de Conf. à UPMC - Sorbonne UniversitésProsper Chemouil Examinateur Directeur de Recherche à OrangeJacques Demerjian Encadrant Maître de Conf. à Université LibanaiseKablan Barbar Encadrant Professeur à Université LibanaiseGuy Pujolle Directeur Professeur à UPMC - Sorbonne UniversitésHakima Chaouchi Directrice Professeur à Telecom SudParis
Université Pierre et Marie Curie
Ecole Doctorale Informatique, Télécommunications et ElectroniquePour obtenir le grade de
DOCTEUR de l’Université Pierre et Marie Curie
Spécialité
SYSTEMES INFORMATIQUES ET RESEAUX
Efficient and Secure Mobile Cloud Networking
Jacques Bou Abdo
Présentée et soutenue publiquement le 18 Déc. 2014.Devant un jury composé de :
Francine Krief Rapporteur Professeur à Université de BordeauxNathalie Mitton Rapporteur Directeur de Recherche à InriaPascal Urien Examinateur Professeur à Telecom ParisTechStefano Secci Examinateur Maître de Conf. à UPMC - Sorbonne UniversitésProsper Chemouil Examinateur Directeur de Recherche à OrangeJacques Demerjian Encadrant Maître de Conf. à Université LibanaiseKablan Barbar Encadrant Professeur à Université LibanaiseGuy Pujolle Directeur Professeur à UPMC - Sorbonne UniversitésHakima Chaouchi Directrice Professeur à Telecom SudParis
Pierre and Marie Curie University
Doctoral School of Computer science, Communication and Electronics Submitted in partial fulfillment of the requirements for the degree of
DOCTOR OF SCIENCE of the Pierre and Marie Curie University
Specialization
COMPUTER SCIENCE AND NETWORKING
Efficient and Secure Mobile Cloud Networking
Jacques Bou Abdo
Defended publicly on 18 Dec. 2014.
Committee in charge:Francine Krief Reviewer Professor at Bordeaux UniversityNathalie Mitton Reviewer Head of research group at InriaPascal Urien Member Professor at Telecom ParisTechStefano Secci Member Assoc. Professor. at UPMC - Sorbonne UniversityProsper Chemouil Member Expert Program Leader at Orange LabsJacques Demerjian Co-advisor Assoc. Professor at Lebanese UniversityKablan Barbar Co-advisor Professor at Lebanese UniversityGuy Pujolle Advisor Professor at UPMC - Sorbonne UniversityHakima Chaouchi Advisor Professor at Telecom SudParis
Ad maiorem Dei gloriam
Résumé
MCC (
Mobile Cloud Computing ) est un candidat très fort pour le NGN (
Next Generation Network ) qui permet aux utilisateurs mobiles d’avoir une mobilité étendue, une continuité de service et des performances supérieures. Les utilisateurs peuvent s’attendre à exécuter leurs travaux plus rapidement, avec une faible consommation de batterie et à des prix abordables ; mais ce n’est pas toujours le cas. Diverses applications mobiles ont été développées pour tirer parti de cette nouvelle technologie, mais chacune de ces applications possède ses propres exigences. Plusieurs MCA (
Mobile Cloud Architectures ) ont été proposées, mais aucune n'a été adaptée pour toutes les applications mobiles, ce qui a mené à une faible satisfaction du client. De plus, l'absence d'un modèle d'affaires ( business model ) valide pour motiver les investisseurs a empêché son déploiement à l'échelle de production. Cette thèse propose une nouvelle architecture de MCA (
Mobile Cloud Architecture ) qui positionne l'opérateur de téléphonie mobile au cœur de cette technologie avec un modèle d'affaires de recettes. Cette architecture, nommée OCMCA (
Operator Centric Mobile Cloud Architecture ), relie l'utilisateur d’un côté et le fournisseur de services Cloud (CSP) de l'autre côté, et héberge un cloud dans son réseau. La connexion OCMCA / utilisateur peut utiliser les canaux multiplex menant à un service beaucoup moins cher pour les utilisateurs, mais avec plus de revenus, et de réduire les embouteillages et les taux de rejet pour l'opérateur. La connexion OCMCA / CSP est basée sur la fédération, ainsi un utilisateur qui a été enregistré avec n’importe quel CSP, peut demander que son environnement soit déchargé de cloud hébergé par l'opérateur de téléphonie mobile afin de recevoir tous les services et les avantages de OCMCA.Les contributions de cette thèse sont multiples. Premièrement, nous proposons OCMCA et nous prouvons qu'il a un rendement supérieur à toutes les autres MCA (
Mobile Cloud rchitectures ). Le modèle d'affaires ( business model ) de cette architecture se concentre sur la liberté de l'abonnement de l'utilisateur, l'utilisateur peut ainsi être abonné à un fournisseur de cloud et être toujours en mesure de se connecter via cette architecture à son environnement à l'aide du déchargement et de la fédération. Etant donné qu’OCMCA offre des services pour les utilisateurs mobiles qui devront être authentifiés d'abord avec l'opérateur mobile avant l'authentification avec le CSP pour accéder à son environnement et les services enregistrés, nous proposons une authentification robuste et un protocole SSO (
Single Sign On ), nommé CE-AKA3 (
Ensured Confidentiality Authentication and Key Agreement protocol version 3 ), capable d'effectuer deux authentifications en parallèle. Ce protocole permet d'obtenir une réponse plus rapide que les mécanismes existants actuellement et réalise une authentification sécurisée et privée à la fois à la NAS (Non-Access Stratum) et aux couches applicatives.Deuxièmement, nous étudions les problèmes de la privaticité dans diverses applications de MCA (
Mobile Cloud Applications ) et montrons que les mécanismes de protection de la privaticité implémentés dans des MCA (
Mobile Cloud Architectures ) existants n’offrent pas des niveaux satisfaisants. Nous présentons également qu’OCMCA peut offrir des niveaux de la privaticité plus élevés pour les applications exposées et peut être étendu pour devenir une interface d'interception légale.Troisièmement, nous prouvons, en utilisant un modèle mathématique, que notre proposition d'utiliser la fédération est financièrement réalisable. Nous montrons également que la fédération sans surveillance pourrait entraîner des conséquences catastrophiques sur la performance, sur les retards et sur la congestion du réseau. Pour résoudre ce problème, nous proposons un nouveau CFM (
Cloud Federation Manager ) appelé BBCCFM (
Broker-Based Cross-Cloud Federation Manager ), pour être utilisé par OCMCA. Ce CFM (
Cloud Federation Manager ) facilite la sélection des offres de la fédération tout en les surveillant pour prévenir les risques indiqués. BBCCFM aboutit à un faible retard, trafic et coûts en consolidant les demandes à un nœud central (
Broker ) et la formation d'une économie d'échelle. BBCCFM a une disponibilité comparable à d'autres mécanismes distribués et est conforme aux recommandations du "Cloud Security Alliance".
Mots Clés:
Mobile Cloud Computing, modèle d'affaires, sécurité, confidentialité, crowdsourced location based services, cloud federation, EPS, AKA bstract
Mobile cloud computing is a very strong candidate for the title "Next Generation Network" which empowers mobile users with extended mobility, service continuity and superior performance. Users can expect to execute their jobs faster, with lower battery consumption and affordable prices; however this is not always the case. Various mobile applications have been developed to take advantage of this new technology, but each application has its own requirements. Several mobile cloud architectures have been proposed but none was suitable for all mobile applications which resulted in lower customer satisfaction. In addition to that, the absence of a valid business model to motivate investors hindered its deployment on production scale. This dissertation proposes a new mobile cloud architecture which positions the mobile operator at the core of this technology equipped with a revenue-making business model. This architecture, named OCMCA (Operator Centric Mobile Cloud Architecture), connects the user from one side and the Cloud Service Provider (CSP) from the other and hosts a cloud within its network. The OCMCA/user connection can utilize multicast channels leading to a much cheaper service for the users and more revenues, lower congestion and rejection rates for the operator. The OCMCA/CSP connection is based on federation, thus a user who has been registered with any CSP, can request her environment to be offloaded to the mobile operator's hosted cloud in order to receive all OCMCA's services and benefits.The contributions of this dissertation are multifold. First, we propose OCMCA and prove that it has superior performance on all other mobile cloud architectures. The business model of this architecture focuses on user's subscription freedom, i.e. the user can be subscribed with any cloud provider and still be able to connect through this architecture to her environment with the help of offloading and federation. Since OCMCA offers services to mobile users who should be authenticated first with the mobile operator before authenticating with the CSP to gain access to her environment and registered services, we propose a robust authentication and single-sign-onprotocol, named EC-AKA3 (Ensured Confidentiality Authentication and Key Agreement protocol version 3), capable of performing both authentications in parallel. This protocol achieves faster response than currently existing mechanisms and achieves secure and private authentication at both NAS (Non-Access Stratum) and application layers.Second, we study privacy problems in various mobile cloud applications and show that privacy preserving mechanisms implemented at existing mobile cloud architectures fail to offer satisfactory levels. We also show that OCMCA can offer higher privacy levels for the discussed applications and can be extended to become a lawful interception interface. Third, we prove, using a mathematical model, that our proposition to use federation is financially feasible. We also prove that unmonitored federation might result in catastrophic impact on performance, delay and network congestion. To solve this problem we propose a new cloud federation manager called BBCCFM (Broker-Based Cross-Cloud Federation Manager), to be used by OCMCA. This manager facilitates the selection of the federation offers while monitoring it to prevent the shown hazards. BBCCFM results in lower delay, traffic and cost by consolidating requests at a centralized node (Broker) and forming economy of scale. BBCCFM has a comparable availability to other distributed mechanisms and is compliant with the recommendations of "Cloud Security Alliance".
Key Words:
Mobile Cloud Computing, business model, security, privacy, crowdsourced location based services, cloud federation, EPS, AKA. able of Contents
CHAPTER 1 INTRODUCTION ............................................................................................................ 11.1. Introduction................................................................................................................................... 11.2. Objectives and Workflow ............................................................................................................. 21.3. Background ................................................................................................................................... 61.3.1. Cloud computing................................................................................................................... 61.3.2. Mobile cloud computing ....................................................................................................... 91.3.3. EPS architecture.................................................................................................................... 91.3.4. EPS AKA ............................................................................................................................ 141.4. Organization of this Report......................................................................................................... 19CHAPTER 2 MOBILE CLOUD ARCHITECTURE: PERFORMANCE AND BUSINESS MODEL202.1. Introduction................................................................................................................................. 202.2. State-of-the-Art ........................................................................................................................... 212.2.1. Mobile Cloud Architectures................................................................................................ 212.2.1.1. Cloud computing with mobile terminals......................................................................... 222.2.1.2. Virtual cloud computing provider................................................................................... 232.2.1.3. Cloudlet........................................................................................................................... 242.2.1.4. CloneCloud ..................................................................................................................... 252.2.2. Mobile cloud Applications.................................................................................................. 252.3. Architectures evaluation ............................................................................................................. 282.3.1. Architecture Requirements ................................................................................................. 282.3.2. Application configuration ................................................................................................... 322.3.3. Network configuration ........................................................................................................ 332.3.4. Simulation Results .............................................................................................................. 342.3.5. Result Analysis ................................................................................................................... 372.3.5.1. Cloud computing with mobile terminals vs. Virtual cloud computing provider............. 382.3.5.2. Cloud computing with mobile terminals vs. Cloudlet..................................................... 382.3.5.3. Virtual cloud computing provider vs. Cloudlet............................................................... 392.3.5.4. Architecture Ranking ...................................................................................................... 39
HAPTER 1 INTRODUCTION1.1. Introduction
Cloud computing is a concept reforming IT industry and consequently changing how companies look into IT infrastructure. Reduced CAPEX (Capital Expenditures) and pay-as-you-go mode is best suiting startups and SMEs (Small and Medium Enterprises) to outsource their computation resources [1] [2] and focus their capital on creating a competitive edge against other products and services. Even though many companies (especially major ones) are reluctant to migrate their data to the cloud [1], non-corporate end users are easily adopting this new trend.Weak privacy and business models are two main aspects delaying wide adoption of computation outsourcing [3]and hindering an investment boom until having all these concerns tackled.With its mobility, reduced latency and increased bandwidth, mobile networks are becoming the network of choice for many corporate and non-corporate users to connect to Internet. Mobile devices are increasingly popular and currently constituting 40% of Internet accessing devices [4].Cloud-based mobile applications are expected to reach 9.5$ billion by end of 2014 [4]. Cloud and mobile computing are performing a successful and very promising tag team which is estimated to dominate the storage and processing traffic over the Internet.Mobile cloud computing is a very strong candidate for the title "The Next Generation Network" which empowers mobile users with extended mobility, service continuity and superior performance. Its main concept lays in offloading a job from a resource-limited mobile device to be executed at the cloud and then receiving the result once done. Users can expect to execute their jobs faster, with lower battery consumption and affordable prices; however this is not always the case. Various mobile applications have been developed to take advantage of this new technology, but each application has its own requirements. Several mobile cloud architectures have been proposed in literature but none was suitable for all mobile cloud applications and this acques Bou Abdo 2 leads to low customer satisfaction for all the customers using the applications not suited by the implemented architecture.Having a mobile cloud architecture suitable for all applications is simply a must, but it is not enough. A valid business model that motivates investors is a vital factor in making any technology reach deployment phase. This fact emphasizes the need for a technology capable of satisfying the requirements of both major players (users and investors) who control the dynamics of market strategy.This thesis targets at proposing competitive mobile cloud architecture based on an interesting business model which motivates investors, especially mobile operators. This architecture should be future-proof by being compatible with horizontal federation, the destiny of maturing industries. This thesis also targets at proposing a multi-layer private authentication and single-sign-on protocol in addition to various privacy applications on the proposed mobile cloud architecture. In the following, the main objectives, challenges and our approaches for achieving this goal are described.
Mobile cloud computing is a very promising technology that provides its users a wide range of services and its operators elevated user traffic. This trend is putting the infrastructure providers (mobile operators) face to face with critical problems such as: demanding QoS (Quality of Service), investment optimization, user privacy, scalability etc. We are able to tackle these problems in four interdependent and incremental objectives:
Objective 1: Resource optimizing mobile cloud architecture . We proposed anarchitecture (titled OCMCA: Operator Centric Mobile Cloud Architecture) taking into consideration its ability to offer very competitive QoS which satisfies users' requirements. The QoS parameters used in evaluating the architecture's performance are specifically selected to represent the users' interest. This erformance and Security in Mobile Cloud Computing 3 architecture is able to achieve high profits, penetration rates and investment optimization. This objective is met in chapter 2. Reference papers are: • •
J. Bou Abdo, J. Demerjian, H. Chaouchi, K. Barbar and G. Pujolle, "Operator Centric Mobile Cloud Architecture", IEEE Wireless Communications and Networking Conference (IEEE WCNC 2014).
Extended privacy offered by the mobile cloud architecture . The proposed architecture should offer elevated privacy level for its users. We divide the provided privacy mechanisms into two categories:
Objective 2: Pre-authentication : This category contains the AKA(Authentication and Key Agreement) and SSO (Single-Sign-On)mechanisms which will be executed in the absence of a secure context to establish one. This objective is met in chapter 3 using a protocol titled EC-AKA3 (Ensured Confidentiality Authentication and Key Agreement protocol version 3). Reference papers are: • •
J. Bou Abdo, H. Chaouchi and M. Aoude, "Ensured Confidentiality Authentication and Key Agreement Protocol for EPS". 3rd Symposium on Broadband Networks and Fast Internet, 28-29 May 2012. IEEE. • •
J. Bou Abdo, H. Chaouchi and J. Demerjian, "Security v/s QoS for LTE Authentication and Key Agreement protocol.", International Journal of Network Security & Its Applications Special Issue on:"Communications Security & Information Assurance". Sept 2012. • •
J. Bou Abdo, J. Demerjian, K. Ahmad, H. Chaouchi and G. Pujolle, "EPS mutual authentication and Crypt-analyzing SPAKA". International Conference on Computing, Management and Telecommunications (ComManTel 2013), 22-24 Jan 2013. IEEE. • •
J. Bou Abdo, J. Demerjian, H. Chaouchi and G. Pujolle, "EC-AKA2 a revolutionary AKA protocol". International Conference onComputer Applications Technology (ICCAT 2013), 20-22 Jan 2013. IEEE. acques Bou Abdo 4 • •
J. Bou Abdo, J. Demerjian, H. Chaouchi, K. Barbar and G. Pujolle, "Single-Sign-on in Operator Centric Mobile Cloud Architecture", 17th IEEE Mediterranean Electrotechnical Conference (IEEEMelecon 2014).
Objective 3: Post-authentication : This category contains location-privacy-preserving-mechanisms and identity privacy/investigation dilemma which takes place in the presence of a trust context. This objective is met in chapter 3. Reference papers are: • •
J. Bou Abdo, J. Demerjian and H. Chaouchi, "Security in Emerging 4G Networks", Next-Generation Wireless Technologies, ISBN 978-1-4471-5164-7, Springer 2013. • •
J. Bou Abdo, J. Demerjian, H. Chaouchi, K. Barbar and G. Pujolle, "Privacy in Crowdsourcing location based services", 3rd IEEE International Conference on Cloud Networking (IEEE CloudNet).
Ensuring scalability through federation.
Future-proof mobile cloud architecture should consider its scalability, especially with the forecasted increase in traffic. Two aspects should be considered to ensure system-wide scalability which are:
Access Network scalability . If the current 5G research initiative succeeded in achieving its targets, access network scalability can be ensured for undetermined period. This aspect is considered outside the scope of this manuscript.
Objective 4: Computation/Storage scalability . Federation is considered an important scalability and business continuity factor in cloud computing.A federation establishment mechanism should be proposed to maintain the financial feasibility of this scalability solution. This objective is met in chapter 4. Reference papers are: • •
J. Bou Abdo, J. Demerjian, H. Chaouchi, K. Barbar and G. Pujolle, "Broker-Based Cross-Cloud Federation Manager", 8 th International Conference for Internet Technology and Secured Transactions (ICITST-2013). IEEE. erformance and Security in Mobile Cloud Computing 5 • •
J. Bou Abdo, J. Demerjian, H. Chaouchi, K. Barbar and G. Pujolle, "Macro-economy effect on cloud federation", 3rd IEEE International Conference on Cloud Networking (IEEE CloudNet). • •
J. Bou Abdo, J. Demerjian, H. Chaouchi, K. Barbar and G. Pujolle, "Federation means cash ", 3rd International Conference on e-Technologies and Networks for Development (ICeND 2014). IEEE. • •
J. Bou Abdo, J. Demerjian, H. Chaouchi, K. Barbar and G. Pujolle, "Cloud federation? We are not ready yet", 6th International Symposium on Cyberspace Safety and Security (CSS 2014). IEEE.The objectives and the contribution workflow are presented graphically in figure 1.1.Figure 1.1 Contribution division acques Bou Abdo 6
Many definitions for cloud computing can be found in literature, each trying to give a complete and specific explanation of what this technology is all about. We start by surveying these definitions and then give our own based on the lessons learnt. Cloud computing is:"a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction." [5]."a parallel and distributed computing system consisting of a collection of inter-connected and virtualized computers that are dynamically provisioned and presented as one or more unified computing resources based on Service-Level Agreements (SLA) established through negotiation between the service provider and consumers." [6][7]."a large pool of easily usable and accessible virtualized resources (such as hardware, development platforms and/or services). These resources can be dynamically reconfigured to adjust to a variable load (scale), allowing also for an optimum resource utilization. This pool of resources is typically exploited by a pay-per-use model in which guarantees are offered by the Infrastructure Provider by means of customized Service Level Agreements." [7][8]."hardware-based service offering compute, network, and storage capacity where: Hardware management is highly abstracted from the buyer, buyers incur infrastructure costs as variable OPEX, and infrastructure capacity is highly elastic." [7][9].We believe that cloud computing can be better described by two complementary definitions, one conveying the user's perspective and the other conveying the provider's. So wedefine cloud computing to be:Online, infinite-like, easily provisioned and pay-as-you-go resource pool that are bound by SLAs. erformance and Security in Mobile Cloud Computing 7
Pool of resource under the management of a centralized entity that is capable of dynamically provisioning it.The user can offload her job (computation, storage, etc.) to the cloud to decrease the utilization at her local devices and to get additional functionalities she doesn't have locally. The advantages and disadvantages of cloud computing as described in [10] are shown in table 1.1.Table 1.1 Advantages and disadvantages of cloud computing
Advantages Disadvantages
Lower-Cost Computers for Users Requires a Constant Internet ConnectionImproved Compatibility Between Operating Systems Doesn’t Work Well with Low-Speed ConnectionsLower IT Infrastructure Costs Features Might Be LimitedFewer Maintenance Issues Stored Data Might Not Be SecureLower Software Costs If the Cloud Loses Your Data, You’re ScrewedInstant Software UpdatesIncreased Computing PowerUnlimited Storage CapacityIncreased Data SafetyImproved PerformanceImproved Document Format CompatibilityEasier Group CollaborationUniversal Access to DocumentsLatest Version AvailabilityRemoves the Tether to Specific DevicesThe cloud architecture stack is composed of three main layers [11]: SaaS (Software as a Service), PaaS (Platform as a Service) and IaaS (Infrastructure as a Service) as shown in figure 1.2. Additional service layers are continuously proposed to add supporting features, such as PasS[12] and HuaaS[11].IaaS is the only presented layer, in this introduction, because of its importance to inter-cloud federation which is thoroughly discussed in chapter 4. It is the bottom layer at the cloud stack and nearest to the hardware. It enables on-demand provisioning of servers [7]. IaaS offers two services: VRS (Virtual Resource Set) and PRS (Physical Resource Set) [13]. PRS is hardware dependant and creates an abstraction layer to be used by VRS. VRS is hardware independent and used to monitor virtualized applications. One of the most dominant VRS acques Bou Abdo 8 monitor technologies is called hypervisor or VMM (Virtual Machine Monitor) where the virtualized applications are user virtual machines [7]. VIM (Virtual Infrastructure Manager), regardless of its underlying VMM layer, provides the tools for scheduling and managing VMs across multiple physical layers [14]. VRS, PRS, VIM and VMM are shown in figure 1.2.
SaaSPaaSIaaS
PRS (Hardware infrastructure)VMM or HypervisorVirtualInfrastructureManager
Monitoruser OS
APP
Monitoruser OS
APP
VRS
Figure 1.2 Cloud stack (Well-known layers)Cloud Manager Layer is still needed to completely define the cloud. It provides cloud-like interfaces and higher-level functionalities for authentication, identity management, contextualization and VM disk image management [16]. The cloud manager layer contains also the federation manager [15] which performs the following abstracted operations:The first operation is selecting a cloud provider (foreign) having its IdP (Identity Provider) trusted by the client's (the cloud experiencing saturation and interested in federation) IdP, then establishing a secure connection after successful authentication.The second operation is transferring the VMs (Virtual Machine) and extending the hypervisor. erformance and Security in Mobile Cloud Computing 9
Mobile cloud has been considered by [17] to be a collection of mobile devices within the same vicinity all having interest in processing the same data. In this case, the processing cost (battery power and CPU cycles) will be divided on the participating devices and hopefully fulfilling mobile cloud's goals. Mobile cloud is controversial since we are expecting one architecture to be adequate for all mobile applications, always decreasing power consumption in mobile devices and most importantly cheap. No architecture found in literature was able tosatisfy the above expectation, and none was standardized.Mobile cloud computing has been understood differently by the research community and this explains the deep difference in defining this technology and designing its architectures. To give a generalized definition which includes all points of view and architectures, it should be abstract and doesn't specify detailed features. For this reason, we define mobile cloud computing as: "A technology which allows the user to access cloud services through mobile devices".
EPS architecture
EPS (Evolved Packet System) [18] is the 4 th generation of an extensively used mobile communication system, which has at least 30 years of cumulative experience in large-scale deployments and global interoperability. It is the first all-IP 3GPP release which was designed to be backward compatible with previous releases.Although EPS offers considerably low latency and high traffic rates, current standardization efforts are attempting to enhance mobile networks' performance to be able to cope with the increasing user demand. These attempts are mainly focusing on RAN (Radio Access Network) with minor modification on the core resulting in future proof services.In addition to its elevated QoS performance, EPS has the following benefits [19]:Reduced cost per bit.Increased service provisioning. acques Bou Abdo 10 Flexible use of existing and new frequency bands.Simplified architecture and open interfaces.Reasonable terminal power consumption. erformance and Security in Mobile Cloud Computing 11Figure 1.3 EPS architectureacques Bou Abdo 12
EPS architecture is shown in figure 1.3, where the following entities are presented:
UE (User Equipment) : is the device which allows the user to access the network [20].Some of its functions are [21]: o Contains the authentication information which will be used to authenticate the user during EPS-AKA (Authentication and Key Agreement) as will be shown in the coming section. o Supports LTE uplink and downlink air interface. eNB (Evolved Node B) : is the entity responsible for delivering user and control plane traffic to UE over the air channel. Some of its functions are [21]: o IP header compression and ciphering of user data stream. o Radio resource management.
MME (Mobility Management Entity) : is the entity responsible for handling NAS (Non-Access Stratum) [22] control plane traffic also known as signaling. Some of its functions are [21]: o Tracking Area list management. o Authentication and Key Agreement. o Lawful Interception of signaling traffic.
HSS (Home Subscriber Server) : is defined in the standard as: "It is the entity containing the subscription-related information to support the network entities actually handling calls/sessions" [20]. It is a very important entity in AKA as will be shown in the coming section. Some of its functions are [21]: o Stores the subscriber data. o Generates the AVs (Authentication Vector) used in AKA. o Used in locating the current position of the user (on MME layer) i.e. finds which MME the user is currently attached to. erformance and Security in Mobile Cloud Computing 13
S-GW (Serving GateWay) : is RAN's interface with the core network for user plane traffic. Some of its functions are [21]: o Lawful Interception [23-25]. o Packet routing and forwarding [20]. o Local anchor point for inter-eNB handover.
P-GW (PDN-GateWay) : acts as the mobile network's gateway router toward PDN (Packet Data Network) for both LTE (E-UTRAN) [79] and pre-LTE (GERAN and UTRAN) technologies. Some of its functions are [21]: o Per-user based packet filtering. o UE IP addresses allocation.
PCRF (Policy and Charging Rules Function) : is the entity responsible for services charging control. It is described in the standard as: "In order to allow for charging control, the information in the PCC (Policy and Charging Control) rule identifies the service data flow and specifies the parameters for charging control. The PCC rule information may depend on subscription data. For the purpose of charging correlation between application level (e.g. IMS) and service data flow level, applicable charging identifiers shall be passed along within the PCC architecture, if such identifiers are available" [26]. Some of its functions are decides how services shall be treated in the PDN gateway [21] based on the related subscription.
IMS (IP Multimedia Subsystem) : is the entity responsible for offering multimedia services' content and related signaling. IMS services are "based on an IETF defined session control capability which, along with multimedia bearers, utilizes the IP-Connectivity Access Network" [27].In figure 1.3, the Red line represents normal data traffic between the mobile user and the destination (other mobile user, Web server, etc.). In case the two communicating parties are connected to the same operator, then the traffic will bounce at PGW without reaching PDN. The acques Bou Abdo 14
Blue line describes the path followed by user plane traffic of the services offered by the operator. The green line describes the path followed by the user generated control plane (signaling) traffic.
A telecom operator offers restricted services to its customers and roaming users from other operators (if a roaming agreement exists with the user’s home network). The operator has to filter out illegitimate users, and be able to bill those who benefit from the offered services. The procedure for identifying and authenticating users is shown in figure 1.4 [28].The conceptual algorithm shown in figure 1.4 is used to define an abstract call flow having the following operations fulfilled sequentially:User identificationNetwork authenticationMobile authenticationNetwork authentication (serving network authentication) was first added in EPS. The above call flow is valid for UMTS if network authentication is removed.In UMTS and its predecessors, after authentication, the user can only assure “that he is connected to a serving network that is authorized by the user’s HN to provide him services; this includes the guarantee that this authorization is recent” [29]. Security network authentication was considered unnecessary in UMTS, since there was an assumption of mutual trust among UMTS operators [30].In EPS this assumption is considered not valid, thus serving network authentication was added to ensure that the serving network’s identity is really confounded with what it is claiming.In other words, the user is connecting to the same network which its home operator has generated the AV (Authentication Vector) to. erformance and Security in Mobile Cloud Computing 15
The protocol responsible for identification and authentication in 3GPP mobile technologies is called AKA (Authentication and Key Agreement). More information on 3GPP EPS AKA is presented next.EPS identifies subscribers permanently using a unique identifier called IMSI (International Mobile Subscriber Identity) [30]. Size of IMSI is 15-digits and divided into 3 digits for MCC (Mobile Country Code), 2 for MNC (Mobile Network Code) and 10 for MSIN (Mobile Subscriber Identification Number). Capturing a user’s permanent identifier transmitted over the air channel can be used to detect the user’s current position in addition to user tracking and other privacy breaching attacks. 3GPP has tried to overcome these attacks by introducing a new temporary identifier, GUTI (Globally Unique Temporary UE Identity), to provide an unambiguous identification of the UE. GUTI is only relevant in the serving MME’s area, thus it is sent by the network over a non-access stratum layer connection when confidentiality and integrity protected.A user’s GUTI is not expected to be constant over a long period of time, since it can then be used in user tracking instead of IMSI. GUTI might be updated in an attach accept message, tracking area update accept message or GUTI reallocation command. This modification is presented in using GUTI instead of previously used TMSI (Temporary Mobile Subscriber Identity).As mentioned above, GUTI is only transmitted when the NAS layer connection is confidentiality and integrity protected. Confidentiality and integrity protection is enabled only after key sharing which is a late step in the access control mechanism. Conceptual steps in access control are: identification, authentication, authorization, key sharing, and finally enabling secure access. It can be seen from the discussed steps that identification occurs before establishing a secure connection, thus user identities are transmitted in plain text. Confidential identification is a very expensive task when compared to confidential data exchange in a security established connection, thus a compromise has to be made between additional costs resulting from ID hiding and high level of privacy. This dilemma faced the designers of GSM, UMTS, and finally LTE. acques Bou Abdo 16
Network to UE:Identity requestUE to Network:Registration request (to be able to benefit from Services.)Is the identifier valid?Network to UE:AuthenticationRequest(Challenge)Network: Getinformation from repository “HSS”UE to Network:challenge reply IdentificationNetwork AuthenticationUE: Is the received challenge valid?Network: Is the received reply authentic? Mobile AuthenticationThe user is identified,authenticated and allowed to use the services
Figure 1.4 Identification and authentication conceptual algorithm erformance and Security in Mobile Cloud Computing 17
AKA (Authentication and Key Agreement procedure) is responsible for user identification, user authentication, network authentication and generation of master keys, which will be used to derive the keys used in deriving the confidentiality and integrity keys. This procedure includes UE (User Equipment), eNB (evolved NB), S-MME (Serving network’s MME) and H-HSS (Home network HSS) as seen in figure 1.5.Figure 1.5 EPS authentication and key agreement protocol
EPS AKA procedure shown in figure 1.5 is as follows:
1. -MME: NAS Attach Request (IMSI)
A user interested in connecting to a network, if the user has no previous temporary identifier, he has to identify himself by transmitting his permanent identifier (IMSI) in a NAS acques Bou Abdo 18 attach request. If the user has a temporary identifier from a previous connection, he can send his GUTI||LAI/RAI. The S-MME will contact the MME serving the LAI sent by the user, if it succeeded in retrieving GUTI/IMSI couplet it proceeds to step 2, else it requests the user to send his permanent identifier.
2. S- -HSS: Authentication Info Request (IMSI, SNID)
S-MME retrieves MCC||MNC from IMSI and route the request to H-HSS concatenated with the serving network’s ID (IMSI||SNID). It then concatenates its ID to the request send by the user and forwards it to the corresponding HSS.
3. H- -MME: Authentication Info Answer (RAND || XRES || KASME || AUTN)
The H-HSS fetches for IMSI/K/SQN triplet in its database. A random variable named RAND is generated. The remaining variables in the AV (Authentication Vector) are derived according to the following scheme:MAC = f1(K, AMF, SQN, RAND)AK = f5(K, RAND)AUTN = SQN xor (AK||AMF||MAC)CK = f3(K, RAND)IK = f4(K, RAND)KASME = KDF(CK, IK, SNID, (SQN xor AK))XRES = f2(K, RAND)AV = RAND||XRES|| KASME ||AUTNAV is then sent back to S-MME.
4. S- erformance and Security in Mobile Cloud Computing 19
MME forwards a challenge towards UE containing RAND and AUTN. UE verifies AUTN to authenticate legitimacy of the serving network. If the request is legitimate RES is generated in addition to the confidentiality and integrity keys.
5. -MME: Authentication Reply (RES)
UE replies to S-MME’s challenge with RES. S-MME compares RES (from UE) and XRES (from H-HSS), if they are equal then the user is authenticated, keys will be derived, NAS security context will be established and S-MME sends eNB the needed keys to establish AS security context.
The rest of this thesis is organized as follows. Chapter 2 proposes a resource optimizing mobile cloud architecture named OCMCA and rank this architecture against others found in literature to prove its superior performance. OCMCA's business model is also described in this chapter which is based on cloud federation. Chapter 3 proposes an authentication and single-sign-on protocol named EC-AKA3 which creates a trust context between the mobile user and her cloud provider passing through the mobile operator. Other privacy applications of OCMCA are presented in this chapter. Chapter 4 proves mathematically that cloud federation is financially feasible by itself in addition to its critical contribution to OCMCA's business model. This chapter also shows that "distance" is an important selection criterion to maintain the feasibility and profitability of cloud federation and proposes a federation manager to enforce this selection criterion. Finally chapter 5 summarizes our main conclusions, achievements and open issues for future research. acques Bou Abdo 20
CHAPTER 2 MOBILE CLOUD ARCHITECTURE: PERFORMANCE AND BUSINESS MODEL2.1. Introduction
Mobile technology experienced radical changes in its concepts, aims and needs after introducing smartphones and 4G networks. Protocol traffic overhead appears to be no more a critical problem since mobile networks are achieving high throughputs and new technologies (such as 5G) are promising even higher rates. Mobile devices are not necessarily the slim clients that used to dominate the network ten years ago. Smartphones are powerful devices capable of processing majority of mobile applications, but have very limited power resources (e.g. battery) and it is not likely to change in the foreseen future. Mobile devices, either computation/storage-limited (slim client) or power-limited (Smartphone), need a technology that helps in decreasing power consumption, delay and user's cost without compromising the privacy, availability and mobility offered by mobile networks.Mobile cloud computing is on-demand, dynamic and self-provisioned outsourcing of IT resources from a centralized service provider over a mobile access network. It is a technology that offloads resource-intensive applications from resource-limited mobile devices to be processed "somewhere else". This technology aims to decrease mobile's power consumption, allow complex applications to be managed from mobile devices and most importantly keep the expenses within the user's cost budget.Many mobile applications are multicast-based in nature (such as: Google cloud messaging platform [31], multimedia applications and same-content delivery applications like:Google play, Apple store, etc.) but its physical implementation and mobile network's characteristics transform its communication into a group of unicast messages leading to unnecessary congestion, additional delay and more expensive fees. None of the mobile cloud architectures found in literature exploited this weakness but rather adopted it to become an inherited mobile cloud limitation. erformance and Security in Mobile Cloud Computing 21
In order to solve this problem and make mobile cloud computing more agreeable and efficient for both customers and operators, network core adaptations should be considered. In this chapter we discuss mobile cloud from telecommunication perspective by proposing an innovative architecture and interesting business model. This new architecture keeps the mobile operator at the center of mobile cloud computing and offers revenue-making business model that motivates operators to invest in this technology.The rest of this chapter is organized as follows: In section 2.2 we survey existing mobile cloud architectures and applications found in literature. Section 2.3 presents the architecture requirements that are used to measure architecture performance and evaluate its suitability for various mobile cloud applications. It also presents the simulation environment, configuration and results which are analyzed to rank the architectures. Section 2.4 presents our proposed architecture which benefits from the mobile network to offer superior services as shown in its performance comparison with all other architectures. In this section, we also present our proposed architecture's business model which draws the guidelines to offer high profitability and penetration rates. Section 2.5 summarizes this chapter.
Mobile cloud computing is relatively a new technology having lots of potential applications but no standardized architecture until nowadays. This motivated researchers to innovate different architectures each trying to emphasize on a certain requirement (such as mobility, power consumption, etc.) and select the optimal compromise for the others. In this section, we are going to survey existing mobile cloud architectures and applications found in literature.
As a result of many innovative attempts, various mobile cloud architectures have been proposed each exploiting a technology (such as: ad hoc Wi-Fi, p2p, mobile networks, etc.) that acques Bou Abdo 22 helps in emphasizing on one of MCC's requirements. The mobile cloud computing architectures found in literature are:
It is identical to the normal cloud computing architecture where computation is implemented in a remote cloud server (within the CSP's network), but the terminals in this case are mobile devices such as PDAs, Smart Phones, etc. Mobile devices connect to the Internet, in most of the cases, over an expensive connection such as LTE, UMTS and GPRS [32].Connecting through Wi-Fi interface is also possible but it creates many concerns regarding mobility such as: network availability, handover, etc. An example on the above concerns is shown in the following use case: The user is accessing her CSP using a mobile device over a Wi-Fi network offered at the coffee shop she is currently in. Leaving the coffee shop makes her drop the connection and loses the cloud service. This architecture is shown in figure 2.1.Figure 2.1"Cloud computing with mobile terminals" architecture erformance and Security in Mobile Cloud Computing 23
This architecture proposes the creation of a virtual cloud from peer-to-peer connected mobile devices over an ad-hoc Wi-Fi connection to share processing burden [17]. P2P nodes participate only if found in the vicinity (Wi-Fi range) and interested in the processed data. After selecting the mobile devices participating in this virtual cloud, the job requestor divides the job into tasks and offloads each to a participant. After processing the task, the participant repliesback with his processed data which is consolidated by the requestor to get the final result. These results are sent back to the participants. This architecture is shown in figure 2.2.Figure 2.2"Virtual cloud computing provider" architecture acques Bou Abdo 24
This architecture proposes installing cloudlet servers in high density areas (such as: coffee shops, malls, etc.) collocated with Wi-Fi hotspots [33]. The user connects to the cloudlet server and offloads its job to be processed. It contacts the user's cloud service provider to retrieve the user's environment through federation. Starting this point, future jobs will be processed at the cloudlet until getting disconnected (user leaves the hotspot coverage). This architecture is shown in figure 2.3. Figure 2.3"Cloudlet" architecture erformance and Security in Mobile Cloud Computing 25
It is having a clone of the mobile device running in cloud. This solution uses an application-level virtual machine that can partition an application and run one part on the mobile device and the other at the clone. This solution works at the application layer to decide which portion of an application should be offloaded to the cloud [32][34].CloneCloud is an application layer solution, while all other architectures discussed aboveare physical layer and try to answer different questions (such as: how to connect to the cloud network? is user mobility ensured? how to ensure user confidentiality?, etc.). CloneCloud is complementary to the other architectures, thus will not be included in the performance comparison. Cuckoo [35], various Cloudlet versions [36][37], Spectra [38], Chroma [39], Hyrax [40], MMPI (Mobile Message Passing Interface) framework [41], MobiCloud[42] and MAUI [43] are offloading mechanisms and frameworks for dynamic selection of code partitions (pieces of the program) to be executed remotely similar to CloneCloud so will not be included in the performance comparison.
Computation-intensive mobile applications are the best candidates for being transformed into mobile cloud applications. It has been shown in [44] that during 2012, games and messaging applications are the most popular from developer side (based on number of developed applications) but Facebook (76% of US Smartphone users), Google Maps (65.9%), Google Play (54.3%), Google Search (53.5%), Gmail (47.6%), YouTube (46.4%), Pandora Radio (42%), Apple iTunes (41%), Cooliris (38%) and Yahoo! Messenger (32%) are the most popular applications from user side (based on number of downloaded applications). The applications that that can benefit from multicast communication (Google Play, YouTube, Pandora Radio, Apple iTunes and Cooliris) constitute a majority of the top ranked mobile applications. In this section,we are going to present different computation-intensive mobile applications presented in literature [4] which is profiled and simulated in later sections. The applications are shown in table 2.1. acques Bou Abdo 26
Table 2.1 Computation-intesive mobile applications
Application group Application
OCR (Optical Character Recognition) :Isprocessing an image to extract the found characters/text. Various applications can be implemented on the text after extraction, such as translation.
Application 1 [4]: A foreign traveler tries to understand a street sign by capturing the image using his mobile, extracting the text using an OCR application and finally translating it to an understandable language. Another scenario for the same application was discussed in [17], where a foreign tourist is visiting a museum in South Korea. He is not able to understand an interesting exhibit written in Korean, so he captures the exhibit's image and tries to translate it using an OCR application. Since his mobile device is not able to process the captured image (due to limited or expensive resources such as RAM, Swap space and Internet connection), the application tries to scan nearby devices. Interested nearby devices create an ad hoc network and a virtual mobile cloud to process the image cooperatively. The extracted text is then translated to English.
Natural language processing : Is a useful tool for travelers to be able to communicate with locals.
Application 2 [45]: Text-to-speech is an application allowing a mobile user having a file to be read to locals
Crowd computing : Is a method allowing different video recordings captured by different mobile devices to construct a single video covering an entire event [40].
Application 3 (Lost child) [46]: A five years old John, is attending a parade with his parent in Manhattan. John goes missing and his parents report the incident to the Police, who send out an alert via a message to all mobile phones within two miles radius, requesting them to upload the parade images they have, to a server that only the police have access to. John is spotted in some images and his position was located, and he was reunited with his parents. This application requires high privacy as will be shown in section 3.3.2. Privacy is discussed in section 3.3.1. The participation invitation in this application is multicast/broadcast by nature.
Application 4 (Disaster relief) [46]: Electronic maps become useless after a disaster, thus hindering disaster relief teams from performing rescue operations efficiently. Local citizens are asked to use their mobile phones to photograph disaster sites, and upload it to a central server [4]. The collected images are used to create a panoramic view of the sites, thus facilitating the navigation of the relief teams. This application requires high privacy similar to application 3.
The participation invitation in this application is multicast/broadcast by nature.
Sharing GPS/Internet data [4]:
Instead of reading common data from internet or GPS by multiple users, one user can download the data and share it with interested nearby devices through local-area or peer-to-peer networks. This application group helps in decreasing the cost and delay [40] resulting
Application 5 [4]: Scans using Bluetooth for a co-located device which has a recent GPS reading. Instead of using the expensive GPS connection the needed information can be retrieved from co-located devices. The performance of this application augments in dense events such as: party, football match etc. Other format of this application is: "Traffic Lights Detector for Blind Navigation" [48].
The requestor's communication with other participants is multicast/broadcast by nature. erformance and Security in Mobile Cloud Computing 27 from downloading online information.
Application 6 [17]: Instead of downloading a P2P file from the internet over an expensive interface (GPRS, UMTS, LTE etc), a mobile user scans using Bluetooth for a nearby device which has downloaded the needed file and retrieve it over a less expensive interface (Bluetooth).
The requestor's communication with other participants is multicast/broadcast by nature.
Application 7 : We propose a new application which fits under this group. Bicycle fans gather yearly to watch "tour de France", a 23-day racing event [49], taking place mainly in France and other nearby countries. Fans and racers are interested in knowing the instantaneous detailed ranking of racers with additional information (the time difference between the first racer and other contestants, velocity etc.). Each user needs to receive the data on his device, which is transmitted to all application users. The transmitted data is similar to all the users and uses multicast/broadcast by nature.
Crowdsensing : Are used to share timestamped sensor readings, such as GPS, accelerometer, light sensor, microphone, thermometer, clock, and compass.
Application 8 [4]: Queries the users located in 1 mile radius to get the average temperature of nodes within a mile.
The requestor's communication with other participants is multicast/broadcast by nature.
Application 9 [40]: Traffic reporting can be implemented by querying the velocity distribution of all nodes within half a mile of the next highway on the current route.
The requestor's communication with other participants is multicast/broadcast by nature.
Multimedia search [4]: Mobile devices store many types of multimedia content such as videos, photos, and music which can be shared by other users.
Application 10 [40]: Multimedia files can be searched in the contents of nearby mobile devices.
The query in this application is multicast/broadcast by nature.
Social networking [4]:Sharing user content with friends on social media facilitates automatic sharing and P2P multimedia access, thus reducing the need for huge servers to manage this amount of data [40].
Application 11 [40]: Integrating Facebook with mobile cloud to share the active files using mobile interfaces.
Crowdsourcing : Is outsourcing tasks, used to be executed by machines or employees, into an external set of people [50][51].
Application 12: “Social search engine” is one of the most popular crowdsourcing application theme which focuses on answering context-related questions using human-help (crowd) instead of or in complementary with search engines [52][53].Chacha [54] and Aardvark [55] are two popular crowdsourcing applications that have similar objectives, but for detailed discussion, application 12 will represent Chacha. This application requires high privacy as shown in section 3.3.1.
Application 13: “Crowdsourced location-based service” is a method to fetch the recommendations about certain location based categories posted by people with taste and interest similar acques Bou Abdo 28to the requester. Foursquared[56] is a popular application offering crowdsourced location based service. This application requires high privacy as shown in section 3.3.1.
Mobile augmented reality [57][58] :Is the creation of an information-intensive virtual world confounded with the physical environment allowing the user to “display related information, to pose and resolve queries and to collaborate with other people” [57]. Mobile augmented reality (MAR) is running AR applications in the mobile environment
Application 14 [59]: “Google glasses” is a wearable computing platform which allows the person wearing those glasses to view the real word in addition to supplementary requested information. It can be used also to execute certain jobs such as sending messages, translating etc.
Wearable computing [57][58] :Accessing information generated (sensor) or received (downloaded) using mini-electronic devices having very limited battery, storage and computation resources.
Application 15:
A tool to measure the blood pressure, heart rate and other vital signs of the user and upload these information to be presented in real-time to the doctor.
There are other mobile cloud applications found in literature but are still under investigation, such as Cloud gaming [60][61][62][63], Mobile learning [60][64][65][66][67], and Mobile healthcare [60][68][69]. These applications cannot be profiled, due to the variety of proposed solutions and optimization techniques, thus will not be included in the simulation results.
In this section, we are going to prove that none of the architectures found in the literature is suitable for all applications and none can be selected as optimal. To do so, we start by showing the application requirements which is used to evaluate the performance of each architecture. We then profile each application into numerical values (application configuration) which is used in the simulation. The network is then configured into numerical values and finally the performance of all the architectures is shown and analyzed.
MCC (Mobile Cloud Computing) was developed to respond to mobile devices' needs for a technology that helps in decreasing power consumption, delay and user's cost without compromising the privacy, availability and mobility offered by mobile networks, as shown in erformance and Security in Mobile Cloud Computing 29 section 2.1. When designing a mobile cloud architecture several, requirements should be taken into consideration which represents the aim behind using MCC. Similarly, these requirements areused as metrics to evaluate the performance and compare the studied architectures. The requirements are divided into quantifiable and non-quantifiable as shown next:
Quantifiable requirements : can be calculated in numerical metrics. The quantifiable requirements are: • •
Cost : Financial cost due to network usage. Cost is calculated in terms of "financial units" relative to the mobile fees. An architecture better suits the application if it achieves lower cost. • •
Delay:
Transmission, propagation and processing delay. In case of in-house processing, it is the time between starting the execution and finishing the job. In case of offloading, it is the time between sending the first offloaded bit till receiving the last reply bit. Delay is calculated in milliseconds (ms). An architecture better suits the application if it achieves lower delay. • •
Power consumption : Power consumed by a mobile device during processing, transmission and waiting. It is calculated in power units. An architecture better suits the application if it achieves lower power consumption.
Non-quantifiable requirements : cannot be calculated in numerical metrics, but will be represented by subjective values. The non-quantifiable requirements are: • •
Privacy:
Privacy of data during transmission and processing. Privacy is considered high, if no private personal data is stored or processed in non-trusted devices. It is considered medium if private personal data (such as the temperature read by a mobile's sensor) is stored or processed in non-trusted devices, and considered low if private personal data is stored or processed in non trusted devices and can be correlated to the user's id. A cloudlet server is acques Bou Abdo 30 considered non-trusted since it is not under the supervision of a trusted provider. An architecture better suits the application if it achieves higher privacy. Architectures get disqualified if it is not able to satisfy the privacy requirements of an application. • •
Mobility:
The expected distance to be covered by a user before disconnecting from a service. Cloudlet servers can be accessed through local APs (Access Points) only, then this very short range hinders the device's online mobility especially that we don't expect LAN coverage to be continuous. We consider that Cloudlet offers very low mobility. In virtual cloud, the user has more mobility freedom since not bounded to the fixed position of the AP, but bounded to the group forming the virtual cloud he is connected. We consider this architecture offers medium mobility. The user in "Cloud computing with mobile terminals" has the freedom to move in the entire region covered by his or any another operator (using roaming). We consider this architecture offers high mobility. Since mobility is one of MCC's requirements, we consider that a studied architecture better suits an application if it achieves higher mobility. • •
Scalability:
Mobile applications downloaded in 2013 range between 56 and 82 billion and it is expected to reach 200 billion in 2017 [44]. Mobile cloud architectures are expected to experience high penetration rates which leave the researchers in front of a critical scalability issue. The architecture should be able to serve millions of users, handle the incremental traffic mobile networks are currently facing and most importantly offer a satisfying coverage in cities and major villages. Each architecture's scalability is studied separately:o
Cloud computing with mobile terminals:
This architecture offers excellent coverage and routes all the MCC jobs to be executed at CSP's premises. CSPs are able to process huge amount of jobs and extend his capability by federating some resources from other cloud providers. The only bottleneck is at transmission which might be overwhelmed with the erformance and Security in Mobile Cloud Computing 31 incremental traffic if no newer mobile technology is implemented. This architecture requires no investment in additional physical devices and able to support current traffic rates. This architecture is considered to have high scalability.o
Virtual cloud computing provider:
This architecture requires no investment in additional physical devices, but will have difficulties (delay and power drainage) in processing very complex applications since the participating mobile devices are sharing the load. A user interested in processing more complex applications should team up with more users, users with powerful mobile devices and/or upgrade his devices. This architecture is considered to have high scalability.o
Cloudlet:
This architecture requires the investment of random business owners in deploying physical devices (cloudlet servers) even with the absence of a valid business model. Cloudlets will face low utilization rates, over-investment and high rejection rates due to the traffic commuting. As residential areas are usually apart from business areas, the cloudlet servers in one area will be severely under-utilized throughout the period the users have commuted to other locations. This requires over-investment to offer acceptable services in different areas. If some areas are not well equipped, customer rejection rates will be elevated. This architecture is considered to have low scalability. • •
Multicast-capable : Boolean value specifying whether the studied architecture is capable of handling multicast traffic efficiently (not transforming it into bulk of unicast traffic). Since the majority of the top ranked mobile applications are multicast-based, having a multicast-capable mobile cloud architecture is of critical importance. acques Bou Abdo 32
In this section, we profile the mobile cloud applications into numerical values which areused, in the simulation shown later, as application configuration. Each presented application isprofiled using the following parameters:
Uploaded data : Size of the uploaded data which will be processed. Unit is byte.
Processing : The processing needed in terms of processing units to generate the response. Unit is "processing unit".
Downloaded data : Size of the processed data downloaded. Unit is byte.
Resource sharing : Boolean value represents whether the client requires accessing the resources (GPS, Internet, etc.) of the cloud server (cloudlet or other mobile devices generating a virtual cloud).To better simulate the architectures, each application is replaced by its profile and asample job will be executed. Application profiling is shown in table 2.2.Table 2.2 Application profiling
Application Uploaded Data (KB) Downloaded Data (KB) Processing(processing units) Resource sharing1
12 & 13
10 1 10,000 False erformance and Security in Mobile Cloud Computing 33
Network configuration
In this section, we show the network configuration we used to simulate various mobile cloud architectures and applications. The network is composed of two parts (end devices and transport network) and the configuration of each part is shown separately.Transport network configuration is based on LTE experimental values reported in [70][71] which are shown in Table 2.3.Table 2.3 Transport network configuration
Parameter Value
Air Interface Latency 8 mseNB Processing Latency 3 msAir Interface Upload bandwidth 0.35 MbpsAir Interface Download bandwidth 36 Mbps"Backhaul + Core" Delay 5 ms"Backhaul + Core" Upload bandwidth 100 Mbps"Backhaul + Core" Download bandwidth 100 MbpsS-GW/P-GW Processing Latency 2 msInternet Latency 25 msInternet Upload bandwidth 100 MbpsInternet Download bandwidth 100 MbpsEnd device configuration is retrieved from [72][73] and shown in Table 2.4.Table 2.4 End device configuration
Parameter Value
Mobile device (UE) processing speed 1000 unit per secondCloud processing speed (100X faster than UE) "Assumed" (depends on the used UE and VM) 100,000 unit per secondCloudlet Server processing speed [73] 5,000 unit per secondUE's power cost for sending 1 bit over Wi-Fi 1 power unitsUE's power cost for sending 1 bit over LTE [72] 23 power unitsUE's power cost while waiting for 1 second [73] 30,000,000 power unitsUE's power cost while computing over 1 second [73] 80,000,000 power unitsUE's cost for sending 1 bit over Wi-Fi to cloudlet 1 financial unitUE's cost for sending 1 bit over LTE (recorded in Lebanon on 1 - 100 financial units acques Bou Abdo 34
In this section, we show the simulation results of the mobile cloud architectures and applications presented earlier. The simulation used specially crafted C erformance and Security in Mobile Cloud Computing 35
Table 2.5 Performance evaluation of standalone mobile devices
Quantifiable Requirements (Lower values are better)
Non-quantifiable Requirements (Higher values are better)
Appl. Cost (financial units)
Delay (ms)
Power consumption (10 power units) Privacy Mobility Scalability Multicast Capable?1 Quantifiable Requirements(Lower values are better) Non-quantifiable Requirements(Higher values are better)Appl. Cost (10 financial units) Delay (ms)
Power consumption (10 power units) Privacy Mobility Scalability Multicast Capable?1 > 1.001< 100.1 3963 142.033 High High High No > 1.001< 100.1 145 27.433 High High High No > 100.001< 10000.1 245 2440.543 High High High No > 0.002 < 0. 2 89 2.896 High High High No > 10.001< 1000.1 165 246.553 High High High No > 1.001< 100.1 145 27.433 High High High No > 0.002< 0.2 1088 32.86 High High High No > 2< 200 3020 112.333 High High High No
12 & 13 > 0.002< 0.2 98 3.166 High High High No acques Bou Abdo 36 > 1.001< 100.1 3963 142.033 High High High No > 0.011< 1.1 214 6.853 High High High NoThe cost range shown in table 2.6 represents the range between local and roaming users. This architecture cannot overcome in-house processing in cost, but has achieved considerable enhancements in delay and power consumption for both applications. The simulation results for "Virtual cloud computing provider" mobile cloud architecture are shown in table 2.7.Table 2.7 Performance evaluation of the mobile cloud architecture "Virtual cloud computing provider" Quantifiable Requirements(Lower values are better) Non-quantifiable Requirements(Higher values are better)Appl. Cost (10 financial units) Delay (ms)
Power consumption (10 power units) Privacy Mobility Scalability Multicast Capable?1 Disqualified Disqualified
12 & 13
Disqualified erformance and Security in Mobile Cloud Computing 37 thoroughly in section 2.3.5. Table 2.8 studies the third architecture "Cloudlet" against various applications.Table 2.8 Performance evaluation of the mobile cloud architecture "cloudlet" Quantifiable Requirements(Lower values are better) Non-quantifiable Requirements(Higher values are better)Appl. Cost (10 financial units) Delay (ms)
Power consumption (10 power units) Privacy Mobility Scalability Multicast Capable?1 Disqualified Disqualified
12 & 13
Disqualified Result Analysis
In this section, we deduce the strengths and weaknesses of each architecture based on the simulation results. We then rank the best performing architectures across requirements and prove that no mobile cloud architecture is suitable for all applications. We start by comparing the architectures. acques Bou Abdo 38
When comparing the delay and power consumption results of these two architectures, we find that: "Virtual cloud computing provider" overcomes "Cloud computing with mobile terminals" in application: 2, 5, 6, 7 and 10."Cloud computing with mobile terminals" overcomes "Virtual cloud computing provider" in application: 1, 8, 9, 14 and 15."Virtual cloud computing provider" fails in satisfying the privacy requirements for application: 3, 4, 11, 12 and 13.common property. "Cloud computing with mobile terminals" does not overcome "Virtual cloud computing provider" in any application with this property. We deduce that "Virtual cloud computing provider" suits applications with "low processing". common property. "Cloud computing with mobile terminals" fail to overcome "Virtual cloud computing provider" in any application with this property. We deduce that "Cloud computing with mobile terminals" suits applications with "high processing"."Virtual cloud computing provider" fails to provide the privacy requirements for applications 3, 4, 11, 12 and 13. In addition to that, this architecture scores lower than "Cloud computing with mobile terminals" on mobility. Both architectures have good scalability but fail to take advantage of multicast traffic.
When comparing the delay results of these two architectures, we find that "Cloud computing with mobile terminals" overcomes "Cloudlet" for all applications except one (App. 5). erformance and Security in Mobile Cloud Computing 39
As for power consumption "Cloudlet" overcomes "Cloud computing with mobile terminals" in applications 2, 5, 6, 7 and 10 which are the applications with "low processing". We deduce that "cloudlet" suits applications with "low processing" and we confirm our previous deduction that "Cloud computing with mobile terminals" suits applications with "high processing".
When comparing the delay results of these two architectures, we find that "Virtual cloud computing provider" overcomes "Cloudlet" for all applications except applications 8 and 9. These two are the only applications having high processing (100,000 processing units) and very small uploaded data (1KB).As for power consumption "Cloudlet" overcomes "Virtual cloud computing provider" in all applications. We deduce that "cloudlet" results in lower power consumption than "Virtual cloud computing provider".
In order to rank the cloud architectures for each application, many grading schemes can be used. We are going to use five different schemes just to show that for different preferences no mobile cloud architectures can be considered optimal. The grading schemes are:The first grading scheme orders architectures based on delay. The architectures are ranked in table 2.9, where smaller rank is better.The second grading scheme orders architectures based on power consumption. The architectures are ranked in table 2.10, where smaller rank is better.The third grading scheme orders architectures based on cost. The architectures are ranked in table 2.11, where smaller rank is better.The fourth grading scheme orders architectures based on privacy and mobility. The architectures are ranked in table 2.12, where smaller rank is better.The fifth grading scheme orders architectures based on scalability. The architectures are ranked in table 2.13, where smaller rank is better. acques Bou Abdo 40
Table 2.9 Ranking cloud architectures using first scheme
Appl. Executing in-house Cloud computing with mobile terminals Virtual cloud computing provider Cloudlet1 - 1 X X - 3 1 2 - 2 1 3 - 2 1 3 - 1 3 2 - 1 X X
12 & 13 - 1 X X - 1 2 3 - 1 2 3"Cloud computing with mobile terminals" becomes more competitive against other architectures in delay as the processing becomes more complex. Oppositely, "Virtual cloud computing provider" becomes more competitive against other architectures in its delay results as the processing becomes lighter. "Cloudlet" architecture offers higher delay for all applications, which is considered a drawback. Table 2.10 Ranking cloud architectures using second scheme Appl. Executing in-house Cloud computing with mobile terminals Virtual cloud computing provider Cloudlet1 - 1 X X - 3 2 1 - 3 2 1 - 3 2 1 - 1 3 2 - 1 X X
12 & 13 - 1 X X - 1 3 2 - 1 3 2 erformance and Security in Mobile Cloud Computing 41 "Cloud computing with mobile terminals" becomes more competitive against other architectures in power consumption as processing becomes more complex. Oppositely, "Cloudlet" becomes more competitive against other architectures in power consumption as the processed data becomes lighter."Virtual cloud computing provider" architecture offers higher power consumption for all applications, which is considered a drawback.Table 2.11 Ranking cloud architectures using third scheme Appl. Executing in-house Cloud computing with mobile terminals (local user)
Cloud computing with mobile terminals (Roaming user)
Virtual cloud computing provider Cloudlet1 - 1 2 X X - 1 4 3 1 - 1 4 3 1 - 1 4 3 1 - 1 4 3 1 - 1 2 X X
12 & 13 - 1 2 X X - 1 4 3 1 - 2 4 1 3"Cloud computing with mobile terminals" achieves best cost performance for local users across all applications except (1, 2 and 15), but worst performance for roaming users across all applications. "Cloudlet" has good performance with applications 5,6,7,8,9,10 and 14 while "Virtual cloud computing provider" performs better with applications 1, 2 and 15.Table 2.12 Ranking cloud architectures using fourth scheme Appl. Executing in-house Cloud computing with mobile terminals Virtual cloud computing provider Cloudlet1 - 1 X X - 1 2 3 - 1 2 3 - 1 2 3 - 1 2 3 acques Bou Abdo 42 - 1 X X
12 & 13 - 1 X X - 1 2 3 - 1 2 3Similarly, it is most private to execute a job in-house, followed by a trusted service provider (Cloud computing with mobile terminals), then a collection of users share the same interest in the processed job (Virtual cloud computing provider) and finally the least privacy offering architecture is "Cloudlet" where data is processed in a server not under the monitoring of a trusted party. Table 2.13 Ranking cloud architectures using fifth scheme Appl. Cloud computing with mobile terminals Virtual cloud computing provider Cloudlet1
12 & 13 erformance and Security in Mobile Cloud Computing 43 throughout this chapter, were focusing on users' needs while neglecting the operator's concerns. "Cloudlet" and "Virtual cloud computing provider", for example, eliminate the use of the mobile operator. "Cloud computing with mobile terminals" significantly increase the traffic leading to higher rejection rates and lower quality for real-time applications, such as voice calls, which are the operator's major profit.The problem in all existing mobile cloud architectures (previously surveyed) is that they discard the financial incentive behind MCC and fail to take advantage of the major traffic type (multicast) generated by computation-intensive mobile applications. We propose, in the coming section, a mobile cloud architecture satisfying both concerns (users' and operators') enforced with a valid business model that encourages the investment of stakeholders (such as: mobile vendors, mobile operators and cloud providers) in this architecture. The decision makers in the technology industry are biased by financial and economic motivations which make their decisions, in many cases, technology unfair. An adopted solution should be technologically and financially feasible and introduces a revenue-making business model. Even a good solution doesn't make it to implementation phase if it discards these motivations, especially if a better solution exists and focuses on promoting economic incentives?The slow progress in deploying IPv6 is a very well-known example on economic effects and market statics that goes even beyond major technology players who are pushing toward this migration. Another example is Fujitsu which has developed a data transfer protocol that overcomes "UDP" and "TCP's" speed by 30 times [74]. Although Fujitsu has achieved impressive breakthrough, they are not expecting it to replace "TCP" or "UDP" because of the absence of a valid business model that persuade the huge investment needed to perform this change (new TCP/IP stacks, APIs, application upgrades, etc.).We have shown in a previous section that the majority of the top ranked mobile applications are multicast-based, and none of the mobile cloud architectures found in literature acques Bou Abdo 44 was designed to take advantage of this mobile traffic characteristic. The weakness in existing architectures is that they tried to meet MCC requirements through network edge solutions (focusing on network edge entities without any modification to the network core) by either trying to eliminate the use of mobile networks (such as "Cloudlet" and "Virtual cloud computing provider") or abstracting it ("Cloud computing with mobile terminals") and in both cases failing to exploit its benefits. At the physical layer of current mobile technology implementations (LTE and UMTS), network layer multicast message is translated into a group of unicast messages (we will call this operation "unicast bundling"). Let BW(n) be the Bandwidth consumed by sending the same data to n hosts, then: )1()(
BWnnBW (2.1)From network edge perspective, the transmitted message might be 100% efficient (i.e. sending a multicast message to n hosts), but from network core perspective and the system as a whole the efficiency is (1/n). The current physical layer implementation in mobile technologies does not suit applications using multicast/broadcast communications. We deduce that abstracting the mobile network as "Cloud computing with mobile terminals" proposed is definitely not a future proof solution. We believe that utilizing multicast is not a feature anymore, but a necessity to overcome the drawbacks generated from "unicast bundling".Network edge solutions are not able to force the core network to forward multicast traffic without utilizing "unicast bundling". In order to solve this problem and make mobile cloud more agreeable and efficient, network core adaptations should be considered.When designing our architecture, we seriously took into consideration users' and operators' concerns since we are completely aware that this architecture can make it to production only if it overcomes its competitors in performance and offers a valid business model that convinces investors and decision makers. We also designed this architecture to handle separately both types of traffic (unicast and multicast) to achieve elevated revenues and optimized utilization of resources. In the coming section we propose our architecture titled erformance and Security in Mobile Cloud Computing 45
OCMCA (Operator-Centric Mobile Cloud Architecture) as a response for the previously discussed concerns and a lesson learnt from previous architectures' mistakes.
The lessons learnt from section 2.3, corresponds to users' concerns, are summarized as follows:
Delay : "Cloud computing with mobile terminals" suits applications requiring complex processing because it is equipped with powerful cloud servers. Oppositely, "Virtual cloud computing provider" suits light applications because processing is executed close to the mobile device. Our architecture uses powerful cloud servers, but these servers should be closer to the mobile device.
Power consumption : Similarly "Cloud computing with mobile terminals" suits applications requiring complex processing and "Virtual cloud computing provider" suits light applications. Our architecture offloads the job into powerful cloud servers thus will be suitable for complex applications. By decreasing delay as shown above, the power consumed by the mobile device waiting for the reply will be decreased.
Cost : Wi-Fi traffic is cheaper than unicast mobile traffic. Our architecture uses multicast traffic when possible to decrease users' costs and increase operator's revenues as shown in the business model (section 2.4.4).
Privacy : Executing a job in a trusted environment has higher privacy level. Our architecture positions the cloud servers in a trusted environment to ensure privacy.
Mobility : The operator's network coverage and handover mechanisms make a connected user (connected to his services through operator's network) benefit from high mobility. Our architecture uses the mobile network to connect between cloud servers and users.
Scalability : Statistical multiplexing proves that unified resources are more scalable, and this is why "Cloudlet" was not. Our architecture uses cloud servers accessible by any connected user (connected to the mobile operator's network) acques Bou Abdo 46 and connected with high bandwidth and low latency link to the operator's core network which makes it scalable. Its scalability can be increased through federation.Figure 2.4 represents a normal EPS network with minimum entities needed for the basic functionalities (Call and Internet Access).Figure 2.4 EPS network (minimum configuration)Our architecture proposes the allocation of a cloud (called "Cloud server" throughout the remaining of this chapter) hosted by the mobile operator (in the mobile operator's premises or in a trusted network as shown in figure 2.5). "Cloud server's" location within the operator networkis responsible for the following features:Close to the mobile core in order to eliminate the "delay" resulting from accessing the internet. The decreased distance can be seen in figure 2.5.Connected to the MME allowing it to differentiate between unicast and "multicast" traffic which facilitates separate handling of these two traffic types.Under the supervision of the mobile operator or a trusted party. The operator is also trusted by the user, since an SLA is already signed, thus the "Cloud server" is considered a "private" environment. erformance and Security in Mobile Cloud Computing 47
The cloud is accessible by all connected users, since a direct connection exists with the core network. This feature is responsible for high user "mobility" and participates in increasing the "scalability" of this architecture.The positioning of the "Cloud server" is graphically presented in figure 2.5.Figure 2.5 Initial phase of OCMCA (without multicast)By positioning the "Cloud server" within the operator's network, we achieved all the features previously mentioned. Although the multicast traffic has been specified, it cannot be forwarded to the users without additional support. 3GPP has standardized multicast and broadcast packet transmission in UMTS and broadcast transmission in LTE through a feature named MBMS (Multimedia Multicast/Broadcast Service) [75][76][77][78] which was defined in 3GPP's technical specification as follows: acques Bou Abdo 48 "MBMS is a point-to-multipoint service in which data is transmitted from a single source entity to multiple recipients" [76].Physical broadcasting allows network resources to be shared when transmitting the same data to multiple recipients [76].Its architecture ensures efficient usage of radio-network and core-network resources, especially in radio interface [76].MBMS requires the introduction of two nodes to the EPS's core (also named EPC: Evolved Packet Core) network [76], which are:
MBMS GW : responsible for the connections with content owners, cloud servers in our case.
BM - SC (Broadcast Multicast Service Centre) : provides a set of functions for MBMS User Services.When the "Cloud server" receives a request it checks if the data should be unicast or multicast. In case of multicast, "Cloud server" notifies MME which in turn requests the P-GW through S-GW to add the participant to a multicast group. When the user is ready to receive the multicast traffic, the "Cloud server" forwards the data to BM-SC which in turn forwards it back to MBMS GW which is responsible for targeting the needed eNBs.If the operator is providing multicast services (such as mobile TV), then MBMS GW and BM-SC are already installed and could be utilized by our architecture without the need for additional investment. Enabling multicast in LTE allows the local cloud, located within the mobile operator's premises, to transmit data efficiently to the users of one or more cells. Unicast based applications will use the normal "user dedicated channels" to send their unicast data to a specific user. The full configuration of our proposed architecture is presented in figure 2.6.Cloud Server has been carefully positioned, in direct connection with P-GW using the standardized "SGi" interface, to require minimum standardization and development effort. Using this interface, makes the development and integration of "Cloud server" much easier ("SGi" libraries are already developed by vendors, no need for intermediate integration entities, etc.) in erformance and Security in Mobile Cloud Computing 49 addition to the possibility to be co-located with the IMS (IP Multimedia Subsystem). In other words, IMS services can be installed as a service in the operator's cloud. This argument is also valid for other services offered by a mobile operator known as VAS (Value Added Services) such as: voice mail, top-up, credit transfer, waiting ringtone, etc.Figure 2.6 OCMCA (full configuration)The added nodes (MBMS GW, BM-SC and Cloud Server) are transparent to normal mobile traffic. Mobile traffic will pass as follows:
Normal Mobile Traffic : eNodeB, Serving GW, PDN GW (Packet Data Network GateWay). It is represented by the blue line in figure 2.7.
Unicast Cloud Traffic : eNodeB, Serving GW, "Cloud Server", Serving GW, eNodeB. It is represented by the green line in figure 2.7.
Multicast Cloud Traffic : eNodeB, Serving GW, "Cloud Server", BM-SC, MBMS GW. It is represented by the red line in figure 2.7. acques Bou Abdo 50
Figure 2.7 Traffic paths in OCMCA
User's Processing Environment
For a user to be able to execute her tasks at the "Cloud server" she has to be subscribed with either the mobile operator's cloud or any other cloud provider. In the first case, the user's environment is created and maintained at the "Cloud Server" so enjoying all the features mentioned in the previous section is possible. In the second case, the user's environment is located at the CSP which the user is subscribed to. The user environment has to be offloaded securely to the "Cloud server" which will be able then to offer its services in CSP's place. Offloading user environment is not possible without a trust relationship and financial motivation for the CSP. The most suitable method to establish monitored and accountable trust relationship erformance and Security in Mobile Cloud Computing 51 between cloud providers is "cloud federation". Federation will be discussed in details in section 4.4. Since users are usually connected with the same operator for long durations, we propose that the user's CSP should federate resources at the mobile operator's "Cloud server" and then offload the user's applications and environment settings. In this case the CSP will be able to offer its clients a faster and cheaper service while the mobile operator will be able to serve not just its clients, but any user subscribed with different cloud providers.Enabling federation in OCMCA will lead to higher penetration rates since mobile operators don't need to enter in competition with mature cloud providers to gain market shares, while on the contrary cloud providers will be interested in creating a partnership with the mobile operator due to mutual profit opportunities. In this case, all computation-intensive processing is implemented within the mobile operator's network and the Terminal generated data are offloaded to the local cloud without the need to access the internet (which decreases the cost per bit of the transmitted data).
In this section, we present the simulation results of OCMCA using the same network configuration, application configuration and architecture requirements presented in section 2.3.3 in order to rank our architecture compared to the ones found in the literature. The simulation code is also developed using C
Quantifiable Requirements (Lower values are better)
Non-quantifiable Requirements (Higher values are better)
Appl. Cost (10 financial units) Delay (ms)
Power consumption (10 power units) Privacy Mobility Scalability Multicast Capable?1 > 0.1001> 1.001 3903 140.203 High High High Yes > 0.1001 85 25.603 High High High Yes acques Bou Abdo 52 < 1.001 > 10.0001< 100.001 183 2409.013 High High High Yes > 0.0002< 0.002 39 1.336 High High High Yes > 1.0001< 10.001 101 242.023 High High High Yes > 0.1001< 1.001 85 25.603 High High High Yes > 0.0002< 0.002 1038 31.306 High High High Yes > 0.2< 2 2950 134.5 High High High Yes
12 & 13 > 0.0002< 0.002 48 1.606 High High High Yes > 0.1001< 1.001 3903 140.203 High High High Yes > 0.0011< 0.011 164 5.293 High High High YesWe compare the performance of OCMCA against the previously presented architectures in table 2.15. Table 2.15 OCMCA's ranking across different requirements Appl. Cost Delay Power consumption Scalability, Mobility and privacy(same as Cloud computing with mobile terminals)1
12 & 13 erformance and Security in Mobile Cloud Computing 53 As can be seen in table 2.15, OCMCA achieves excellent scores in cost, mobility and privacy and good results in delay and power consumption in addition to centralized profits and fair fee distribution among users.
We are going now to calculate the theoretical cost of application 7 using our proposed architecture and the three architectures discussed in section III. "Tour De France" is in its epic, racers are achieving close times and fans are surrounding the tracks of the race. The fans are viewing the race and keeping an eye on the ranking and timing of each racer, using a mobile cloud application. Let the cost of: 1 bit transmitted from a mobile phone to the "Serving GW" be noted as "A". 1 bit transmitted from the "Serving GW" to a mobile phone over a unicast channel be noted as "B".1 bit transmitted from the "Serving GW" to a mobile phone over a multicast much cheaper than unicast.1 bit transmitted from a mobile to another over a Wi-Fi interface be noted as "C".Let the size of the request to get periodically the scores be "rq" bits, and the size of the retrieved data be "rp" bits sent every period T (we will consider the update rate to be once every minute). Let the average number of fans and riders within a Wi-Fi range using application 7 be N. Let the average number of fans and riders within a cell be M. The cost of application 7 over one hour period per user is shown in table 2.16.In "Virtual cloud computing provider" architecture, one user will download the information from internet (downloader) and broadcast it to the remaining users (sharer) using Wi-Fi connection who in turn will resend the data in broadcast. Thus users are noted as "downloader" and "sharer". acques Bou Abdo 54
Table 2.16 Costs of different architectures
Architecture Cost
Our proposed architecture rq × A + 60 × rq × (B/m)Cloud computing with mobile terminals rq × A + 60 × rq × (B)"Sharer" in Virtual cloud computing provider rq × C + 60 × rp × C + N× 60 × rp × C"Downloader" in Virtual cloud computing provider rq × A + 60 × rp × B + 60 × rp × CCloudlet rq × C + 60 × rp × Crq × A is the cost to join a certain event. 60 × rq × (B/m) is the cost of receiving 60 updates in one hour over a multicast channel, considering that the scores are transmitted every minute. 60 × rq × (B) is the cost receiving 60 updates in one hour over a unicast channel. 60 × rp × C is the cost of broadcasting 60 updates to nearby users. N × 60 × rp × C is the cost of receiving broadcast updates from nearby users.We are going now to compare the architectures based on financial cost. Wi-Fi is free (C=0), and multicast traffic is m times cheaper than unicast (where m is fixed by the operator). The cost will be in this case:Our proposed architecture: 60 × (B/m) × rq + rp × A "Cloud computing with mobile terminals" architecture: 60 × B × rq + rp × A"Cloudlet": free"Virtual cloud computing provider" architecture: o "Downloader": 60 × B × rq + rp × A o "Sharer": free o Average cost: (60 × B× rq)/N + rp × Arp × A, rq and 60 are common to all users, so we are going to eliminate the previous parameters to better compare the costs. The simplified costs are shown in table 2.17.Let us consider the number of participants to be 100 (M = N=100) and the cost of multicast traffic be 10 times cheaper (m=10). In this case the user pays for the studied application in OCMCA 10 times less than what he would pay for the same application in other architectures and the operator would receive (M/m) 10 times more profit than normal unicast for the same channel. Network availability is also preserved (since one channel is serving M users) erformance and Security in Mobile Cloud Computing 55 in addition to the extra profits. This new business model creates the financial motivation for mobile operators to invest in mobile cloud computing and promises elevated revenues.Table 2.17 Simplified costs of different architectures
Architecture User cost Operator Revenues per channel CommentsCloud computing with mobile terminals
B B This architecture has good coverage and achieves good profits, but it is not scalable. The number of connected users is limited to "sub-carriers" available at this sector/cell. It also increases the customer rejection rate since the "subcarriers" will be already reserved. Higher customer rejection decreases potential profits and customer satisfaction.
Virtual cloud computing provider
Average: B/NDownloader: BSharer: 0 B Although this architecture achieves low average user cost, but in reality only one user (Downloader) is paying full tariff and the remaining users (sharer) are getting advantage of it. The Downloader's motivation should be studied more for this architecture to implantable.
Cloudlet
OCMCA
B/m M×B/m Usually M > m > 1, this architecture decreases the user cost and increases the operator's profit without affecting potential profits and decreasing customer satisfaction. This win-win situation is definitely interesting for operators.
We have shown in this chapter, that OCMCA achieves excellent scores in the majority of architecture requirements and a superior performance against all competitive architectures. It also achieves a business model that motivates investors due to the very promising revenues and acques Bou Abdo 56 limited investment needed (for instance: only software upgrade is needed to run OCMCA if IMS and MBMS servers are already installed at the operator's premises).Since OCMCA can offer IMS as one of its SaaS services, other operator functionalities can be migrated to this cloud such as billing (also known as Intelligent Network), VAS, etc. This opens a huge door on the different models a mobile operator can be such as:
Outsourced Services : The telecom vendor or any other CSP can offer VASservices to be rented by small operators that aren't able to deploy all the services in their network.
Shallow Operators : An operator can outsource all its core services from a CSP and just maintain its radio network.
Virtual Operator : An operator can outsource all its core services from a CSP and rent its radio network from other operators. This result in zero investment needed to join the mobile market.
No Operator : A mobile network can be developed from HeNBs (Home eNBs) connected over the internet to a cloud-hosted core network which eliminates the need for fixed line operators.The proposed operator models are all possible, but further research is needed to decide which model is capable of surviving till the deployment phase. erformance and Security in Mobile Cloud Computing 57
CHAPTER 3 Security in Mobile cloud3.1. Introduction
As shown in the previous chapter, OCMCA is a very competitive mobile cloud architecture that scores high in both customer and operator side requirements. It is an evolution of mobile technology which overloads its facilities (such as: coverage, bandwidth, trust relationships, SLA, interfaces, etc) to offer more developed services. All architectures using the mobile network, including OCMCA, requires the users interested in their services to be connected first to the operator (either local or roaming users). This dependency in services makes connection establishment a sequential process which is dissatisfying in high latency networks.As these services (mobile communication and mobile cloud computing) stack over each other, the delay between starting the mobile phone and being able to use the mobile cloud services also builds up due to partial delays at each layer. The following authentication scenario happens whenever a user connects to the mobile operator and tries to access any service: 1. A mobile user has to authenticate first with the mobile operator using AKA (Authentication and Key Agreement).2. Establish a secure connection with the service provider (SSL).3. Authenticate with the service provider using any combination of authentication methods: username, password, token, etc. 4. Access the requested services if all the previous steps were successful.This multi-step process creates additional delay and increases attack footprint. Exploiting any of the above steps will compromise the whole procedure and makes the user vulnerable to privacy breaching attacks.Literature contains lots of attacks on EPS AKA and SSL as will be shown in section 3.2.2. The user in this case can be exploited at each layer of this authentication procedure resulting in poor privacy and confidentiality levels. We propose in this chapter an AKA protocol, acques Bou Abdo 58 for mobile and mobile cloud communications, that minimizes delay, ensures the confidentiality of user identity and unifies the above three steps taking advantage of our proposed architecture.Confidential authentication and secure session establishment are just the first step in providing end-to-end security and privacy in mobile cloud computing which is complimented by application security. The two main categories constituting application security are:
Application provided security : security features that are required from the application developer such as: OS security (Operating System), middleware security, application code security, storage encryption, etc. This category is independent from the used architecture, thus considered outside the scope of this work.
Architecture provided security : security features that are offered by the technology/operator/architecture such as: LPPM (location-privacy-preserving-mechanism), interception detection, etc. In this chapter, we are interested in studying this category and especially focusing on LPPM.Although computers’ intelligence and processing power are drastically increasing, search engines are still bounded to factual answers and fail in providing personal opinions which are more valuable [80] and could only be provided by human interaction. Crowdsourcing applications, for example, reply to user's query based on her location and this is where threats lay. Existing mobile cloud architectures does not offer any LPPM to crowdsourcing applications other than the legacy ones which are already proven vulnerable. In this chapter we prove that OCMCA increases the privacy of its applications through upgraded LPPM. We also prove that OCMCA maintains the user's identity privacy while maintaining operator-controlled lawful interception of grain-level mobile cloud data. The ability to reveal the identity of the source of single flow traffic is required to maintain the privacy of non suspect users without hindering law forces from performing its investigations.The rest of this chapter is organized as follows: section 3.2 proposes an authentication, key agreement and SSO protocol, named EC-AKA3, and proves its superior performance and erformance and Security in Mobile Cloud Computing 59 security against currently existing protocols that are used to authenticate the user first with her mobile operator and then with her CSP. Section 3.3 analyzes the privacy in OCMCA through two different scenarios. In section 3.3.1, privacy in crowdsourcing location based services is studied while privacy in crowdcomputing is studied in section 3.3.2.Section 3.4 summarizes this chapter.
Existing mobile networks were designed to offer its users the fastest access to its legacy services without taking into consideration any future service development. EPS AKA has been lightly designed to achieve the least delay even to the extent of compromising its security as will be shown in section3.2.2.2.1. With the evolution in the offered services, the used AKA protocol became insufficient and multiple additional authentication steps became necessary. The following authentication scenario happens every time a user connects to the mobile operator and tries to access any external service:1. A mobile user has to authenticate first with the mobile operator using AKA (Authentication and Key Agreement).2. Establish a secure connection with the service provider (SSL).3. Authenticate with the service provider using any combination of authentication methods: username, password, token, etc. 4. Access the requested services if all the previous steps were successful.Although AKA was designed to offer fast access, the delay resulting from this multiple authentication is high due to its sequential nature. In addition to the elevated delay, the attack footprint also increases due to the usage of different protocols. In this section, we propose the acques Bou Abdo 60 first mobile-cloud-integrated AKA protocol which enables secure and rapid access to mobile cloud services.
SSL/TLS (Secure Sockets Layer/Transport Layer Security) is a protocol responsible for securing TCP/IP communication at the transport layer. It uses asymmetric encryption at the negotiation phase to agree on a key and then uses symmetric encryption for the communicated messages [81]. It is used in almost all secure Internet transactions [82].SSL has been thoroughly evaluated by the research community resulting in various published attacks that are able to exploit it such as:BACPA (Blockwise Adaptive Chosen Plaintext Attack) [83].Chosen Ciphertext Attack [84].BEAST (Browser Exploit Against SSL/TLS) [85][86]CRIME (Compression Ratio Info-leak Made Easy) [85][87].TIME (Timing Info-leak Made Easy) [85].BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) [85][88].LUCKY 13 [85][89].RC4 Biases: Some versions of SSL/TLS use RC4, so all attacks found against the later are considered to also breach the later. Some of the attacks on RC4 are found in [85][90][91].Password Interception[93].We have only surveyed the attacks on SSL as a proof of concept without getting deeper in describing it since cryptographic attacks are outside the scope of this manuscript. erformance and Security in Mobile Cloud Computing 61
In this section we survey 3GPP’s standard authentication and key agreement protocol inaddition to two of the latest proposed enhancements found in literature. The privacy and security level for each protocol is studied in order to prove that none can be considered secure. The studied protocols are:
Many attacks found in literature can exploit EPS-AKA [30][94], but we will only describe the ones which will be used in further discussion throughout the chapter:
IMSI Catcher : Capturing IMSI in plaintext transmitted over Air interface.
Fake BTS : Running an active fake BTS (Base Transceiver Station) attack (breaches the user’s call and data privacy, with having some control over the mobile device).IMSI catcher attack requires minimum resources and knowledge, and has less risk of being detected or traced back. This vulnerability is known since GSM, and it was inherited by EPS from its predecessors (GSM and UMTS). This vulnerability, if exploited, can breach user’s identity and location privacy. Fake BTS attack requires exploiting the transport security (between Home Network’s HSS and Serving Network’s MME), or maliciously using a trusted operator’s infrastructure (private key) [95][96] to gain the UE’s trust.To further confirm that EPS-AKA is insecure, we have verified this protocol using AVISPA (Automated Validation of Internet Security Protocols and Applications) [97], and it shown that a MITM (Man-In-The-Middle) attack is capable of making the adversary gain the user's trust. This gained trust can give the adversary full access on all the user's calls. Our full work showing EPS-AKA's verification can be seen in [98 -101]. IMSI catcher, Fake BTS and MITM attacks are enough to prove that EPS-AKA is easily exploited and offers very low privacy. acques Bou Abdo 62
Since LTE Release 8, UE started to authenticate the network, because active attacks are considered possible. Session Hijacking and other active attacks are treated successfully in 3GPP standards, while Fake BTS is still under debate. Many researchers have studied this problem and proposed protocols to enhance this feature in EPS; one of the latest proposed protocols in literature is PKBP [102].We have proposed an attack against PKBP that could also result in making the UE trust the adversary which gives the later full access on the former's calls. More on the proposed attack can be seen in [98-101].
SE-AKA (Security Enhanced Authentication and Key Agreement) is another trial by the research community to solve the security vulnerabilities in mobile AKA. This protocol proposed the encryption of the user's IMSI using the operator's public key to be sent at the authentication start. We have proposed an attack titled "Intelligent brute force" that was able to decrypt 80% of the user's IMSIs within 2 hours. This attack can be used to exploit SE-AKA which allows IMSI catcher attack to be then implemented. More on the proposed attack can be seen in [98 -101].
We have proposed EC-AKA as a secure and fast AKA protocol that was able to resist all the attacks found in literature at that time. More on this protocol can be seen in [98 -101]. We modeled EC-AKA using "hlpsl" (programming language used by AVISPA) to be verified using AVISPA and it was proved to be secure. The hlpsl model of EC-AKA can be seen in [92]. erformance and Security in Mobile Cloud Computing 63
When EC-AKA was proposed, fake serving network attacks were considered outside of its scope. To propose EC-AKA as a corner stone in the privacy preserving mechanisms used with mobile cloud computing, we were interested in fortifying this protocol against all known AKA breaches and the result was EC-AKA2 [101]. It has also been verified using AVISPA and was shown secure. The message flow of EC-AKA2 is shown in figure 3.1:
Initial Context Setup (KeNB)AS Security Mode Complete(MAC-I)AS Security Mode Command: (Integrity algorithm, Ciphering algorithm, MAC-I)
UE eNB MME HSS
NAS Attach Request:A = {IMSI’, RandomEncKey, RandomIntKey, UESecCapabilities, RandomUESecCapab1, SNID, Integritycheck
TIK } PKH , ID
HSS
Authentication Data Request A, {SNID}
PKH
Authentication Data Response{AV(1,…,n), UESecCap, EK, IntegrityCheck (AUTN(i),RAND(i),KSI
ASME ) TIK , IntegritycheckIIK}
PKM
Authentication Request:{RAND(i),AUTN, KSI
ASME , IntegrityCheck(AUTN(i),RAN(i), KSI
ASME )TIK} EK , (RandomUESecCapab1 + chosen UESecCapabilityUser authentication response: {RES} EK NAS Sec Mode Command: {eKSI, [IMEISV request], [NONCEUE, NONCEMME]NAS-MAC} EK NAS Security Mode Complete: ([IMEISV], NAS-MAC)
Figure 3.1 EC-AKA2 message flow
1. UE • MME: NAS Attach Request: A={IMSI’, RandomEncKey, RandomIntKey, UESecCapabilities, RandomUESecCapab1, SNID, Integritycheck
TIK } PKH , ID
HSS acques Bou Abdo 64
Sending NAS Attach Request: UE generates 3 random keys: RandomEncKey, RandomIntKey, and UESecCapabilities. These 3 keys are concatenated with IMSI’ (the 10 rightmost digits of the IMSI stored in the UICC (Universal Integrated Circuit Card)), and UESecCapabilities. The messages are integrity protected using a pre-shared algorithm, with the key TIK. All of the above data are encrypted using the Home network’s public key stored in UICC, to get A. Thus the NAS Attach Request = {A, IDHSS}. SNID will allow the home HSS to authenticate the serving network based on the user’s preference.
2. MME • HSS: Authentication Data Request: A, {SNID}
PKH
MME checks the IDHSS, and compare to an internal list if this HN (Home Network) HSS has implemented EC-AKA. If the HN hasn’t implemented EC-AKA, then the serving network will handle this request as an AKA request to ensure backward compatibility. If the HN has implemented EC-AKA, while the message is sent in plaintext (using AKA), the request will be dropped since it is considered that all the HN’s users should be compatible with their operator. If the HN has implemented EC-AKA, and the send message is encrypted, then MME extracts IDHSS(HSS identifier) and adds its SNID(Serving network identifier), encrypted using the user’s home network public key, to the received request and forward it to the HSS having ID = IDHSS. When HSS received the message and decrypt it, it will compare the SNID inside A to that added by MME. If both SNIDs confound, then HSS make sure that this is the network selected by the user.
3. HSS • MME: Authentication Data Response {AV(1, …, n), UESecCap, EK, IntegrityCheck(AUTN(i), RAND(i), KSIASME)
TIK , Integrity checkIIK }
PKM
At the HSS, The received Authentication Data request is decrypted. From the IMSI, the private key is fetched. The private key is used with a randomly generated number RAND, to create a group of keys, noted Authentication Vector AV. To optimize performance, HSS creates "n" Authentication vectors, to be used later by MME if needed, instead of requesting new AVs when needed thus increasing delay in operations (such as Handover, etc.). PIK is pre-shared with HSS, then PIK|| RandomIntKey, generates the Integrity key TIK, same as TIK generated on UE side. A is then checked for Integrity, if failed HSS will drop the request and reply with an error erformance and Security in Mobile Cloud Computing 65 code, else generate EK = XOR (PEK, RandomEncKey). PEK is pre-shared, and RandomEncKey is received in A. HSS then performs Integrity check with Key IIK on all the above fields, concatenate the results with the checked data, and encrypt it using the serving network’s public key. The encrypted data are sent back to MME as Authentication Data Response.
4. MME • UE: User authentication request: {RAND(i), AUTN, KSIASME, IntegrityCheck (AUTN(i),RAND(i),KSIASME)TIK } EK , XOR( RandomUESecCapab1, chosen UESecCapability) When Authentication Data Response is received, if the MME can decrypt the message then we can authenticate the network else the AKA process will be terminated automatically. MME then pick AV(1), and select RAND(1), AUTN, and KSIASME, to be checked for Integrity. The resultant of the integrity check is concatenated to RAND(1), AUTN, and KSIASME, to be encrypted using an algorithm from those specified by UESecCap with key EK. The chosen algorithm’s code is added random key RandomUESecCapab1, which is generated in UE. The encrypted data is concatenated with XOR (chosen algorithm’s code, RandomUESecCapab1), are forwarded to UE as User authentication request, a challenge to the UE’s authenticity.
5. UE • MME: User authentication response: {RES} EK After receiving User authentication request: the encryption algorithm is deduced by (chosen algorithm’s code+ RandomUESecCapab1) - RandomUESecCapab1. UE can then decrypt the data, using the correct algorithm and key. From RAND(1), AUTN, and KSIASME, UE can check the serving network’s authenticity. If network authenticity is verified, UE will generate RES. RES will be encrypted using the temporary encryption key and sent to MME.
6. MME • UE: NAS Sec Mode Command : {eKSI, [IMEISV request], [NONCE_UE, NONCEMME]NAS-MAC } EK If the received RES is confounded with expected RES (XRES), then the network can authenticate the UE. Starting this point the communication will be Integrity protected by the keys acques Bou Abdo 66 generated from AKA. The information needed to establish a secure NAS connection with the Integrity checking are encrypted using the same algorithm, and key (EK), and forwarded to UE as NAS Secure Mode Command. The chosen Ciphering algorithm and Integrity algorithm should belong to the UE Security Capability list sent by UE.
7. UE • MME: NAS Security Mode Complete ([IMEISV,] NAS-MAC)
UE accepts the command, and reply with acknowledgment, NAS Security Mode Complete. Starting this point all NAS signaling is Integrity protected and encrypted using the keys generated by AKA.
8. MME • eNB: Initial Context Setup (KeNB) The eNodeB which the UE is connected to, is contacted by MME. MME sends the initial information needed to start Integrity protected and encrypted AS communication. These information (keys, supported algorithms, etc.) are sent in an Initial Context Setup message. MME-eNB connection is considered secure, since data travels using IPSec, thus no extrinsic encryption is needed.
9. eNB • UE : AS Security Mode Command (Integrity algorithm, Ciphering algorithm, MAC-I) eNodeB commands the UE to start encrypting and Integrity protecting using the AS communication using the AS Security Mode Command.
10. UE • eNB : AS Security Mode Complete (MAC-I) From this point all AS communication are encrypted and Integrity protected using the keys generated through AKA. Acknowledgement is sent back to eNB to confirm the protection start. EC-AKA2 has the following enhancements over EC-AKA: erformance and Security in Mobile Cloud Computing 67
EC-AKA2 has added SNID in the NAS Attach Request to become immune to the MITM attack discussed in the serving network authentication leading to UE tracking.EC-AKA2 has adopted a restriction over EC-AKA during handover; if when a new eNB having no access to the old eNB and requesting the UE to send its IMSI, EC-AKA2 forces the UE to re-run an EC-AKA2 instance. This modification in EC-AKA2, will immune the protocol against the threat “User tracking due to linkability of IMSI/TMSI and RNTI”.EC-AKA2 forces the system to change the used TMSI after changing the UE’s state to LTE_ACTIVE, thus abiding to 3GPP’s recommendations.EC-AKA2 has the same QoS performance as EC-AKA, and will be compared across the other surveyed protocols in the next section.
We are going to define in this section, five parameters to evaluate an AKA protocol. The parameters are:
Security/Risk : The protocol’s resiliency and resistance to attacks, and the attack’s probability. It is known that for the same estimated revenue, with the increase in cost and effort to exploit certain vulnerability the probability of attacking decreases.
Cost : Deployment cost (CAPEX) and running/operation cost (OPEX).
Overhead : Additional overhead (added traffic on transmission interface).
Delay : Overall resulting delay. Higher delay will lead to lower call completion rate when used in a heterogeneous network.
Performance : CPU processing directly proportional to battery consumption.We present in Table 3.1, the technical sheet comparing EC-AKA2/EC-AKA, SPAKA, SE-AKA and EPS’s AKA. This table can be read in decreasing order of each parameter i.e. smaller number is better. acques Bou Abdo 68
Table 3.1 Technical sheet of EC-AKA, SE-AKA, and 3GPP’s EPS-AKA
EC-AKA2/ EC-AKA SPAKA SE-AKA Standard AKASecu r ity Cost
Overhead
Delay
Performance
All users connecting to OCMCA are considered mobile, since its user-interface is through a 3GPP network. Mobile devices are increasingly popular, constituting 40% of Internet accessing devices, and cloud-based mobile applications are expected to rise to 9.5$ billion by 2014 [4].Huge traffic is expected to be generated by mobile users who need to perform multiple authentications (Authentication with the mobile network, cloud provider, targeted application,etc.), thus creating serious and unneeded traffic, congestion and delay. Being able to construct a SSO (Single-Sign-On) mechanism, capable of authenticating the user across the mobile network, cloud provider and selected applications will result in remarkable decrease in delay. As shown in section 3.2.2, EC-AKA2 is a secure AKA protocol capable of resisting all the known attacks which exploited the standard EPS-AKA and achieves good QoS performance. In this subsection, erformance and Security in Mobile Cloud Computing 69 we will overload EC-AKA2 with a newly proposed authentication and Single-Sign-On mechanism that authenticates the user with the cloud simultaneously while getting connected to the serving mobile network. This will ensure reduced delay and minimized traffic overhead. The new version is called EC-AKA3 [100] and its message exchange is shown in figure 3.2.
UE Serving Network’s MME Home network’s HSS
NAS Attach Request:A = {IMSI’, RandomEncKey, RandomIntKey, UESecCapabilities, RandomUESecCapab1, SNID, Integritycheck
TIK } PKH , ID
HSS
Authentication Data Request A, {SNID}
PKH
Authentication Data Response{AV(1,…,n), UESecCap, EK, IntegrityCheck (AUTN(i),RAND(i),KSI
ASME ) TIK , IntegritycheckIIK, {User’s Identity Certificate} K7 } PKM
Authentication Request:{RAND(i), AUTN, KSI
ASME , IntegrityCheck(AUTN(i), RAN(i), KSI
ASME )TIK} EK , (RandomUESecCapab1 + chosen UESecCapabilityUser authentication response: {RES, K7, Delta Proxy Certificate} EK GenerateProxyCertificate
Serving Network’s Cloud
Request Authenticated ?Authentication confirmation
Figure 3.2 EC-AKA3 message flowWe can simply describe EC-AKA3 as EC-AKA2 + authentication and SSO for the cloud services. Since we are mainly interested in the security process within the cloud domain, and since the privacy in EC-AKA2 has already been discussed we are going to give a high description of the message exchange shown in figure 3.2. The steps are listed as follows: acques Bou Abdo 70
NAS Attach Request : The UE sends a connection request and her identity to the serving network's MME (Mobility Management Entity). The identification data are confidential and can only be decrypted at the user's home network HSS (Home Subscriber System).
Authentication Data Request : The received confidential data are forwarded to the user's home network HSS in addition to the serving network's ID which is also confidentiality protected.
Authentication Data Response : contains the needed information for the serving network to authenticate the user, the user to authenticate the serving network and the user's identity certificate encrypted using K7. The transmitted data is confidential and can be decrypted only by the serving network's MME. In previous implementations of job delegation using proxy certificates [104], both the Identity certificate and proxy certificate are delivered by the user. Since mobile cloud uses expensive channels, we designed the delivery of the identity certificate from HSS side.
User authentication request : Contains the information needed by the user to authenticate the serving network. If the network is authenticated, the user generates the K7, RES and Delta proxy certificate. Delta proxy certificate will be discussed later.
User authentication response : The serving network's MME authenticate the user using RES. Since the user has already authenticated the serving network and send K7, MME can now decrypt the user identity certificate. It concatenates the identity certificate with the Delta proxy certificate to have complete proxy certificate allowing it to delegate the user's jobs into the cloud network existing within the serving network.After this point, the MME plays the role of IdP (Identity Provider) for SSO. If a user is interested in accessing a certain service that needs authentication, the authentication request will be processed by MME, as shown in messages 6, 7 and 8, leading to a faster response without overloading the expensive air channels. erformance and Security in Mobile Cloud Computing 71
The added extensions in EC-AKA3 are the following:Introduction of a new key K7, which can be generated using a KDF (Key Derivation Function) at both HSS and UE.When the Home HSS identifies the user, it sends the user's identity certificatewith the authentication vector to the Serving MME (3rd message).When the user authenticates the network, she creates a proxy certificate granting the operator the permission to contact the CSP on her term. The certificate is encrypted using K7 and can only be retrieved by the MME since it has received the key (K7) from the home HSS.The operator concatenates the identity certificate and the proxy certificate to be able to start offering its mobile cloud services. As can be seen, the user has access to the mobile cloud services just at the same time with AKA which eliminates the delay resulting from (SSL and an authentication protocol).A proxy certificate is a method to make a job owner capable of authorizing his computation provider to delegate a job, over a predefined time limit, to another computation provider. The proxy certificate is signed by the user herself, but to be trusted, the user's identity certificate signed by a trusted CA (Certification Authority) should also be available. EC-AKA3 is a compact protocol which replaces three standalone mechanisms each fulfilling a separated task: UE's mutual authentication with the serving network, such LTE-AKA. EC-AKA3 has inherited its security level from EC-AKA2 [101] which was proven to have superior security when compared with LTE-AKA.User authentication with the cloud services, such as TLS/SSL and username/password authentication.SSO with cloud services, such as IdP/SP. acques Bou Abdo 72
We are going now to compare the traffic overhead of EC-AKA3 compared to the protocol suite (EPS-AKA, TLS/SSL, username/password authentication, IdP/SP). Propagation delay and Cost (QoS parameters) are directly proportional to the transmitted traffic, thus we will simplify our study by only studying the resulting traffic without affecting the comparison validity of the protocols' performance. We are going to divide the network into three layers so that we can measure the internal traffic resulting from the different processes. The divisions are: Air (between UE and eNB), Core (between MME and PDN-GW/Local Cloud/BM-SC) and Internet (between PDN-GW and Remote Cloud). The simulation environment was developed using Java to simulate the performance of EC-AKA3 and the protocol suite (LTE-AKA, TLS/SSL, username/password authentication, IdP/SP). We haven't studied the Processing delay using our environment because we estimate the precision margin to vary by ± 10%, thus we have studied only the transmitted traffic. The simulation results shown below are precise since they are independent from the kernel's scheduler.Table 3.2 shows the exchanged traffic when the user is at her home network. Figure 3.3represents graphically the traffic overhead generated by EC-AKA3 and protocol suite when the user is in her home network.Table 3.2 Traffic overhead generated by EC-AKA3 and "Protocol Suite" for local user
Air (bits) Core (bits) Internet (bits)EC-AKA3
LTE-AKA
422 768 0
TLS/SSL
User/Pass
16 16 16
IdP/SP
15 15 15
Protocol Suite erformance and Security in Mobile Cloud Computing 73
Figure 3.3 Traffic overhead generated by EC-AKA3 and "Protocol Suite" for local userAs can be seen in table 3.2, EC-AKA3 needs 2982 bits at the "Air Interface" and 4131 bits at the "Core Level" to ensure authentication for both mobile and cloud services for a user connecting to her home network. The protocol suite needs 47101 and 47447 bits respectively to ensure the same authentication services as EC-AKA3. Since our architecture positioned the cloud server within the mobile network, no traffic is needed to cross the internet while 46679 bits are needed by the protocol suite to fulfill the authentication procedures. As can be seen in figure 3.3, EC-AKA3 requires 93.6%, 91.2% and 100% less traffic on the "Air Interface", "Core Level" and "Internet Level" respectively.Table 3.3 Traffic overhead generated by EC-AKA3 and "Protocol Suite" for roaming user
Air (bits) Core (bits) Internet (bits)EC-AKA3
LTE-AKA
422 768 768
TLS/SSL
User/Pass
16 16 16
IdP/SP
15 15 15
Protocol Suite
Protocol Suite EC-AKA3 acques Bou Abdo 74
Figure 3.4 Traffic overhead generated by EC-AKA3 and "Protocol Suite" for roaming userTable 3.3 shows the exchanged traffic when the user is roaming. Figure 3.4 represents graphically the traffic overhead generated by EC-AKA3 and the studied protocol suite when the user is roaming. As can be seen in table 3.9, EC-AKA3 needs 2982 bits at the "Air Interface", 4131 bits at the "Core Level" and 4101 at the "Internet Level" to ensure authentication for both mobile and cloud services for a user connecting to a foreign network. The protocol suite needs 47101, 47447 and 47447 bits respectively to ensure the same authentication services as EC-AKA3. As can be seen in figure 3.4, EC-AKA3 requires 93.6%, 91.2% and 91.35% less traffic on the "Air Interface", "Core Level" and "Internet Level" respectively.
EC-AKA3 Protocol Suite erformance and Security in Mobile Cloud Computing 75
With mobile cloud applications, user information is shifted towards the network more than any time before. Critical information revealing user's identity, location, behavior and preferences are becoming accessible to different parties. The leakage of such critical information and the resulting user privacy breach requires security alerts to be raised. This leakage is due to vulnerabilities in the application that could span across different layers. The two main categories constituting application security are:
Application provided security: security features that are required from the application developer such as: OS security (Operating System), middleware security, application code security, storage encryption etc. This category is independent from the used architecture, thus considered outside the scope of this work.
Architecture provided security: security features that are offered by the technology/operator/architecture such as: location privacy preserving mechanism, interception detection etc. In this chapter, we are interested in studying this category.When designing OCMCA we exerted extra efforts to optimize its performance (lower delay, cost and power consumption in addition to higher scalability, mobility and multicast handling capability), and to provide security mechanisms that help in ensuring user privacy and preventing the leakage of personal information. To better understand the privacy levels offered by our architecture, we will study sample applications (applications 3 and 13 shown in section 2.2.2 that clearly show the effect of architecture provided security) and compare its security against the mobile cloud architecture found in literature. acques Bou Abdo 76
Privacy in Crowdsourcing location based services
Crowdsourcing location based services inherit the querying mechanism from its legacy predecessors and this is where the threat lays. In this section we are going to compare the difference between legacy and crowdsourced location based services and then prove mathematically that the highest privacy mechanism with level “Footprint” does not satisfy the privacy level needed by crowdsourced location based services and then prove that higher privacy level and lower overhead is achieved when these services are implemented in Operator centric mobile cloud architecture.
Location-based service is a computer-level online service that utilizes the user’s current position as a critical input for the application providing this service [105]. Location coordinates can be delivered through GPS equipped mobile devices [106], or through the mobile user’s operator. If a multilateration positioning technique is used in the serving network, then the exact location of the user can be specified. If multilateration is not used, then only the distance to the serving eNB is delivered in addition to the eNB’s coordinates; in other words, the user knows that it belongs to the circumference of a circle centered at serving eNB; its radius is the user’s distance to the center. Note that:Location-dependent query is a user triggered request to a location-based service.Nearest neighbor query is a location-dependent query requesting the address of the nearest point of interest.Before being able to request any information from location-based services, the mobile user has to update his location by sending the coordinates to the LBS server, which in turn replies with the requested information. Security of the location related information transmitted over the air channel is considered outside the scope of this section due to the implemented confidentiality and integrity protection at the AS (Access Stratum) layer. We will only consider erformance and Security in Mobile Cloud Computing 77 last mile eavesdropping (between P-GW (PDN Gateway) and LBS server), carried out by outside attackers or the service providers themselves. Capturing insecure identities and location information allow the attacker to breach the user’s privacy by being able to know if the user is in a certain area, and where precisely is she.Anonymization was proposed using pseudonym identities, as a cost effective way to ensure location privacy. Identity anonymization is implemented at the mobile level, where a pseudonym is generated to replace the username in the LBS query as shown in figure 3.5.Pseudonym anonymization failed to ensure the required degree of anonymity [107][108] because each user has a limited number of restricted areas which are known by the attacker and allow him to create a predetermined victim behavior. These restricted areas are places visited regularly by the victim, such as home, office, home-office road, etc. In other words, the anonymizing technique is vulnerable to correlation attacks. Although the username is anonymized other remaining attributes called quasi-identifiers can still be mapped to individuals e.g.: age, sex, and city [106][109]. Figure 3.5 Anonymization using pseudonymThe scenario behind figure 3.5 is that user A currently found at location 01001 is interested in finding a certain service which is returned by the LBS server as located at 01110.K-anonymity [110] is another proposed method to ensure location privacy, where a location-dependent query is considered private if the attacker is able to identify the requester with probability less than 1/K. K is a threshold required by the user [108]. This method uses an intermediate trusted server called anonymizer as shown in figure 3.6. acques Bou Abdo 78
Figure 3.6 Anonymization using K-anonymityEvery subscribed user has to register with a trusted anonymity server (anonymizer) by updating its identity and location. This anonymizer maintains an updated database of user’s current location. Each triggered NN (Nearest Neighbor) query passes by the anonymizer; it replaces the user’s location by a CR (Cloaking Region) and forwards the request to LBS server. its neighborhood. The attacker knows that one within this vicinity has requested this NN query, but the probability of identifying the right user equals 1/K. The LBS server replies with a list containing the identity of each user from CR with its corresponding POI (Point of Interest). The anonymizer then filters the POI corresponding to the real user and passes it to the requester [107][108]. K-anonymity also has drawbacks [107][108]:The anonymizer is considered a single point of failure and bottleneck, thus the probability of full outage is higher than that in pseudonym anonymization.Malicious users can be physically located near the victim, thus the anonymizer will add these users in its CR. Since the eavesdropper knows the malicious users, it can predict the user’s identity with probability > 1/K.K-anonymity is also vulnerable to correlation attacks.K-anonymity’s security level is directly proportional with the frequency of users’ location update. It is not practical and scalable to request location updates periodically from all users. erformance and Security in Mobile Cloud Computing 79
It is more profitable for idle users not to update their location, since moving from LTE_IDLE to LTE_ACTIVE to send this update message will cause higher battery consumption and excess signaling on core level.Generated Only identity privacy is ensured but not location privacy.It is difficult to support continuous LBS.
Crowdsourcing is delegating tasks, used to be executed by machines or employees, into an external set of people [50][51] as shown in figure 3.7. The crowd is selected based on its expertise (topic, geographic location, age, gender, etc.) relevance to the outsourced task. Applications 12 and 13 are examples of crowdsourcing implementations.Figure 3.7 Crowdsourcing“crowd-sourced location-based service” and many crowdsourcing applications [55][80][111], reply to the user's query based on her location. Chorus [111] and crowdsearcher [80] are two crowdsourcing applications, other than Foursquare [56], which require the user's acques Bou Abdo 80 location to be transmitted with the query in order to ensure an optimized task routing. Figure 3.8 shows a sample query (find a good job with a suitable apartment both accessible through public transportation within my neighborhood) sent to crowdsearcher and the steps followed in the resolution mechanism. The square blocks (steps) represent machine based tasks, while the hexagon blocks (steps) represent crowd-based ones.Figure 3.8 Crowdsourcing location based servicesIt can be shown in figure 3.8 that crowdsearcher requires the user's location as part of the query in order to filter out the crowd not belonging to the area the user is interested in. Crowdsourcing applications differ from legacy location based services in the resolution mechanism since one or more employees recruited from the crowd will participate in answering the query, but the user's interface and query mechanism are slightly changed.
The additional intelligence these applications bring is located at the search engine level which is transparent to the user and requires no modification in “query mechanism”. LBSs erformance and Security in Mobile Cloud Computing 81 implement their privacy techniques in the “query mechanism” which is similar to that in crowdsourcing location based applications. The implemented LPPM (Location Privacy-Preserving Mechanism) can be easily upgraded to ensure better security without affecting the remaining components. We are going to study the privacy level offered by the mobile cloud architectures in collaboration with existing LPPMs, but first we should discuss the privacy requirements of crowdsourcing applications and then survey existing LPPMs. The privacy requirements of crowdsourcing applications are:
Location Privacy : In Crowdsourcing Location based services, Location-Identity relationship is relatively easy to be exposed using correlation attacks [28].
Identity privacy : Exposing a user’s non-repudiated identity can expose her to location tracking by exploiting the well-known EPS/UMTS (Universal Mobile Telecommunication System) tracking vulnerabilities [112][101][98].
Identity-request privacy : LBS requests have no system-wide effect (i.e. wrong information will affect the user’s request only without having side-effects on other users). Identity traceback is not required.
Location-privacy preserving mechanisms are the mechanism used to distort user’s LBS queries inside a secure system before being eavesdropped by an adversary. Many LPPMs have been proposed trying to offer a cost effective, practical, scalable, and secure transfer of LBS queries. Some of the latest proposed mechanisms are presented in the following. The Location Privacy-Preserving Mechanisms found in literature [28] are:
Anonymization and obfuscation : Anonymization is replacing the username part of the LBS query with and pseudonym. Obfuscation is responsible for distorting the LBS query’s second part (location).
Private Information Retrieval (PIR) : Both request and reply are encrypted, leaving the server not be able to identify the sender nor the request. This acques Bou Abdo 82 mechanism is suitable for legacy LBS but impractical in crowdsourcing, since the search engines need to send the crowd a plaintext job.
Feeling-Based approach : Identify a public region and request that her disclosed location must be at least as popular as that space.
Footprints : Is considered the most secure location privacy-preserving mechanism. It is an enhancement of the well-know “K-anonymity Cloaking Region” where the anonymizer contains not only the list of users and their location, but also the list of users who have been at each location during the past period “P”. The anonymizer receives the real request, replaces the user’s location by a CR (Cloaking Region) as shown in figure 3.9, and forwards the request to currently or have been within the past period “P” in the area where the user is sending the request form. The request is considered private if the attacker cannot differentiate the requestor in a group of K users i.e. cannot be sure with a probability greater than (1/K) that a user is or isn’t the requestor.The attacker model in LBS considers that the adversary can be located close to or within the Location based server thus having access to all the received CRs. The system’s privacy level can be evaluated by the adversary’s uncertainty of identifying the requestor.Since “Footprints” offer LBSs the highest privacy level between the existing LPPMs, we will study this mechanism to evaluate its adequateness to Mobile Cloud Computing. erformance and Security in Mobile Cloud Computing 83
Figure 3.9 "Footprints" LPPM in crowdsourcing LBS
Before studying “Footprints” adequateness to Mobile Cloud Computing, we start by surveying attacks on K-anonymity. Several attacks on K-anonymity have been discussed in literature, which are:
Selfish behavior based attack:
The authors of [113] showed the behavior of selfish users in "Anonymization and obfuscation" LPPM and its effect on privacy protection.
Homogeneity attack [114][115] : This attack takes advantage of the fact that "K-anonymity create groups that leak information due to lack of diversity in the sensitive attribute" [114]. acques Bou Abdo 84
Background knowledge attack:
This attack takes advantage of the fact that "K-Anonymity does not protect against attacks based on background knowledge" [114] which are not included in the offered information.The attacks on K-anonymity will be used later to differentiate our contribution and show that our proposed attack has more generalized attacker model.
Let {x , x , ....,x n } be the set of users found in a cloaking region, where "n" is the size of the CR. Let "x" be our investigated user. If CRxeixxxx n ..},...,,{ then "x" is for sure not the requestor. The probability of a user being added to a CR without being the true requestor is: NnrequestorxP requestorxCRxPxxrequestorxCRxP i iii (3.1)"N" is the number of users in the area controlled by the studied anonymizer. The probability of a user being added to a CR while being the true requestor is: requestorxCRxP (3.2)We can deduce that, the probability of a user being added to a CR is:
Ni ii requestorxPrequestorxCRxPCRxP )()./()( (3.3)If all the users have the same frequency of sending requests i.e. xi are equiprobable i.e. NrequestorxP i (3.4)We can deduce that: erformance and Security in Mobile Cloud Computing 85 nNn NCRxP CRxrequestorxPCRxrequestorxP (3.5)Based on the assumption that all users are equiprobable, “Footprints” was considered to satisfy K-anonymity by assigning the cloaking region size into "k". In this section we describe our attack, titled frequency attack, against the privacy defined by K-anonymity which is used in "footprint" LPPM. Until now, we have considered that all users are equiprobable, but in reality they aren't. Consider a LBS which can be used by a user to retrieve the location of the nearest shop (bakery, Chinese restaurant, etc.). While being at my home, I am aware of the most important places which I usually access; I know the bakeries, barbers, supermarkets, etc. within my town so I need no support in locating these places while on the contrary I can help others. When visiting places I am new to, It will be hard for me to find certain targets (metro, supermarket, etc.) especially when facing language problems. My rate of asking for guidance in these new places is much higher than that while being in my known region. Let comfort zone be a set of areas where a certain user is familiar with and needs no support from the studied LBS in finding places. A user's comfort zone includes her hometown, workplace, etc. Outside this comfort zone, the query frequency of this user increases. In this part, the users' frequencies are not equal i.e.
NrequestorxPi i (3.6)Let )( requestorxPP ii (3.7)Then acques Bou Abdo 86 baPCRxPthenNnbandN nNalet N nNPNnPPNn requestorxPrequestorxCRxPCRxP iiNi xxiNi ii )(111 )1(11)1()11( )()./()( (3.8)The adversary can, from a sample of collected CRs, estimate the requesting frequency of each user, taking into assumption that this user is either in his comfort zone or not through-out the duration of CR capturing. Let x ij be a random variable representing the occurrence of user “i” in the j th collected CR (CR j ). nj iji xnX (3.9)We can estimate the population rate (the real rate of the user i) from the sample rate with a confidence interval. elsewherenSXnSX nifnnStXnnStXCRxP nnSXnnSXCRxP ii iii iii ,, 301,1)( 1,1)( (3.10)“t” follows student P i since baPCRxP ii )( (3.11) nPPCRxrequestorxP CRj jx (3.12) erformance and Security in Mobile Cloud Computing 87
Knowing the requestor with a probability different than (greater or less than) “1/n” will result in lower entropy (uncertainty) thus better predictability and this breaches the K-anonymity constraint. In the next section we are going to show the entropy and rate of requestor successful prediction generated in simulation environment.
We simulated in this section, using a specially crafted c
Proportion of the population with high request rates A v e r a g e p r o b a b ili t y o f p r e d i c t i n g t h e r e qu e s t o r s u cc e ss f u ll y acques Bou Abdo 88 It can be shown in figure 3.10 that frequency attack has increased the prediction success by 50% to 80% depending on the distribution of the requestors (percentage of users outside their comfort zone). In figure 3.11, we can see the estimated rate of successful prediction and the rates achieved by the frequency attack for a cloaking region of size 4. The x-axis and y-axis are similar to that in figure 3.10.Figure 3.11 Prediction success rate for CR=4It can be shown in figure 3.11 that frequency attack has increased the prediction success by 30% to 70% depending on the distribution of the requestors (percentage of users outside their comfort zone). In figure 3.12, we can see the entropy (uncertainty) of the studied location privacy-preserving mechanism “Footprint”. The x-axis represents the proportion of the population with high request rates while the y-axis represents mechanism's entropy.It can be shown in figure 3.12 that the entropy (uncertainty of knowing the requestor) is lower when using frequency attack for both CR sizes. It means that the attacker is able to estimate the real requestor with a probability greater than “1/n” which leads to a breach in the “K-anonymity” privacy constraint.
Rate of requestor successful prediction using frequency attackFootprint's estimated rate of successful predictionProportion of the population with high request rates A v e r a g e p r o b a b ili t y o f p r e d i c t i n g t h e r e qu e s t o r s u cc e ss f u ll y erformance and Security in Mobile Cloud Computing 89 Figure 3.12 Entropy for frequency attack (CR=4, CR=5) and equiprobable users
The attacker model for each attack on K-anonymity surveyed in section 3.3.1.1.5 is:
Selfish behavior based attack:
The attacker model expects the occurrence of self-interested users whose presence increase the exploitation rate. If the LPPM system is designed to reject self-interested users, this attack will have no effect.
Homogeneity attack:
The attacker model expects the publishing of non sensitive quasi-identifiers which will be used to identify the groups which leak information. This attack is suitable for exploiting Microdata tables ("tables that contain unaggregated information about individuals" [114]), but not for location based services which doesn't include quasi-identifiers other than the location. Location isn't enough for the adversary to identify groups which can leak information, thus this affect is considered ineffective in LBS scenario.
Background knowledge attack:
The attacker model expects the adversary to know some background knowledge on the victim like: religious affiliation, favorite team, etc. This attack is possible, in LBS scenarios, only when the victim
Proportion of the population with high request rates E n t r o p y acques Bou Abdo 90 is requesting information related to the background knowledge the adversary has which should be different from the neighborhood.Frequency attack requires none of the constraints enforced by others which makes us consider that it has a more generalized attacker model than all the previously proposed attacks. It is also suitable for LBS scenarios. Ensuring a high privacy level for location based services is not trivial in the following environments:
Untrusted service provider:
In most of the cases, the user has no signed contract with the crowdsourced location based server, thus no privacy obligations are held especially when no auditing is taking place.
Hostile network:
Crowdsourced LBSs have no mean to manage incoming traffic's privacy level other that encryption.
Untrusted service provider in hostile network:
Most of the LBSs are untrusted and connected to the internet (hostile network), but enforces encrypted traffic. This environment ensures nearly the same privacy level as that of untrusted service provider in trusted network which is still hard to secure. Figure 3.13 shows untrusted service provider in a hostile network. erformance and Security in Mobile Cloud Computing 91
Figure 3.13 Untrusted service provider in hostile networkThe highest privacy level can be achieved by a trusted service provider within a trusted network without the need for overhead generating LPPMs. Any LPPM generates both processing and traffic overhead, thus eliminating these mechanisms without affecting the privacy level is definitely an achievement. Since crowdsourced LBS users are mobile users too, our proposed solution for this privacy issue is based on OCMCA which is capable of establishing a trusted service provider within a trusted network as shown in figure 3.14. acques Bou Abdo 92
Figure 3.14 Trusted service provider within a trusted networkIf a crowdsourced LBS federates some resources at the "cloud server", then this service can be considered secure since it becomes monitored by a trusted party (mobile operator) and located within a trusted network. The monitoring mechanism enforced by the mobile operator is not discussed in this dissertation, but we consider it does not allow any privacy breaching logs to be transmitted outside the network. In this scenario, an attacker can't collect the LBS queries except using “insider attacks”. Insiders cannot be prevented from accessing user data, but the threatened data found in the HSS and MME are considered much more important than that collected from LBS and is considered outside the scope of this dissertation.Since LPPMs have been proposed to prevent an attacker who captured LBS queries from identifying the requestor or tracing the users, we can consider that LPPMs are not needed anymore in this scenario since attackers are not capable of capturing the transmitted requests unless able to breach the AS(Access Stratum) layer encryption. If an attacker was able to breach AS encryption the threatened data are much more important than that collected from LBS. erformance and Security in Mobile Cloud Computing 93
Studying the monitoring mechanisms enforced by the mobile operator to ensure log privacy is one axis for future work.
Architecture development can be a very complex task if trying to satisfy multiple contradictory requirements. Some of the privacy requirements for mobile cloud architectures supporting crowdcomputing applications are:Maintain identity privacy for participating users.Identify the sender of a certain message if required by authorative parties (like: police or investigators based on court orders in case an anonymized participant is considered a suspect). The identities of the remaining users (not requested in the court order) should be neither declared to nor retrieved by (through attacks found in 3.3.1.1.5)any party other than the mobile operator. These contradictory requirements create a dilemma if not implemented in equilibrium. The mobile cloud architectures found in literature are not equipped to satisfy both requirements and causes one to prevail on other.In this section we use application 3 (presented in section 2.2.2) as an example for crowdsourcing applications to help us evaluate the satisfaction level of the two presented privacy requirements offered by the mobile cloud architectures. We also show that OCMCA can satisfy both requirements and is recommended as a lawful interception interface for mobile cloud traffic.
Application 3 can be used to investigate the track taken by a lost child; where the police needs to construct the event based on the captured images and their timestamps. All the uploaded data are trusted and used to reconstruct an event which considers the uploaded data as facts and acques Bou Abdo 94 the remaining portions of the event are interpolated. We would like to note that the investigation techniques used in the next scenario are basic, but are considered a proof of concept for all applications requiring lawful interception on user generated data such as crowdsensing. Consider the scenario of a lost child where the real event is shown in snapshots at T , T , T , T , and T as shown in figure 3.15.The child in reality is moving from the left crossroad to the right one as shown in the progress of the snapshots. Consider the police have received the snapshots T , T and T as shown in figure 3.16. Figure 3.15 Real scenario erformance and Security in Mobile Cloud Computing 95 Figure 3.16 legitimate snapshots received by the policeIn this case, the police can deduce successfully that the child moved in the right direction thus all their investigation will focus from the right crossroad and beyond. In the case of child kidnapping, the criminals can upload false information (either correct image with false timestamp or modified image) in order to affect the reconstructed events resulting in false investigation. In the same scenario, the criminals have uploaded the images of the child which belongs to T and T but maliciously replaced T by T and T by T resulting in the construction of the event as shown in figure 3.17. acques Bou Abdo 96 Figure 3.17 legitimate and illegitimate snapshots received by the policeThe police will deduce, in this case, that the child moved from left to right and then returned back towards the left crossroad. The police will focus their investigation on the left crossroad and beyond, missing important time necessary for the criminals to move far away from the incident's location. After verifying that the child has continued towards the right (and didn't turn back towards the left crossroad) as shown by CCTV cameras from across the road and its timestamps (T and T ) confounded with the maliciously uploaded images, the police can deduce that the snapshots (T and T ) are related to the criminal or someone trying to hinder the justice by giving (on purpose) false clues. This person should be identified and prosecuted. To identify this person a valid relationship between the uploaded images and the uploader should be verified, thus an identifying technique should be used. The uploaded data can be identified using one of the following identifying techniques:1. Anonymized: uploaded without any identifier. erformance and Security in Mobile Cloud Computing 97 Pseudo-anonymized: identified by a random identity given to the source of the data. This method is usually used in location based services.3.
Identified: the uploaded images are identified using the user's unique and non-repudiated id.In table 3.4 we study the privacy level offered by different combinations of mobile cloud architectures and identifying techniques.Table 3.4 Privacy offered by combinations of mobile cloud architecture and identifying techniques
Mobile cloud architecture Identifying technique Description
Arch. 1: "Cloud computing with mobile terminals" 1 The identities of the users whoparticipated in uploading the images is only known to the Mobile CSP, but the sender-image relationship cannot be retrieved thus the police can't differentiate the criminal from any other participant. Note: filtering techniques can be proposed such as comparing the image resolution to that of the uploader's camera, but the technique can be easily tricked. 23 Uploading the user's non-repudiated identity with the images create the same threat model discussed in LBS where the adversary can detect the presence of the uploader. Although the user's privacy has been breached, some might consider the resulting threat to be minimal; but the real threat is not the detection of the user but linking the user identity to the used IP address which allow the adversary to track the user beyond incident's location. LTE and 3GPP have a well-known vulnerability in tracking IP addresses [101][112] which put the user under a relatively easy unauthorized tracking. Mobile cloud is inheriting LTE's security vulnerabilities but in our case, it is much easily exploited due to the user's cooperation.Arch. 2: "Virtual cloud computing provider" 1 The identities of the users whom have uploaded the images are unknown; moreover the adversary needs significantly less effort to intercept, modify and send the malicious images and their timestamps. We would like to note that other privacy preserving mechanisms such as "Mix zone" can't but increase the uncertainty of identifying the sender.23 It has the same threat as architecture 1 which allows the adversary to trace the user based on identity-IP mapping with significantly less effort. The decrease in exploitation complexity leads to the increase in the resulting risk, thus lower security and privacy level acques Bou Abdo 98 than architecture 1.Arch. 3: "Cloudlet" 1 Ensures the same privacy level offered by architecture 2.23Arch. 4: "OCMCA" 1 Same privacy level as architecture 1.2 Since the mobile CSP is a trusted party (due to the signed SLA), It can play the role of the anonymizer in LBS. The adversary located just before the police server will see pseudo-anonymized images which will grant him no beneficial information. On the contrary, if the police are interested in getting the identity of the sender of a specific image, they can contact the mobile operator who already has the list of uploaders and their used random identity.3 Same privacy level as the previous case (4-2), since the mobile cloud server will anonymize all the uploaded information before being sent. We can deduce from the above discussion that none of the architectures except architecture 4 (OCMCA) is capable of ensuring a satisfying privacy level which protects the users from tracking attacks. We would like to note that the mobile CSP is trusted for anonymizing the identities since she already have the user's id and exact location thus this service will add no extra information. The "cloud server" in OCMCA is the perfect place of the implementation of lawful interception systems, since it neither affects the service's privacy nor keeps the police's intervention unmonitored.
We have proposed, in this chapter, a new protocol called EC-AKA3 formed by extending a highly secure AKA protocol for LTE (EC-AKA2), with authentication and SSO mechanisms using proxy certificates. After comparing EC-AKA3 with the mobile cloud's current implementation, it was shown that our protocol decrease the traffic overhead generated from authentication more than 91%. EC-AKA3 requires a trust relationship to be already established between the mobile operator and CSP which is natively satisfied in OCMCA.We have shown that existing mobile cloud architectures fail to offer any extended privacy preserving mechanism other than those proposed for legacy location based services. We have also proved using a mathematical model and simulation that the privacy level offered to legacy erformance and Security in Mobile Cloud Computing 99 and crowdsourced location based services using “Footprints” could be breached. Since existing mobile cloud architectures are not able to offer its applications a satisfactory privacy level, OCMCA was designed to offer an end-to-end trusted context which leads to the elimination of threatening attacker models. We are currently collecting real data concerning the proportion of the population outside their comfort zone at different areas (universities, football stadiums, downtown, etc.) in order to estimate the real impact of frequency attack on similar services.OCMCA as an LI (Lawful Interception) interface is one of our future research directions in order to present OCMCA as a full scalable product. acques Bou Abdo 100
CHAPTER 4 Cloud Federation4.1. Introduction
We have shown in chapter 2 that cloud federation is a new part in mobile cloud computing especially OCMCA, but this feature has been previously introduced for cloud computing and many researchers consider it as its fate.Cloud computing industry is moving in steady steps towards maturity [116] which holds different economic challenges than what cloud providers used to face. The different criteria and challenges of mature and immature economies are shown in table 4.1.Table 4.1 Immature vs. mature economy criteria
Immature Economy Mature Economy
New players (companies) entering and exiting the industry. Very hard for new players to enter the industry.Competition on market shares. Market shares statically divided.Variable prices. Stable price for all the players providing the same commodity.Players try to decrease their prices as much aspossible in order to increase their market shares and aiming to increase their prices back at a later stage after establishing reputation and customer loyalty relationships which helps in keeping their market share even after price increase. Each player tries to optimize her investment and decrease her expenses in order to ensure profitability at the market's stable price.Oligopoly is a term used in economics to indicate a market governed by a limited number of parties. We can thus identify the current cloud market status as oligopoly. This status is an early stage of a developing ecosystem.For cloud providers to be able to survive this coming shift in the cloud computing industry, their investments should be carefully optimized to ensure profitability at the price fixed by dominant players (such as Microsoft, Google, Salesforce and Amazon). To do so, the research erformance and Security in Mobile Cloud Computing 101 community has proposed various pricing models [117], SLA features [118][119], resource provisioning techniques [120 - 122] and cloud federation techniques [16][123][116][125]intending to help CSPs (especially small and medium ones) optimize their investments.The authors of [16] [116][123][125]forecasted that the development of cloud computing market's ecosystem passes by three stages:Stage 1 “Monolithic”: Islands of cloud services delivered by mega-providers similar to the current oligopoly. Stage 2 “Vertical Supply Chain”: Specific players agree to cooperate statically.Stage 3 “Horizontal Federation”: Providers will dynamically cooperate between themselves to gain: “economy of scale”, efficient use of their assets, enlargement of their capabilities, and becomes more competitive.Cloud federation is an intra-layer inter-cloud interoperability and outsourcing concept that will be used by small and medium cloud providers [116][126][100]; especially those interested in surviving the formation of cloud market's ecosystem. It is resource sharing and task delegation between providers to increase consumer value and transform IT services into a commodity [127]. Federation should be transparent [127] to the user and abide to the customer-cloud SLA (Service Level Agreement). It is usually triggered when the home cloud (job owner) has all its resources saturated. Federation establishment passes by many steps but could be grouped into three main tasks [116][16]:
Discovery : Requesting and receiving offers (price, QoS, etc.) from CSPs interested in federation.
Match-Making : Eliminating all the unqualified offers and then selecting the cheapest in order to optimize the CSP's profit. This technique will select the best offer anywhere in the world and this is where the hazards start. The hazards of this step will be discussed later.
Authentication : Creating a relationship between the federated and federating CSPs. acques Bou Abdo 102
Although many researchers consider that cloud federation is an inevitable coming step, to the best of our knowledge, none has proven mathematically cloud federation's capability to optimize revenues. In this chapter, we are interested in proving that cloud federation is not just a must for OCMCA but it's financially feasible in both cloud and mobile cloud computing. To do so we compare the ROI (Return-On-Investment) in standalone and federated cloud networks and prove that federation increases profit. We also compare the theoretical utilization rates in both networks and finally prove mathematically that cloud resource federation help providers in optimizing their investments. This study neglects bids and incoming federation requests in order to be independent from any pricing scheme.This study and all cloud investment optimizing techniques found in literature [16] [117 -123] assume that network cost and delay between two cloud providers are negligible, thus favorizing the use of federation. Federating a job to a CSP at a far geographical distance adds propagation delay on top of the currently existing latency which has a negative effect on the CSP's sales [128]. None of the match-making agents found in literature uses distance as a criterion to select the best offer. In this chapter, we are interested in enforcing "distance" as an important selection criterion to maintain the feasibility and profitability of cloud federation.A fast and secure federation mechanism that is capable of enforcing our selection criteria is vital for the development of mobile cloud computing and the sustainability of cloud computing. In this paper we study existing federation managers, specifically CCFM (Cross-Cloud Federation Manager) and analyze its strengths and limitations. To overcome its limitations and make cloud federation more competitive in the current business trends, we introduce a new node called “broker” which will play a significant role in the enhanced CCFM mechanisms. The discovery and match-making agents in CCFM will be modified to enforce a new business model which is more interesting for private investors. Finally, our new business model will be discussed and possible versions are stated.The rest of this chapter is organized as follows: In section 4.2 the financial feasibility of cloud federation is proved mathematically as an investment optimization technique for cloud providers in addition to its necessity for OCMCA. Section 4.3 shows that cloud federation erformance and Security in Mobile Cloud Computing 103 requires an intelligent selection algorithm to maintain its efficiency, else leads to financially catastrophic consequences. Section 4.4 proposes a new federation manager titled BBCCFM capable of enforcing the implementation of the previously presented intelligent selection algorithm. Section 4.5 summarizes this chapter.
In this section we present a financial study that evaluates the financial performance of standalone IaaS cloud provider (federation is not enabled) and compare it to a federation enabled CSP (cooperate with other cloud providers also offering IaaS services). The IaaS resources are represented by IaaS VMs (Infrastructure as a Service Virtual Machines) [117], the smallest resource allocation unit. VM can represent computation power, storage capacity, network I/O etc. but a client's request is measured as a multiple of VM (rounded upward). It is an abstract unit which could be replaced by the value best representing the CSP. Practical value announced by Amazon where "EC2 compute unit" is equivalent to a 1.0 - 1.2 GHz 2007 Xeon processor [116]. Each physical server can support a fixed number of VMs then the CSP's installed VMs depend on the running physical servers. Let the studied CSP's current resources be "m" VMs, which will be represented by "m" independent servers in a queuing system. The number of available VMs is directly proportional to the financial amount a CSP has invested. The available VMs in a standalone manner might not be enough to respond to customers' needs, especially if they run demanding applications, leading to customer rejection. This status is called under-investment. Purchasing more servers will cost the CSP and that might affect the tangible assets [129] or increase the liabilities [130] especially if the CSP is an SME (Small or Medium Enterprise). This will lead to the decrease in the server's utilization rate and this status is called over-investment. acques Bou Abdo 104
As the number of available VMs decrease, the CSP will be able neither to offer strict SLAs nor to cope with sudden increase in demand leading to high customer rejection rates. As the number of available VMs increase, stricter SLAs become possible but the servers will be mainly under-utilized. Under-utilizing servers have multiple effects such as: lower revenues for each server, long time to "break even" and investor discouragement especially in a fast developing industry like technology. Break even analysis is used "to find the amount of sales necessary to pay all fixed costs and have zero income" [130]; Applying it to our case, it is to find the number of served jobs needed to cover the investment made on a VM. ROI (Return-On-Investment) is the retrieved amount of money for each unit of investment. It is used to measure the investment's efficiency.
We consider the rate of incoming jobs follows Poisson distribution thus using stochastic processes, we can create a relation between: number of needed VMs, number of customers the provider is interested in serving and probability of rejection. We consider that one job reserves one VM over the duration of this job so the available VMs in the studied CSP form a queuing system of type M/M/m/m [131]. "m" is the number of VMs and M/M define Markov birth process/ Markov death process. This study neglects bids and incoming federation requests in order to be independent from any pricing scheme. From M/M/m/m model we can deduce that: elsewherePP mkifkkk !10 (4.1) !1 kP mk k (4.2) mk kmm kmP !1!1 (4.3) erformance and Security in Mobile Cloud Computing 105 Where: P k Is the probability that "k" jobs are being processed simultaneously in "k" different VMs.Is the rate of incoming jobsIs the rate of job termination
The cloud datacenter planner should dimension the number of needed VMs for a standalone CSP based on the following three constraints:1. Rejection Rate < "threshold accepted by cloud provider"2. Maximizing ROI3. Minimizing Break even timeBoth the Rejection rate and the threshold are between 0 and 1. three studied parameters is shown in equation 4.4. mk km kmraterejection !1!1 (4.4) Let us consider that the provider's revenue is 1 price unit for each job. Let the revenue generated from "m" servers per period be noted as g(m), then g(m) is the probability of having "k" jobs being processed (P k ) multiplied by the revenue of "k" processes (k$) for all values of k. acques Bou Abdo 106 )/(=g(m) m$P+...+2$P+1$P+0$P=g(m) m0k m210 periodunitspricekP k (4.5)Since ROI is the overall retrieved amount of money for each unit of investment, it is considered unit-less. We are going, in this chapter, to use ROI for comparing the amount retrieved in one period with the initial investment which results in (1/period) as a unit. It can be represented as in the equation below: mk kmk kmk kk k kVMoneofpricem kkVMoneofpricem k VMoneofpricem kkPVMoneofpricem mgROI !1!1!1!11 !1)( (4.6) Let the break even time be noted as T E , where it represents the time needed by our system to process a number of jobs enough to collect revenues equal to the investment, without making any profit. T E uses period as a unit of measurement. We can represent T E as shown below: ROITpriceVMkPT
Emk kE (4.7) Maximizing ROI is at the same time minimizing T E then the above constraints can be simplified into:1. Rejection Rate < "threshold accepted by cloud provider" erformance and Security in Mobile Cloud Computing 107
2. Maximizing ROI"Price of one VM" is a constant part of ROI which doesn't affect its maximization, thus will be eliminated just for clarity without any effect on the scores. The theoretical representation of the simplified constraints for a standalone CSP is shown in equation 4.8. mk kmk kmk km km kROI thresholdkmraterejection !1 !1!1!1 (4.8)A federated CSP has no constraints against "rejection rate", since all the extra jobs can be federated. The theoretical representation of the simplified constraints for a federated CSP is shown in equation 4.9. mk kmk k km kROI !1 !1 (4.9) acques Bou Abdo 108 )0()1( 1)1(111)0( 0!1!1)( raterejectionraterejection aaraterejectionraterejection aka mamraterejection mk km (4.10) mk kmmk km ka makamamraterejectionmraterejection thenmraterejectionmraterejectionIf (4.11)The rejection rate is strictly decreasing for every positive value "a" which is always true. We can prove similarly that ROI is strictly decreasing. As "m" increases to satisfy the rejection rate in standalone CSP its ROI decreases. Since federated cloud networks do not need to satisfy the rejection rate constraint (Instead of rejecting new requests, it will be redirected to other providers) the designer can freely choose the value of "m" optimizing the revenues. We can conclude that for any incoming request rate and network size ROI federated standalone . To represent the above results graphically, mkmkmk km kROIMaximizing thresholdocirnkmraterejection !1!1!1!1 (4.12) erformance and Security in Mobile Cloud Computing 109
We are going now to compare the ROI of standalone and federated CSP for different 4.1.Figure 4.1 Federated v.s. Standalone ROIIn figure 4.1, the y-axis represents the logarithmic value resulting from dividing ROI of federated CSP by ROI of the standalone version as shown in the expression below. daloneSFederated
ROIROIy tan log (4.13)The x- astandalone CSP is never better than federated for every possible "rejection rate threshold" and "n*ocir" for this particular value.We have proven in this section that cloud federation is not just a must for OCMCA to achieve higher penetration rates, but helps cloud providers to optimize their investments and increase their profits. This raises our interest in cloud federation as a financially feasible technology that is critical for the progress of both cloud and mobile cloud computing.
Federated / ROI
Standalone ) acques Bou Abdo 110 This study and all cloud investment optimizing techniques found in literature [16] [117-123], assume that network cost and delay between two cloud providers are negligible thus neglect any significant delay resulting from job federation which affects customer satisfaction. Negative customer experience affects future sales and can affect long-term profitability. In the coming section we will show that inter-cloud delay is significant if not controlled.
To the best of our knowledge, all the previous works on cloud federation were looking from a CSP's point of view and tried to optimize the CSP's direct revenues and this is misleading. From simulation results, we deduced that the propagation delay and time zone difference wasn't included in published results, i.e. only considering federation between local CSPs, but this assumption is not very precise and require special monitoring to enforce. Federation is implemented to increase customer satisfaction by decreasing the rejection rate, but the match-making agents found in literature results in just the opposite. Federating a job to a CSP at a far geographical distance adds propagation delay on top of the currently existing latency which has a negative effect on the CSP's sales [128].
The daily traffic of a CSP, if no economic incentives were implemented [116], looks like a peak between two valleys where this peak represents the daytime usage and the valleys represent the traffic at night and/or weekend [128] as shown in figure 4.2.For explanation simplicity, we will call the high traffic period as "peak". Based on our observations, the peak interval boundaries of different CSPs have small variation margin, thus we can deduce that all the CSPs within the same time zone will experience their peaks (high traffic rates) nearly simultaneously. This discussion will start to be critical when cloud networks move into federation. erformance and Security in Mobile Cloud Computing 111
Figure 4.2 Traffic cycles at a CSP
In this subsection, we show sample latency figures between time zones [132]:Table 4.2 Latency between time zones
Location A Location B Time Zone Difference Latency (ms)
Seol Tokyo 0 90Sydney Tokyo 1 150Hong Kong Sydney 2 180Seol New Delhi 3.5 300Tokyo USA (East) 7 330Hong Kong USA (East) 8 230New Delhi USA (East) 11.5 380
Table 4.2 shows sample latency measurements which can give us an overview on the propagation latency if federation is established between distant providers. In the coming section we will study the effect of peaks on resource prices, and start to formulate the macro-economy paradox behind federation.
For a federation relationship to be established, the following couplet should be available: : A M : A M : A M : P M : P M : P M : A M : A M : A M : P M : P M : P M : A M : A M : A M : P M : P M : P M : A M : A M : A M : P M : P M : P M Traffic Representation acques Bou Abdo 112
A "federated" CSP who is interested in offering some of his resources to other CSPs for a certain price.A "federating" CSP is interested in renting some resources from other CSPs. This provider will scan for the cheapest CSP that can satisfy its needs.For federation to be automatic, the federated resources should be priced automatically. In the remaining of this paper the mechanism to price an available cloud resource is called "pricing scheme". Various pricing schemes exist in literature such as: = × ( ) + [120], where "F" is the resource's federation price, "M p " and "M idle " are total capacity and idling capacity of the federated CSP, "F max " is the on-demand price and "F min " is the minimum profitable price [120]. ( ) = × ( ) × × × [122], where " " is the ratio of free resource to offer, "a" is the factor to reflect that the price of VMs offered for federation could be different from the price of VMs for regular users. The real price offered by the federated CSP is (a × Price_VM_Hour). o ( ) = ( ) ( ) × × _ [122]where "VM free " is the number of resources the CSP is interested in offering, "Cp" is the system capacity, "Up" is the system utilization, Nodes is the number of hosts in the system and "VM_Node" is the number of resource units per host. o In [117] a graph has been shown representing the relationship between the revenue and the offered price in the above equation. The offered price will be modified to ensure optimized revenue.Bidding and Spot VMs: the user submits her request and specifies the maximum price she is interested in paying. If the bid is lower than the current price, the job will not be executed and remains in pending state until prices become less than or equal to the bid [120]. Since the demand at peak hours increases, the cloud resource price also increases, thus most of the cheap bids will stay pending and wait for low-traffic hours. erformance and Security in Mobile Cloud Computing 113
As can be seen in all the above pricing schemes, the federated resource price increases as the CSP get busier. This observation abides to the classical "Law of supply" [133], but the consequences of this trivial observation are critical and will be discussed in the next section.
Since all the regional providers will experience their peak simultaneously, each CSP in that region will have limited free resources, so they price it expensively. At any instance when a CSP is experiencing a peak and becomes interested in federation, she will find the best price in far time zones where the CSPs are in their low traffic period thus offering lower prices than local and regional CSPs. We are going next to show a sample case study which proves our discussion.Figure 4.3 shows that the studied CSP is facing 2 states: high traffic (8:45 AM till 3:45 PM) and low traffic (4:00 PM till 8:30 AM). Let us consider that the CSP is experiencing saturation at 12:00 PM and requests federation offers as discussed in “Match-making step”. All the users within the same time zone as the requestor are also experiencing peaks, so their offers are expensive since price and utilization are directly proportional. Let us consider the CSPs 1 time zone away (having their local time as either 11:00 AM or 1:00 PM), they are also experiencing peaks since the high traffic spans between (8:45 AM till 3:45 PM), so these CSPs will also reply with expensive offers. The CSPs replying with cheap offers are at least 4 time zones away so using the current price-based cloud selection mechanism, the cloud will select a CSP at least 4 time zones away. acques Bou Abdo 114
Figure 4.3 One day Traffic at a CSPUsing the data from table 4.2, we can see that the extra propagation delay between 2 locations, 4 time zones away, is greater than or equal to 2×300ms. To evaluate the severity of this delay we shall compare it to CSPs' announcements. "Google reported 20% revenue loss due to a specific experiment that increased the time to display search results by as little as 500 ms. Amazon reported a 1% sales decrease for an additional delay of as little as 100 ms." [128]. With the current data we have, we are not able to decide precisely the sales loss margin but we expect the sales to decrease by at least 10%, but in case of Google the losses will bypass 20%.
In this section, we are going to study the effect of this observation on the resource provisioning policies proposed in [120] and prove that their simulation assumptions were not very precise. In [120], the proposed resource pricing scheme is: = × ( ) + (4.14)Based on the above pricing scheme, the CSPs who are experiencing low traffic rates will price their resources approximately F min to cover their fixed costs. In this case, if a federation : A M : A M : A M : A M : A M : A M : A M : A M : A M : A M : P M : P M : P M : P M : P M : P M : P M : P M : P M : P M One Day traffic erformance and Security in Mobile Cloud Computing 115 request is transmitted, the cheapest received offer will be F min . In [120], the proposed resource provisioning policies are:
NTFI (Non-Federated Totally In-house) : VM spots are terminated to support incoming on-demand VMs if no free resources were found. If no spot VMs are available to be terminated, the job is rejected.
FAOO (Federation-Aware Outsourcing Oriented) : If no free resources were found, the CSP tries federation and select the best offer. If federation was not successful the bids and spot VMs gets terminated.
FAPO (Federation-Aware Profit Oriented) : If no free resources were found, the CSP compares the profit resulting from outsourcing the incoming jobs with that resulting from terminating the bids and selects the highest profit. The proposed decision algorithm is:
If ( K×F s (t') - (n-m+K) ×F s (t) + (n-m) ×F offer < 0){ Federate the traffic }Else{ Replace Spot VMs by on-demand VMs } Where "F offer " is the cheapest offer received from a CSP interested in renting some of its resources, "F s " is the bid or spot VM price, "n" is the incoming on-demand requests, "m" is the number of available VMs and "K" is the number of spot VMs having their accounting period starting at "t".We have implemented the same environment proposed in [120] but using a specially crafted java code since we added CSPs with various phase shifts in their daily trafficrepresenting different time zones. Our simulation results showed that the cheapest offer is always very close to "F min " and received from CSPs at far time zones. The profit comparison of FAPO with and without time zone difference is shown in figure 4.4. acques Bou Abdo 116 Figure 4.4 FAPO performance comparisonIn figure 4.4, old FAPO represents the policy's performance when considering local CSPs only as shown in [120], while new FAPO represents the policy's performance with the participation of CSPs from different time zones. The profit comparison of FAOO with and without time zone difference is shown in figure 4.5.Figure 4.5 FAOO performance comparison N o r m a li z e d p r o f i t r a t i o ( F A P O / N F T I ) Total number of requests
FAPO performance comparison
Old FAPO vs NFTINew FAPO vs NFTI0.960.9811.021.041.061.081.1 N o r m a li z e d p r o f i t r a t i o ( F A OO / N F T I ) Total number of requests
FAOO performance comparison
Old FAOO vs NFTINew FAOO vs NFTI erformance and Security in Mobile Cloud Computing 117
In figure 4.5, old FAOO represents the policy's performance when considering local CSPs only as shown in [120], while new FAOO represents the policy's performance with the participation of CSPs from different time zones.As can be seen in figures 4.4 and 4.5, the inclusion of "time zone difference" parameter directly affects the estimated profits and business model of the CSP so we can consider the previous assumption (only local CSPs) and its results to be not very precise. We would like to note that both simulation scenarios (old and new) does not include the customer satisfaction parameter and consider all the customers (serviced in-house or federated) to have the same satisfaction, although significant delay will be present. Of course this is far from truth, and the real results will be different, but as noted in section 4.3.2, the customer satisfaction vs. customer traffic relationship is not yet publicly published.We have proven in this section that federation is a very promising solution for CSP's investment optimization but requires an intelligent selection algorithm in order to maintain its efficiency. In the next section we will propose a federation manager that enforces the needed selection criteria and introduces a competitive business model.
CCFM (Cross-Cloud Federation Model) proposed in [16][123] is one of the most developed federation architectures. In this section we are interested in evaluating the Discovery and Match-Making agents proposed in CCFM and show their shortcomings. The shortcomings include: delay, overhead, reputation, and absence of a business model. The discovery agent uses P2P algorithm to discover other clouds and request offers from them. We propose a new entity named “broker” which plays an intermediate role between the clouds, and transform the discovery agent to use client-server mode. Although this transformation might not look attractive to many researchers and a step against the trend especially due to the “broker” being a single-point-of-failure, but it will be proven, later in this section, that a cloud-broker model is best acques Bou Abdo 118 suiting federation. It will also be shown that the client-server communication is more robust than P2P in case of federation management.Other than business needs, cooperative calculation is a motive for many organizational clouds to federate [124] (such as NASA, CEA, universities, etc.). Although commercial cloud federation products are available and the need for federation is continuously increasing, its deployment is not popular. This is expected since the business model proposed for federation module including CCFM [16][123] does not motivate investors to take this extra-charge. CCFM's business model will be compared with our proposed one later in this section.
Today we can see that Cloud is moving in steady steps into adapting federation similar to what was expected [16][125]; moreover commercial products enabling federation are now available [134]. We are still missing the motivating business model that will encourage investments in this challenging side of cloud networks.Villegas et al. [127] discussed a broker concept operating between clouds to support intra-layer (SaaS-SaaS, PaaS-PaaS or IaaS-IaaS) federation. The broker concept will be the federation's driving force if a revenue-making business model was successfully created and thiswill be shown is Section V. Kiani et al. [135] proposed the usage of a context-based broker as the sole administrative authority for a Cloud thus each cloud should be attached to one and only one broker. This context-based broker is responsible for clouds within a geographical area. Discovery, selection and authentication are totally inter-broker mechanisms, while cloud providers communicate only with their corresponding broker. This model doesn't support a successful business model since the sole authority domain isn't opened for private investors (else monopoly will be achieved), and it needs a governmental/standardizing authority to take the broker role. Public initiatives usually lag behind private investors. Since our proposed business model accepts competition and private institutions to run the broker role, we believe it is more applicable and needs shorter time to be realized. erformance and Security in Mobile Cloud Computing 119
Inter-Cloud federation can be abstracted in two complex operations. The first operation is selecting a cloud provider (foreign) having its IdP (Identity Provider) trusted by the client's (the cloud experiencing saturation and interested in federation) IdP, then establishing a secure connection after successful authentication. The second operation is transferring the VMs (Virtual Machine) and extending the hypervisor as described in section III. In the above division of operations, Single-Sign-On [136][137][138] will be a late process within the first group. Celesti et al. [16] proposed that CCFM (Cross-Cloud Federation Manager) contains three agents, which are Discovery, Match-Making and Authentication. The procedures within the first complex operation, which we are interested in, were elegantly attached to CCFM's agents. Discovery and Match-Making agents will be studied thoroughly in this paper at sections III and IV. Celesti et al. [123] enhanced the algorithms used in the three agents proposed for CCFM. Nai-Wei et al. [139] redefined the agents in CCFM over four Modules named: “Current Resource Status Module”, “Message Exchange Module”, “Resource Matching Module”, and “Identity Verification Module”. These four agents represents the same mechanisms found in [16] but in more distributed manner. Celesti et al. [140] evaluated the use of distributed identity provider within cloud federation. CCFM's authentication agent has been enhanced but no changes were done to the discovery and match-making agents. Wang et al. [141] discussed the selection process within the Match-Making agent and proposed an enhanced procedure. Since Celesti et al. [16] has proposed to use P2P mechanism for peer discovery in the discovery agent, we are going to evaluate its adequateness in CCFM environment. Li et al [142]listed four different peer discovery mechanisms each exploiting an underlying architecture. Celesti et al. [123] specified that peer discovery should use a centralized file [143] implementing the publish-and-subscribe (pubsub) software design pattern. Reputation is an important criterion to evaluate a cloud for federation. Many reputation techniques were proposed for P2P systems but any technique can belong to one of the following groups. The first group of techniques needs a centralized node to keep track of user reputation, while the second group requires retrieving the reputation rating from other peers on every query. acques Bou Abdo 120
Kamvar el al. [144] proposed a reputation mechanism which needs less computation than others found in the industry and minimizes the impact of malicious peers. Dewan et al. [145] proposed a reputation mechanism using distributed identities. Literature contains a lot about reputation mechanisms in P2P [146][147] but none claims to compete with the security, privacy and responsiveness of reputation in client-server architectures. Gupta et al. [148] proposed the use of a partially distributed approach through a centralized node responsible for reputation named RCA (Reputation Computation Agent). This resulted in superior reputation accuracy and acceptable overhead.
Cloud computing is defined as “a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction”[143].This model has the following essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity and measured services. After defining the system we should describe its architecture.The cloud architecture stack is composed of three main layers [149]: IaaS (Infrastructure as a Service), PaaS (Platform as a Service) and SaaS (Software as a Service) as shown in figure 4.6. Additional service layers are continuously proposed to add supporting features, such as PasS[150] and HuaaS[151].IaaS is the bottom layer in the cloud stack and nearest to the hardware. It enables on-demand provisioning of servers [7]. IaaS offers two services: VRS (Virtual Resource Set) and PRS (Physical Resource Set) [149]. PRS is hardware dependant and creates an abstraction layer to be used by VRS. VRS is hardware independent and used to monitor virtualized applications. One of the most dominant VRS monitor technologies is called hypervisor or VMM (Virtual Machine Monitor) where the virtualized applications are user virtual machines [7]. VIM (Virtual Infrastructure Manager), regardless of its underlying VMM layer, provides the tools for erformance and Security in Mobile Cloud Computing 121 scheduling and managing VMs across multiple physical layers [14]. VRS, PRS, VIM and VMMare shown in figure 4.6.Cloud Manager Layer is still needed to completely define the cloud. It provides cloud-like interfaces and higher-level functionalities for authentication, identity management, contextualization and VM disk image management [16]. The cloud manager layer contains also the federation manager [152] which will be our focus block for the remaining of this paper.CCFM, which is a modularized version of the federation manager, was proposed in [16][123] to perform all the needed operations for federation establishment. The modules building the federation manager (called agents) are Discovery, Match-Making and Authentication agent as shown in figure 4.7.Incremental resource and service demand might cause the VIM to consume all the available resources at the studied cloud provider. A federation request is triggered by VIM, causing the federation manager to take action by establishing a secure federation with the cloud providing the best offer. acques Bou Abdo 122
SaaSPaaSIaaS
PRS (Hardware infrastructure)VMM or HypervisorVirtualInfrastructureManager
Monitoruser OS
APP
Monitoruser OS
APP
VRS
Figure 4.6 Cloud architectureThe federation algorithm is shown below:
If (federation request is received){ Offeres[][] = Discovery(P2P group);best_offer = Match_making(Offeres);Authentication(best_offer);} erformance and Security in Mobile Cloud Computing 123
Virtual Machine MonitorVirtual Infrastructure ManagerCloud Manager
Federation Manager
DiscoveryAgent Match-MakingAgent AuthenticationAgent
Figure 4.7 Cross-Cloud federation managerThis algorithm, at the federation manager, waits for the VIM to trigger a federation request before performing its logic. The logic will trigger its sub-block (Discovery) to check its P2P groups and retrieve offers from available cloud providers. These offers will then be studied at the match-making agent, and the optimal candidate will be chosen. The authentication agent will then create a secure connection to the chosen candidate. The authentication agent is outside the scope of this paper.The discovery agent is responsible for retrieving offers from available cloud providers interested in federation. The Discovery algorithm is as follows:
Offers[] Discovery(P2P group){ Cloud_Provider_Information_and_contactcloud[] = new Cloud_Provider_Information_and_contact [group.length];Cloud_federation_offersOffers[] = new Cloud_federation_offers[group.length];for (int i=0; i Request_offer(cloud[i]);Offers[i] = Receive_offer();}Return Offers;} The cloud provider belongs to a P2P group, where it subscribes to this group by publishing its contacts. The discovery agent will retrieve a list of available cloud providers participating in the same P2P group and store their contact information in an array called “Cloud”. Each cloud belonging to this array will be requested for an offer, and the received offers will be collected in another array called “Offers”. Offers are then returned to be used by the match-making agent. The match-making agent is responsible for selecting the best candidate offer based on the used algorithm as shown below: Offer match-making(Offers[]){ int j=0;for (int i=0; i Sort (qualified_offers, cost, Desc);returnqualified_offers[0];} The match-making algorithm filters out all the offers not satisfying the requirements and lists the remaining in “qualified_offers”. From these qualified offers, the optimal one (based on a certain selection/sorting algorithm) is chosen and considered the federation candidate. In this section we are going to redefine the Discovery and Match-Making agents through a radical redesign of its internal mechanisms without affecting its interfaces with other agents, thus all the work built over Three-Phase Cross-Cloud Federation Model [141][124][135][153][154][155] will still be valid. This work focuses on federation of physical resources, intra-layer federation [127] which can be positioned at the IaaS layer.Let us focus first on the interfaces of the already proposed agents [16][123] in order to maintain compatibility. The discovery agent searches the P2P group which it belongs to and retrieves a table containing a list of online cloud providers. This agent then sends information queries to the cloud providers listed in the retrieved table. The received replies will be consolidated to be used by the match-making agent. The match-making agent will receive the consolidated replies and select the cloud best satisfying its needs (based on certain criteria such as: best QoS, cheapest Storage, etc.). The authentication agent will then start authentication process with the selected cloud through its Identity Provider.For communication simplicity, we are going to name the mechanisms proposed in [16][123] as “previous” and those we are proposing in this paper as “current”. Before acques Bou Abdo 126 redesigning the Discovery agent, we define a new participant called “broker”. A broker is a service reseller, where it contains an updated list of online providers. In the previous discovery mechanism, a cloud interested in federation would join a peer-to-peer group and subscribe itself as present [16]. When subscribing, the cloud is adding its information to a centralized file [123] so that other clouds can discover it. To achieve better coverage, increase the probability to receive federation requests, or to find better offers, a cloud would join more than one group. In this case our broker will be hosting the centralized file used in P2P discovery proposed by [16]. Figure 4.8 represents the broker as an intermediate node between various cloud providers. In the “current” mechanism, the broker contains updated information about each present cloud provider (such as Offered resources, price of resources, etc.). The information is stored in a table and is similar in concept to UDDI (Universal Description, Discovery and Integration) [157]. Figure 4.8 Broker-based CCFM erformance and Security in Mobile Cloud Computing 127 In the previous mechanism, the discovery agent would create a list of tentative providers retrieved from the centralized file. It then sends a request to each of the cloud providers found in the tentative list. For each request, a reply will be received containing the offered resources (the offered computing capabilities, the time based resource availability, the offered QoS, the trusted IdPs, a cloud black-list) [16]. Request and reply formats are found in [123]. The reply message format is also shown below: Since the broker has updated information about each present cloud provider, it can save much effort on the saturated cloud. Instead of retrieving the list to later contact all the listed clouds requesting an offer, the broker can consolidate the information about all the present clouds in one reply. As shown in figure 4.9, using the previous mechanism a cloud has to fetch the P2P file, send a request to each cloud and receive a reply from every cloud, while our mechanism, shown in figure 4.10, requires 1 pair of messages only. erformance and Security in Mobile Cloud Computing 129 Figure 4.9 Discovery messages in CCFMFigure 4.10 Discovery messages in our Broker-based CCFMAfter receiving different offers from the available clouds, these offers are consolidated and forwarded to the match-making agent. The match-making agent selects the best offer based on selection criteria (such as weighted parameters, etc.). The selection should be deterministic acques Bou Abdo 130 for the same input, thus we propose that this selection criteria should be uploaded to the broker by including it in the request. Instead of replying all the offers within one reply, the broker can calculate the best offer based on the uploaded criteria and notify the requester about the optimal offer. The request format will become: The added tag containing the selection criteria is marked in bold font. The previous mechanism didn't include reputation to eliminate clouds providing fake QoS and offers. Without reputation, a hostile cloud can prevent any two clouds within a group from establishing federation successfully. As mentioned earlier, peer-to-peer reputation mechanisms either requires the collection of logs from all other peers or the use of a centralized node named RCA (Reputation Computation Agent), so one of these reputation techniques should be used with the previous CCFM. Client/server reputation mechanisms can achieve important results; where clients rate other clients after a certain connection/transaction and these reputation scores are stored in trusted centralized server (eBay's auction system is a very successful example [144]). Since we already have a trusted centralized node (broker) we will implement our reputation mechanism based on client/server architecture. We will later show the simulation result comparing the erformance and Security in Mobile Cloud Computing 131 previous mechanisms utilizing P2P reputation and the current mechanisms utilizing client/server reputation. Our proposed algorithms in the discovery and match-making agents results in the high-level message representation shown in figure 4.11. Offer_Request(RequestedResources, Selection Criteria)Home Cloud Broker Foreign CloudOffer_Reply(Foreign cloud contact,Contract conditions)Federation establishmentScore Foreign cloud (Reputation) Figure 4.11 Discovery, Match-making and reputation high-level message representationBefore showing simulation results, let us discuss the availability of the above two mechanisms. The Previous mechanism has a centralized file containing an active list of all the available cloud providers. This centralized file is a single-point-of-failure, so it was proposed in [123] to distribute it over different machines. Table 4.3 compares the characteristics of centralized file in the "previous" architecture with the broker in the "current" architecture.Table 4.3 Comparing availability characteristics Application Previous Current Centralized? Yes YesCan be Replicated? Yes YesSingle-point-of-failure? Yes Yes As shown in table 4.3, both mechanisms have the same availability characteristics. We can conclude from this simple comparison, the P2P based discovery agent does not add availability advantage over our proposed mechanism. The “broker” in our proposed mechanism is a single-point, but implementing it within a cloud (PaaS) increases its resistance against availability attacks [156]. acques Bou Abdo 132 We have modified the previous match-making mechanism to adapt the usage of P2P reputation. The first modified version named pervious-RCA uses a centralized P2P reputation mechanism [148], while previous-DSRM (Distributed System for Reputation Management) uses distributed P2P reputation [145]. We have then simulated, using a specifically crafted threaded c -102-100-98-96-94-92-90-88 10 30 50 70 90 200 400 600 800 1000 3000 5000 7000 9000 20000 40000 60000 80000 100000 Current vs Previous-RCA Current vs Previous-DSRM (%) Percentage of traffic comparison:(Current-Previous)*100/Previous(%) Number of CSPs erformance and Security in Mobile Cloud Computing 133 Figure 4.13 Transmission delay comparisonWe plot in figure 4.13 the transmission delay comparison between current and previous-RCA represented by the blue line and between current and previous-DSRM represented by the red line. We can notice that our proposed discovery and match-making mechanism also decreases the transmission delay minimum by 92% when compared to the other previous mechanisms and tends to “-100%” asymptote as the number of clouds in the group increases. We can see that figures 4.12 and 4.13 are very similar since transmission delay is the resultant of the overall traffic. Figure 4.14 shows the processing delay.Figure 4.14 Processing delay of current, previous-RCA and previous-DSRM mechanisms -102-100-98-96-94-92-90-88 10 30 50 70 90 200 400 600 800 1000 3000 5000 7000 9000 20000 40000 60000 80000 100000 Current vs Previous-RCA Transmission Delay Current vs Previous-DSRM Transmission Delay(%) Percentage of Transmission delay comparison:(Current-Previous)*100/Previous(%) Number of CSPs 10 30 50 70 90 200 400 600 800 1000 3000 5000 7000 9000 20000 40000 60000 80000 100000 Current Previous-RCA Previous-DSRM Processing delay (s) n acques Bou Abdo 134 In figure 4.14 we plot the processing delay of each of the three studied mechanisms. The simulation is run over one PC (P8600 @ 2.4GHz, 1 HDD NTFS 5400 rps) during all the experiment duration. The simulation scenario suggests the usage of n equal power (RAM, CPU, etc) cloud managers each representing a cloud provider. These "n" clouds will be decomposed as 1 home cloud and "n-1" foreign clouds. The scenario contains also 1 supporting node which functions as broker in the current mechanisms, P2P discovery file host and RCA in previous-RCA and P2P discovery file host in previous-DSRM. Comparing the above 3 versions of discovery and match-making mechanisms results in the relative values shown in figure 4.14.Figure 4.15 shows the processing delay comparison.Figure 4.15 Processing delay comparisonIn figure 4.15 we plot the processing delay comparison between current and previous-RCA represented by red line and comparison between current and previous-DSRM represented by blue line. Both plots are nearly confounded thus our proposed mechanism needs 96% less processing for any number of clouds within the same P2P group or uses the same broker. Figure 4.16 shows the propagation delay. -100-80-60-40-200 10 30 50 70 90 200 400 600 800 1000 3000 5000 7000 9000 20000 40000 60000 80000 100000 Current vs Previous-RCA Processing Delay Current vs Previous-DSRM Processing Delay(%) Processing delay comparison:(Current-Previous)*100/Previous(%) n erformance and Security in Mobile Cloud Computing 135 Figure 4.16 Propagation delay comparisonIn figure 4.16 we plot the propagation delay comparison between the three studied mechanisms. Previous-RCA and Previous-DSRM have the same number of messages thus we compared the current mechanism to the previous propagation delay. Our proposed mechanism achieves between 80 and 99.9% less propagation delay when compared to the previous mechanism. After discussing technically CCFM, we are going now to propose a broker-based business model for the current CCFM, and compare it to that of the previous CCFM. The previously proposed broker isn't just an intermediate node that facilitates the federation procedures, but can be a standalone profitable business. Since various cloud providers uses the broker to search for the best offers, this broker can uses economy of scale to get even better offers. Consider we have a broker and 5 subscribed clouds. Let us consider that clouds 1 and 2 are experiencing storage saturation and interested in selecting a federation offer. Clouds 1 and 2 request 100TB each, and the best offer for 100TB is 2$/TB. If the broker participates as an active node, it can request an offer of 200TB. The offer in this case will vary, and the broker will play -120-100-80-60-40-200 10 20 30 40 50 60 70 80 90 100 200 300 400 500 600 700 800 900 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 20000 30000 40000 50000 60000 70000 80000 90000 100000 Current vs Previous Propagation Delay(%) Percentage of Propagation delay comparison:(Current-Previous)*100/Previous(%) n acques Bou Abdo 136 the role of a retailer. The offer given to the broker is 1$/TB since he's going to rent 200TB and not 100TB. The broker can now give an offer to its clients with 1.5$/TB which is even better than the offer given to distributed requests. The clients are now more satisfied, and the broker is achieving revenues without owning any computation or storage infrastructure.Profitable broker-based business model will encourage investors to establish privately owned brokers. It will also encourage cloud providers whom already have implemented CCFM to update its mechanisms since minimal modification is required and instantaneous revenues can be achieved. Previous CCFM can't provide less cost when compared to manual agreements, it can only provide automatic connection establishment with new cloud providers. With our business model, we are proposing a new ecosystem and business opportunities which can be exploited to create more revenue. It is also interesting to note that the time-to-entry and start-up expenditures are very minimal for brokers; moreover a broker can be host running its application on the cloud. This zero cost broker establishment with promising revenues will definitely motivate cloud providers and investors in supporting cloud federation.Broker's role can be extended to manage the traffic overload exerted at the cloud providers within the same time zone. The scheduling techniques and financial feasibility are considered future work. In this chapter we have shown that cloud federation is financially feasible to be implemented in cloud computing but most importantly for us in mobile cloud computing and especially OCMCA.We have also shown that current selection mechanisms in the existing federation managers missed to consider distance as a critical deciding factor which results in devastating decrease in customer satisfaction. erformance and Security in Mobile Cloud Computing 137 BBCCFM has been proposed resulting in 80% less delay and 92% less traffic overhead. Finally we discussed a business model for the broker-based CCFM which will be more motivating and interesting for investors. acques Bou Abdo 138 CHAPTER 5 Conclusions Mobile cloud computing is a very promising technology and a strong candidate for the title "Next Generation Network" due to its capabilities, which empowers mobile users with extended mobility, service continuity and superior performance. Mobile cloud experience was intended to offer higher responsiveness and extended battery life with affordable prices; however current implementations and architectures are far from the set aims. With the variety in mobile applications, it is very hard to have one mobile cloud architecture that suits all especially that it should be financially appealing for investors. Several mobile cloud architectures have been proposed but none was able to satisfy the above requirements which resulted in lower customer satisfaction. In addition to that, the absence of a valid business model to motivate investors hindered its deployment on production scale.The variety in resource-intensive mobile applications reaches the core requirements. Some of these variations are:Uses Multicast vs. Unicast trafficVariety in the privacy requirementsThe content is of public interest vs. private interest.The traffic access is largely sporadic vs. continuous usageMany mobile applications are multicast-based in nature, but its access network(mobile network) transforms, at the physical layer, the communication into a group of unicast messages leading to unnecessary congestion, additional delay and more expensive fees. Other access networks fail to offer the mobility, scalability and privacy offered by mobile networks, thus a compromise is needed by a mobile cloud architecture to meet the expectations.Various mobile cloud application result in user privacy breach especially when offloading tasks to untrusted providers. Similar scenarios could not be controlled without direct interference from major vendors or service providers similar to Apple's application verification implemented before admitting any application to apple store. The needed mobile architecture has to respond to privacy and security threats especially those related breaching location and identity. erformance and Security in Mobile Cloud Computing 139 The cloud computing market is much more mature than mobile cloud and the majority of mobile users are already subscribed with CSPs such as Microsoft, Google etc. For the new mobile cloud architecture to achieve high market penetration rates, it should be able to cooperate with existing CSPs through federation. In this case, any user can be served which increases the targeted market and give the opportunity to server roaming users seamlessly. Federation could also be used to increase the scalability of the needed architecture without the need for extra-investment.Our aims in this dissertation were high and the set objectives were very promising especially that this work is developed in a phase where the form of NGNs (Next Generation Networks) is not yet fully recognized. The first objective "Resource optimizing mobile cloud architecture" was studied in chapter 2 where we compared existing mobile cloud architectures, proved that none is capable of satisfying all mobile cloud applications and deduced the need for a new architecture. We proposed OCMCA, a mobile cloud architecture that uses the mobile network as a host for cloud services. It locates a cloud server within the mobile operator's premises to achieve the following:Decreased latency due to the shorter path between the UE and cloud resources.Enhanced privacy due to the trust and monitoring enforced by the operator.Capability to send multicast traffic at the physical layer due to its connection to MBMS servers.Excellent coverage, mobility and scalability due to the usage of the operator's access network.OCMCA achieved excellent scores in the majority of architecture requirements and a superior performance against all competitive architectures. It is also equipped with a business model that motivates investors due to the very promising revenues and limited investment needed.In the second objective "Pre-authentication", we proposed EC-AKA3 to authenticate auser with her operator and CSP simultaneously, and create an end-to-end trust context. The acques Bou Abdo 140 mobile operator acts, due to the usage of proxy certificates, as an authentication proxy that triggers and handles authentication requests on user's behalf. EC-AKA3 was formed by extending a highly secure LTE AKA protocol (EC-AKA2), with authentication and SSO mechanisms using proxy certificates. After comparing EC-AKA3 with mobile cloud's current authentication and session establishment implementation, it was shown that our protocol decrease traffic overhead by 91% (authentication with one CSP). The user is required to undergo, in the current implementation, the same authentication procedures for every CSP she is interested in contacting. On the contrary, EC-AKA3 gives the mobile operator the privilege to handle authentication procedures with all CSPs on user's behalf resulting in much lower traffic overhead if the user is interested in contacting more than one CSP. This contribution helps in offering the following: Faster service access.Lower traffic overhead.No need for multiple usernames and password.The third objective "Post-authentication privacy" was studied in chapter 3 where a new attack was proposed that breaks the current implementation of legacy and crowdsourced location based services. We proved that this attack has the best attacker model compared to all K-anonymity attacks found in literature. We have also developed a new feature for OCMCA to play the role of a LBS server in legacy and crowdsourced location based services. Due to the cloud server's position in OCMCA, this developed feature can enhance the privacy of the offered services. The new position of the LBS server is within a trusted context (mobile operator's trusted network) which eliminates all attacker models used to breach the privacy of LBS requests. This contribution helps in offering the following:Private LBS (preventing identity-query disclosure).Decreasing delay by eliminating the need for anonymization techniques.The fourth objective "Computation/Storage scalability" was studied in chapter 3 where we have used cloud federation as a scalability method to extend cloud's capabilities to handle erformance and Security in Mobile Cloud Computing 141 sporadic and unexpected customer jobs. We have proven that this method is financially feasible (optimizing ROI, Break-even and rejection rate) using a mathematical model. We have also proposed a new cloud federation mechanism (Broker-Based Cross-Cloud Federation Manager) which achieves a revenue-making business model for federation clusters by using economy of scale. It also achieves lower latency (processing and transmission) by 90%. This contribution helps in offering the following:Enhanced scalability.Optimized investment.Higher market penetration rate. acques Bou Abdo 142 Presenting OCMCA as a competitive product ready for large-scale deployment requires the development of its full features. Although the objectives set at the beginning of this dissertation are fully met, future work is still needed to further develop OCMCA's features.This dissertation's set objectives could be simply described as:Efficient mobile cloud architecture: OCMCA was designed, having a cloud server located within the mobile operator's network.Secure mobile cloud architecture at both pre-authentication and post-authentication phases: The cloud server could be used to offer secure SaaS which are developed by 3rd party providers.Scalable mobile cloud architecture: The cloud server could extend its resources through broker-based federation.OCMCA offers small sized mobile operators the capability to compete with large operators in offering a variety of VAS (Value Added Services). These services, which are considered relatively expensive to deploy, can be developed and hosted by VAS service providers and federated only when needed by the mobile operator. Typical VAS service providers are: Mobile vendors (such as Ericsson, Nokia, Huawei etc.)Operator clusters (such as MTN, Orascom etc.) Application service providers (such as Software companies, Service providers etc.) Currently, each operator offers a bundle of services where each of these services has dedicated servers and databases deployed at the operator's premises. With OCMCA, VASservices can be offered as SaaS without the need for application specific servers to be deployed at each operator and this includes all cloud computing benefits such as higher utilization, higher erformance and Security in Mobile Cloud Computing 143 ROI, lower power consumption etc. Since same VAS applications could be developed by different VAS providers, the service selection algorithm should be carefully studied and more work should be done to evaluate the benefit of using dynamic service selection compared to static agreements between the mobile operator and application service providers. Service brokerage should also be studied and compared against p2p dynamic selection.The used trust establishment technique (between the mobile operator and the service provider) is of great importance, especially that it depends on the used service selection algorithm which could includes various metrics such as: reputation, cost etc.In normal federation mechanisms, the federated cloud provider (offering its resources) charges the federating cloud provider who is collecting money from end users. The used charging mechanism is considered easy since the requestor (federating) and the offerer (federated) are distinct entities. In OCMCA, the federated provider (mobile operator) is the one collecting money from end users and has to pay the federating provider. In addition to the fact that the mobile operator is the one requesting federation and offering its resources to be utilized. This makes the application service provider offering only the logical component (OS image+ software) without offering the hardware services which is a key feature in cloud computing. All the available charging mechanisms are unsuitable for our case, which leads to the need for an adequate charging mechanism.Finally, it is important to investigate the efficiency and cost behind using proxy certificates in EC-AKA3 which is responsible for authenticating mobile users first with mobile operator and then with cloud providers. Other methods could be used to ensure this dual authentication such as overloading user's credentials in mobile's AKA. acques Bou Abdo 144 References [1] N. Gonzalez, C. Miers, F. Redígolo, M. Simplício, T. Carvalho, M. Näslund and M. Pourzandi, "A quantitative analysis of current security concerns and solutions for cloud computing", Journal of Cloud Computing, vol.1 no. 1, pp. 1-8. 2012.[2] R. Saleem, "Cloud computing’s effect on enterprises", Master Thesis 2011, Lund University. 2011.[3] "An SME perspective on Cloud Computing Survey", European Network and Information Security Agency, Survey. 2009.[4] F. Niroshinie, S. W. Loke and W. Rahayu, "Mobile cloud computing: A survey", Future Generation Computer Systems, vol. 29 no. 1, pp. 84-106. 2013.[5] P. Tugnawat and M.E. Fayad, "Advanced Peer to Peer Discovery and Interaction Framework", 18 th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications.[6] R. Buyya, C. S. Yeo, S. Venugopal, J. Broberg and I. Brandic, "Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering computing as the 5 th utility", Future Generation Computer Systems, vol. 25 no. 6, pp. 599-616. 2009.[7] R. Buyya, J. Broberg and A. M. Goscinski (Eds.), "Cloud computing: Principles and paradigms", vol. 87, John Wiley & Sons, 2010. erformance and Security in Mobile Cloud Computing 145 [8] L. M. Vaquero, L. Rodero Merino, J. Caceres and M. Lindner, "A break in the clouds: Towards a cloud definition", ACM SIGCOMM Computer Communications Review, vol. 39 no. 1, pp. 50-55. 2008.[9] "Clearing the Air on Cloud Computing", McKinsey & Co., Technical Report, 2009.[10] M. Michael, "Cloud computing: Web-based applications that change the way you work and collaborate online", Que publishing, 2008.[11] A. Lenk, M. Klems, J. Nimis, S. Tai and T. Sandholm, "What's inside the Cloud? An architectural map of the Cloud landscape", ICSE Workshop on Software Engineering Challenges of Cloud Computing, pp. 23-31. 2009.[12] W. Itani, A. Kayssi and A. Chehab, "Privacy as a service: Privacy-aware data storage and processing in cloud computing architectures", 8 th IEEE International Conference on Dependable, Autonomic and Secure Computing (DASC'09), pp. 711-716. 2009.[13] P. Mell and T. Grance, "The NIST Definition of Cloud Computing", National Institute of Standards and Technology, Special Publication 800-145.2011.[14] B. Sotomayor, R. Montero, I. Llorente and I. Foster,"Virtual infrastructure management in private and hybrid clouds", Internet Computing, vol. 13 no. 5, pp. 14-22. 2009.[15] R. Moreno-Vozmediano, R. S. Montero and I. M. Llorente, "IaaS Cloud Architecture: From Virtualized Datacenters to Federated Cloud Infrastructures", IEEE Computer Magazine, pp. 65-72, Dec. 2012.[16] A. Celesti, F. Tusa, M. Villari and A. Puliafito, "Three-phase cross-cloud federation model: The cloud SSO authentication", 2 nd International Conference on Advances in Future Internet (AFIN), pp. 94-101. 2010. acques Bou Abdo 146 [17] G. Huerta-Canepa and D. Lee, "A virtual cloud computing provider for mobile devices", 1 st ACM Workshop on Mobile Cloud Computing & Services: Social Networks and Beyond. 2010.[18] 3 rd Generation Partnership Project, 3GPP TS 22.278 V8.4.0 (2007-12), Service requirements for the Evolved Packet System (EPS) (Release 8).[19] "Long Term Evolution (LTE): an introduction", Ericsson, white paper, Oct. 2007.[20] 3 rd Generation Partnership Project, 3GPP TS 23.002 V8.7.0 (2010-12), Network architecture (Release 8).[21] "LTE Evolved Packet System Architecture", Alcatel Lucent.2011.[22] 3 rd Generation Partnership Project, 3GPP TS 24.301 V11.1.0 (2011-12), Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS) Stage 3 (Release 11).[23] 3 rd Generation Partnership Project, 3GPP TS 33.106 V11.1.1 (2011-11), 3G security; Lawful interception requirements (Release 11).[24] 3 rd Generation Partnership Project, 3GPP TS 33.107 V11.1.0 (2012-03), 3G security; Lawful interception architecture and functions (Release 11).[25] 3 rd Generation Partnership Project, 3GPP TS 33.108 V11.2.0 (2012-03), Handover interface for Lawful Interception (LI) (Release 11).[26] 3 rd Generation Partnership Project, 3GPP TS 23.203 V8.14.0 (2012-06), Policy and charging control architecture (Release 8).[27] 3 rd Generation Partnership Project, 3GPP TS 23.228 V8.12.0 (2010-03), IP Multimedia Subsystem (IMS) Stage 2 (Release 8). erformance and Security in Mobile Cloud Computing 147 [28] J. Bou Abdo, H. Chaouchi and J. Demerjian, "Security in Emerging 4G Networks", Next-Generation Wireless Technologies, Springer London, pp. 243-272.[29] 3 rd Generation Partnership Project, 3GPP TS 33.102 V11.2.0 (2012-03), 3G Security, security architecture (Release 11).[30] D. Forsberg, G. Horn, W. Moeller and V. Niemi, "LTE security", Wiley.[31] Making the Most of Google Cloud Messaging, Link: http://developer.android.com/training/cloudsync/gcm.html (Access Date: 01- July -2014).[32] B. G. Chun, S. Ihm, P. Maniatis, M. Naik and A. Patti, "Clonecloud: elastic execution between mobile device and cloud", 6 th conference on Computer systems, pp. 301-313. ACM. 2011.[33] M. Satyanarayanan, P. Bahl, R. Caceres and N. Davies, "The case for VM-based cloudlets in mobile computing", IEEE Pervasive Computing, vol. 8 no. 4, 2009.[34] B. G. Chun, S. Ihm, P. Maniatis and M. Naik, "Clonecloud: boosting mobile device applications through cloud clone execution", arXiv preprint arXiv:1009.3088. 2011.[35] R. Kemp, N. Palmer, T. Kielmann and H. Bal, "Cuckoo: a computation offloading framework for smartphones", Mobile Computing, Applications, and Services, Springer Berlin Heidelberg, pp.59-79. 2012.[36] M. N. El-Derini, H. H. Aly, A. E. H. G. El-Barbary and L. A. El-Sayed, "DroidCloudlet: Towards cloudlet-based computing using mobile devices", 5 th International Conference on Information and Communication Systems (ICICS), pp. 1-6. IEEE. 2014. acques Bou Abdo 148 [37] T. Verbelen, P. Simoens, F. De Turck and B. Dhoedt, "Cloudlets: Bringing the cloud to the mobile user",3 rd ACM workshop on Mobile cloud computing and services, pp.29-36.2012.[38] J. Flinn, S. Park and M. Satyanarayanan, "Balancing performance, energy, and quality in pervasive computing", 22 nd International Conference on Distributed Computing Systems, pp. 217–226. IEEE. 2002.[39] R. Balan, M. Satyanarayanan, S. Park and T. Okoshi, "Tactics-based remote execution for mobile computing", 1 st International Conference on Mobile Systems, Applications and Services, pp. 273–286.ACM. 2003.[40] E.E. Marinelli, "Hyrax: cloud computing on mobile devices using MapReduce", Master Thesis, Carnegie Mellon University, 2009.[41] D.C. Doolan, S. Tabirca and L.T. Yang, "Mmpi a message passing interface for the mobile environment", 6 th International Conference on Advances in Mobile Computing and Multimedia( MoMM’08), pp. 317–321. ACM. 2008.[42] D. Huang, X. Zhang, M. Kang and J. Luo, "Mobicloud: building secure cloud framework for mobile computing and communication", 5 th IEEE International Symposium on Service Oriented System Engineering (SOSE), pp. 27–34. 2010.[43] E. Cuervo, A. Balasubramanian, D. K. Cho, A. Wolman, S. Saroiu, R. Chandra and P. Bahl, "MAUI: making smartphones last longer with code offload", 8th international conference on Mobile systems, applications, and services, pp.49-62. ACM. 2010.[44] Global mobile statistics 2014, Link: http://mobithinking.com/mobile-marketing-tools/latest-mobile-stats (Access Date: 01- July - 2014).[45] J. Cheng, R.K. Balan and M. Satyanarayanan, "Exploiting rich mobile environments", Technical Report, 2005. erformance and Security in Mobile Cloud Computing 149 th acques Bou Abdo 150 [57] T. Höllerer and S. Feiner, "Mobile augmented reality", Telegeoinformatics: Location Based Computing and Services. Taylor and Francis Books Ltd., London, UK (2004).[58] B. S. P. Lin, W. H. Tsai, C. C. Wu, P. H. Hsu, J. Y. Huang and T. H. Liu, "The Design of Cloud Based 4G/LTE for Mobile Augmented Reality with Smart Mobile Devices", 2013IEEE 7 th th ACM international conference on Multimedia. 2011.[62] S. Wang and S. Dey, "Modeling and characterizing user experience in a cloud server based mobile gaming approach", IEEE Global Telecommunications Conference (GLOBECOM 2009), pp. 1-7. 2009.[63] S. Wang and S. Dey, "Rendering adaptation to address communication and computation constraints in cloud mobile gaming", IEEE Global Telecommunications Conference (GLOBECOM 2010), pp. 1-6. 2010.[64] A. Kukulska-Hulme and J. Traxler (Eds.), "Mobile learning: A handbook for educators and trainers", Psychology Press, 2005. erformance and Security in Mobile Cloud Computing 151 [65] M. Sharples, J. Taylor and G. Vavoula, "Towards a theory of mobile learning", mLearn 2005, vol. 1 no. 1, pp. 1-9. 2005.[66] L. F. Motiwalla, "Mobile learning: A framework and evaluation", Computers & Education, vol. 49 no. 3, pp. 581-596. 2007.[67] J. Traxler, "Defining, Discussing and Evaluating Mobile Learning: The moving finger writes and having writ....", The International Review of Research in Open and Distance Learning, vol. 8 no. 2.[68] D. B. Hoang and L. Chen, "Mobile cloud for assistive healthcare (MoCAsH)", 2010 IEEE Asia-Pacific Services Computing Conference (APSCC), pp. 325-332. IEEE. 2010.[69] C. Doukas, T. Pliakas and I. Maglogiannis, "Mobile healthcare information management utilizing Cloud Computing and Android OS", 2010 Annual International Conference of the IEEE Engineering in Medicine and Biology Society (EMBC), pp. 1037-1040.2010.[70] S. Mohan, R. Kapoor and B. Mohanty, "Latency in HSPA Data Networks", Qualcomm, white paper, 2011.[71] "LTE real world Performance Study: Broadband and Voice over LTE (VoLTE) Quality Analysis: TeliaDonera, Turku, Finland", Epitrio Ltd., White paper, 2011.[72] J. Huang, F. Qian, A. Gerber, Z. Mao, S. Sen and O. Spatscheck, "A close examination of performance and power characteristics of 4G LTE networks", 10 th international conference on Mobile systems, applications, and services, pp. 225-238. ACM. 2012.[73] K. Kumar and Y. H. Lu, "Cloud computing for mobile users: Can offloading computation save energy?" Computer vol. 43 no. 4, pp. 51-56. 2010. acques Bou Abdo 152 rd Generation Partnership Project, 3GPP TS 25.324 V11.0.0 (2012-09), Broadcast/Multicast Control (BMC) (Release 11).[76] 3 rd Generation Partnership Project, 3GPP TS 23.246 V11.1.0 (2012-03), Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description (Release 11).[77] 3 rd Generation Partnership Project, 3GPP TS 25.346 V11.0.0 (2012-09), Introduction of the Multimedia Broadcast/Multicast Service (MBMS) in the Radio Access Network (RAN) (Release 11).[78] 3 rd Generation Partnership Project, 3GPP TS 25.925, Radio Interface for Broadcast/Multicast Services.[79] 3 rd Generation Partnership Project, 3GPP TS 36.401 V8.0.0 (2007-12), 3GPP System Architecture Evolution (SAE); Security architecture (Release 8).[80] A. Bozzon, M. Brambilla and S. Ceri, "Answering Search Queries with CrowdSearcher", 21 st international conference on World Wide Web, pp. 1009-1018. 2012.[81] R. Oppliger, "SSL and TLS Theory and Practice", Artech House, 2009.[82] A. Freier, P. Karlton and P. Kocher, "Secure Sockets Layer (SSL) Protocol", Dynamic C Module.[83] G. V. Bard,"A Challenging but Feasible Blockwise-Adaptive Chosen-Plaintext Attack on SSL." SECRYPT 2006, pp. 99-109. 2006. erformance and Security in Mobile Cloud Computing 153 [84] D. Bleichenbacher, "Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS acques Bou Abdo 154 [93] B. Canvel, A. Hiltgen, S. Vaudeny and M. Vaugnoux, "Password Interception in a SSL/TLS Channel", Advances in Cryptology-Crypto 2003, pp. 583-599. Springer Berlin Heidelberg. 2003.[94] 3 rd Generation Partnership Project, 3GPP TS 33.401 V11.2.0 (2011-12), 3GPP System Architecture Evolution (SAE); Security architecture (Release 11).[95] G. Sawma and J. Demerjian, "A Distributed Trust and Reputation Model for Capacity Enhancement in Wireless Networks", 1 st rd Symposium on Broadband Networks and Fast Internet, pp. 73-33. IEEE. 2012.[99] J. Bou Abdo, H. Chaouchi and J. Demerjian, "Security v/s QoS for LTE Authentication and Key Agreement protocol", International Journal of Network Security & Its Applications special issue on: "Communications Security & Information Assurance", vol. 4 no. 5, pp. 71-82. 2012.[100] J. Bou Abdo, J. Demerjian, K. Ahmad, H. Chaouchi and G. Pujolle, "EPS mutual authentication and Crypt-analyzing SPAKA", International Conference on Computing, Management and Telecommunications (ComManTel 2013), pp. 303-308. IEEE. 2013. erformance and Security in Mobile Cloud Computing 155 [101] J. Bou Abdo, J. Demerjian, H. Chaouchi and G. Pujolle, "EC-AKA2 a revolutionary AKA protocol", The International Conference on Computer Applications Technology (ICCAT 2013), pp. 1-6. IEEE. 2013.[102] H. Dake, W. Jianbo and Z. Yu, "User authentication scheme based on self certified public-key for next generation wireless network", IEEE International Symposium on Biometrics and Security Technologies (ISBAST 2008), pp.976-980. 2008.[103] J. Bou Abdo, J. Demerjian, H. Chaouchi, K. Barbar and G. Pujolle, "Single-Sign-on in Operator Centric Mobile Cloud Architecture", 17 th IEEE Mediterranean Electrotechnical Conference (Melecon 2014), pp. 151-151. 2014.[104] J. Chen and Z. Huang, "Certificate-based proxy signature", 2010 IEEE International Conference on Informatics and Computing (PIC)". 2010.[105] T. A. Yahiya and H. Chaouchi, "On the integration of LTE and mobile WiMAX networks", 19 th International conference on computer communications and networks (ICCCN 2010), pp. 1–5. IEEE. 2010.[106] M. E. Nergiz, M. Atzori and Y. Saygin, "Towards trajectory anonymization: a generalization-based approach", SIGSPATIAL ACM GIS 2008 international workshop on security and privacy in GIS and LBS, pp. 52–61. ACM. 2008.[107] S. Steiniger, M. Neun and A. Edwardes, "Foundations of location based services", Lecture Notes on LBS, vol. 1. 2006.[108] D. Quercia, N. Lathia, F. Calabrese, G. Di Lorenzo and J. Crowcroft, "Recommending social events from mobile phone location data", IEEE 10 th international conference on data mining (ICDM), pp. 971–976. 2010. acques Bou Abdo 156 [109] G. Ghinita, P. Kalnis, A. Khoshgozaran, C. Shahabi and K. L. Tan, "Private queries in location based services: anonymizers are not necessary", 2008 ACM SIGMOD international conference on management, pp. 121–132. 2008.[110] L. Sweeney, "k-Anonymity: a model for protecting privacy", International Journal of Uncertainty, Fuzziness and Knowledge-Based Systems, vol. 10 no. 05, pp. 557–570.2002.[111] W. S. Lasecki, R. Wesley, J. Nichols, A. Kulkarni, J. F. Allen and J. P. Bigham, "Chorus: A Crowd-Powered Conversational Assistant", 26 th annual ACM symposium on User interface software and technology, pp. 151-162. 2013.[112] 3 rd Generation Partnership Project, 3GPP TR 33.821 V9.0.0 (2009-06), Rationale and track of security decisions in Long Term Evolved (LTE) RAN / 3GPP System Architecture Evolution (SAE) (Release 9).[113] X. Liu, K. Liu, L. Guo, X. Li and Y. Fang, "A Game-Theoretic Approach for Achieving k-Anonymity in Location Based Services", IEEE INFOCOM 2013, pp. 2985-2993. 2013.[114] A. Machanavajjhala, D. Kifer, J. Gehrkeand M. Venkitasubramaniam, "l-Diversity: Privacy Beyond k-Anonymity", ACM Transactions on Knowledge Discovery from Data (TKDD), vol. 1 no. 1. 2007.[115] A. Ohrn and L. Ohno-Machado, "Using boolean reasoning to anonymize databases", Artificial intelligence in medicine, vol. 15 no. 3, pp. 235-254.[116] J. Bou Abdo, J. Demerjian, H. Chaouchi, K. Barbar and G. Pujolle, "Broker-Based Cross-cloud federation manager", 8 th International Conference for Internet Technology and Secured Transactions (ICITST-2013), pp. 244-251. IEEE. 2013.[117] I. Goiri, J. Guitart and J. Torres, "Economic model of a Cloud provider operating in a federated Cloud", Information Systems Frontiers, vol. 14, no. 4, pp. 827-843. 2012. erformance and Security in Mobile Cloud Computing 157 [118] M. E. Haque, K. Le, I. Goiri, R. Bianchini and T. D. Nguyen, "Providing Green SLAs in High Performance Computing Clouds", 2013 International Green Computing Conference (IGCC), pp. 1-11. IEEE. 2013.[119] I. Goiri, F. Julià, J. O. Fitó, M. Macías and J. Guitart, "Supporting CPU-based guarantees in cloud SLAs via resource-level QoS metrics", Future Generation Computer Systems, vol. 28 no. 8, pp. 1295-1302. 2012.[120] A. N. Toosi, R. N. Calheiros, R. K. Thulasiram and R. Buyya, "Resource Provisioning Policies to Increase IaaS Provider's Profit in a Federated Cloud Environment", 2011 IEEE 13 th International Conference onHigh Performance Computing and Communications, pp. 279-287. 2011.[121] B. Yang, F. Tan, Y. S. Dai and S. Guo, "Performance evaluation of cloud service considering fault recovery", Cloud Computing, pp. 571-576. Springer Berlin Heidelberg.2013.[122] I. Goiri, J. Guitart and J. Torres, "Characterizing cloud federation for enhancing providers' profit", 2010 IEEE 3 rd International Conference on Cloud Computing (CLOUD), pp. 123-130. 2010.[123] A. Celesti, F. Tusa, M. Villari and A. Puliafito, "How to enhance cloud architectures to enable cross-federation", 2010 IEEE 3 rd International Conference on Cloud Computing (CLOUD), pp. 337-345. 2010.[124] S. Malik, F. Huet and D. Caromel, "Cooperative cloud computing in research and academic environment using Virtual Cloud", International Conference on Emerging Technologies (ICET), pp. 1-7. 2012. acques Bou Abdo 158 erformance and Security in Mobile Cloud Computing 159 th International Conference on Complex, Intelligent and Software Intensive Systems (CISIS 2012), pp. 241-248. 2012.[136] T. Orawiwattanakul, K. Yamaji, M. Nakamura, T. Kataoka and N. Sonehara, "User-controlled privacy protection with attribute-filter mechanism for a federated SSOenvironment using shibboleth", International Conference on P2P, Parallel, Grid, Cloud and Internet Computing (3PGCIC), pp. 243-249. 2010.[137] A. Meniya and H. Jethva, "Single-Sign-On (SSO) across open cloud computing federation", International Journal of Engineering Research and Applications (IJERA), pp. 891-895. 2012.[138] A. Revar and M. Bhavsar, "Securing user authentication using single sign-on in Cloud Computing", Nirma University International Conference on Engineering (NUiCONE), pp. 1-4. 2011.[139] N. Lo, K. Yeh and P. Liu, "An efficient resource allocation scheme for cross-cloud federation", International Conference on Anti-Counterfeiting, Security and Identification (ASID), pp. 1-4. 2012.[140] A. Celesti, F. Tusa, M. Villari and A. Puliafito, "Evaluating a distributed identity provider trusted network with delegated authentications for cloud federation", The acques Bou Abdo 160 Second International Conference on Cloud Computing, GRIDs, and Virtualization, pp. 79-85. 2011.[141] G. Wang, H. Wang, S. Arroyo, R. Rencher and J. Tjelle, "Compositional QoS Modeling and Analysis of Cloud-based Federated Ecosystems", IEEE 16 th International Enterprise Distributed Object Computing Conference (EDOC 2012), pp. 173-182.2012.[142] Z. Li, D. Huang, L. Zhuang and J. Huang, "Research of peer discovery method in peer-to-peer network", IEEE Region 10 Conference on Computers, Communications, Control and Power Engineering (TENCON'02), vol. 1, pp. 383-386. 2002.[143] P. Tugnawat and M.E. Fayad, "Advanced Peer to Peer Discovery and Interaction Framework", 18 th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA 2003). 2002.[144] S. Kamvar, M. Schlosser and H. Garcia-Molina, "The eigentrust algorithm for reputation management in P2P networks", 12 th International conference on World Wide Web, pp. 640-651. 2003.[145] P. Dewan and P. Dasgupta, "P2P reputation management using distributed identities and decentralized recommendation chains", IEEE Transactions on Knowledge and Data Engineering, vol. 22 no.7, pp. 1000-1013. 2010.[146] J. Hu, Q. Wu and B. Zhou, "Secure and Distributed P2P Reputation Management", Journal of Communications, vol. 3 no. 7, pp. 44-51. 2008.[147] S. Marti and H. Garcia-Molina, "Taxonomy of trust: Categorizing P2P reputation systems", Computer Networks, vol. 50 no. 4, pp. 472-484. 2006. erformance and Security in Mobile Cloud Computing 161 [148] M. Gupta, P. Judge and M. Ammar, "A reputation system for peer-to-peer networks", 13 th international workshop on Network and operating systems support for digital audio and video, pp. 144-152. 2003.[149] P. Mell and T. Grance, "The NIST Definition of Cloud Computing", National Institute of Standards and Technology, Special Publication 800-145, Sep. 2011.[150] W. Itani, A. Kayssi and A. Chehab, "Privacy as a service: Privacy-aware data storage and processing in cloud computing architectures", 8 th IEEE International Conference on Dependable, Autonomic and Secure Computing (DASC'09), pp. 711-716. 2009.[151] A. Lenk, M. Klems, J. Nimis, S. Tai and T. Sandholm, "What's inside the Cloud? An architectural map of the Cloud landscape", 2009 ICSE Workshop on Software Engineering Challenges of Cloud Computing, pp. 23-31. 2009.[152] R. Moreno-Vozmediano, R. S. Montero and I. M. Llorente, "IaaS Cloud Architecture: From Virtualized Datacenters to Federated Cloud Infrastructures", IEEE Computer Magazine, pp. 65-72, Dec. 2012.[153] D. Ardagna, E. di Nitto, P. Mohagheghi, S. Mosser, C. Ballagny, F. D'Andria, G. Casale, P. Matthews, C. Nechifor, D. Petcu, A. Gericke and C. Sheridan, "MODAClouds: A model-driven approach for the design and execution of applications on multiple Clouds", ICSE Workshop on Modeling in Software Engineering (MISE 2012), pp. 50-56. 2012.[154] Y. Wang and H. Chen, "Dynamic Resource Arrangement in Cloud Federation", IEEE Asia-Pacific Services Computing Conference (APSCC 2012), pp. 50-57. 2012.[155] R. Sanchez Guerrero, P. Arias Cabarcos, F. Almenares Mendoza and D. Diaz-Sanchez, "Trust-aware federated IdM in consumer cloud computing", IEEE International Conference on Consumer Electronics (ICCE 2012), pp. 53-54. 2012. acques Bou Abdo 162acques Bou Abdo 162