TAME: Trusted Augmented Mobile Execution on Cloud

Department of Information Technology, University of Haripur, Haripur, Pakistan Department of Computer Science, Faculty of Science and Arts at Belgarn, University of Bisha, P.O. Box 60, Sabt Al-Alaya, Bisha 61985, Saudi Arabia Department of Computer Science Technology, China University of Petroleum-Beijing, Beijing 102249, China Beijing Key Lab of Petroleum Data Mining, China University of Petroleum-Beijing, Beijing 102249, China School of Electrical Engineering and Computer Science, National University of Sciences and Technology, Islamabad, Pakistan


Introduction
e enhanced capabilities, improved connectivity, and increasing accessibility of smart phones have triggered a significant growth in the development of mobile applications. Mobile devices are equipped with a wide array of sensors and gadgets which constantly challenge the developers to come up with innovative products to capture the attention of mobile users as well as the market share. Application stores [1,2] are filled with applications that not only appeal to the entertainment-savvy users, but also cater to the information-sensitive domains of finances and health management.
Mobile devices have successfully captured a major chunk of users' attention away from the desktop machines and offer competitive Internet connectivity to add to their appeal. However the catch lies in the constrained processing capabilities and limited battery life of these devices. is is where mobile devices have to look towards their more grounded and plugged computing counterparts for assistance. Since the mobile devices can connect to more powerful machines via GPRS, Wi-Fi, and related networking technologies, it is a natural consequence to try augmenting the processing capabilities of mobile devices by off-loading resource-intensive tasks to resource-rich machines. Cloud computing [3] offers an attractive platform of choice for hosting resource-intensive applications on behalf of mobile devices. Solutions have already been proposed for augmented execution of mobile applications on clouds [4]. Resource-intensive tasks can be off-loaded to the cloud at various levels of granularity by working out a trade-off between resources required for performing computation ondevice against those required for off-loading task to the cloud.
Mobile phone users may utilize the software services hosted on cloud such as Google Apps [5] or even deploy a clone of the mobile phone on the cloud such as Amazon EC2 [6] garnering the benefits of closed-box execution of mobile applications. However, as with other cloud clients, the concerns of privacy and security associated with sending data/applications to the cloud prevail [7]. Even for an average user, the mobile applications and the data on which they operate are of very personal and private nature. A rootof-trust and associated chain-of-trust needs to be established to ensure the integrity and confidentiality of mobile users' data and applications running on the cloud. In case of desktop clients, standardized solutions based on remote hardware-based attestation in the form of Trusted Platform Modules (TPMs) are available [8] and may be extended to set up trusted clouds [9]. However, for mobile devices, these solutions are not applicable due to lack of hardware-based attestation support.
In this paper, we propose a model for securely hosting and executing mobile applications on clouds. We have extended the notion of secure clouds to mobile clients by providing secure communication and execution channels while keeping in view the practical limitations of mobile devices. In Sections 2 and 3, we explain the related work and background on which we build our solution. Section 4 describes our proposed security architecture in detail giving insight to our approach for ensuring secure communication and privacy-protecting data processing. Section 5 gives the security evaluation of the proposed system and summarizes the current progress. Section 6 concludes our work highlighting the future directions.

Related Work
e need to augment computing capabilities of a mobile device arises not only to host resource-heavy user applications but also to provide integrity measures to keep the device itself in a secure state. Such measures include running periodic virus scans and performing checks on the integrity of installed mobile applications [10]. e significance of these integrity measures has increased greatly with the widespread use of downloaded mobile applications [11] that may compromise mobile users' data and privacy. Keeping data synchronized between mobile and other devices of a user is another long-standing usage of mobile applications that augments mobile phone capabilities. CloneCloud [12] is a prominent effort in this regard for porting the execution of applications from mobile phones to their "clones" in the clouds, any time during execution. e concept of "elastic execution" proposed by the authors builds on the provision for migrating code running on a host virtual machine (VM) to a target VM at runtime. Since most mobile phones run applications on an underlying application-layer VM [13], this solution has wide-scale applicability. eir solution essentially opens up the Infrastructure as a Service (IaaS) capabilities of the cloud to mobile users. However, it does not focus on the security aspects of hosting data or complete clone of the mobile device on the cloud.
For desktop clients of clouds, a model for trusted clouds has been proposed [9] which ensures confidential execution of guest VMs on clouds. e proposed model extends the notion of remote attestation via TPMs to cloud computing paradigm. A cloud consists of a number of nodes on which the client's VM could be hosted. Every time a VM has to be launched or migrated from one node to the other in the cloud, it is ensured that the node is trustworthy. e focus is on enabling the IaaS providers such as Amazon EC2 to provide closed-box execution environment to their clients. However, the same approach cannot be readily applied to mobile phone clients due to their limited resources and lack of support for hardware-based attestation. In [14], the authors propose an architecture exploiting sealed storage mechanism that attests the cloud node prior to launching customer data and ensures confidentiality of customers' data even if the cloud node becomes compromised. In [15], the authors propose trusted attestation architecture for Infrastructure as a Service. e architecture ensures the attestation of virtual machine, hypervisor, and host operating system using the Trusted Platform Module (TPM) and Virtual Trusted Module (vTPM).
Standards for Mobile Trusted Modules (MTMs) [16] have been proposed for hardware-based attestation of mobile devices, and standardized hardware implementations are expected to be available soon. In [17], the authors have developed an emulator based on a subset of MTM standards for remote attestation of Android platform [13]. e work focuses on establishing trustworthiness of the applications running on Android platform including the Android Dalvik VM. Additionally, the remote attestation process is able to attest the classes loaded by the VM to establish the validity of applications running on top of the virtual machine. It is a significant improvement in the attestation process which is often limited to applications launched directly by the operating system. eir architecture can be readily ported to work with actual hardware MTMs once available. However, the confidentiality and integrity of key-pairs and hashes stored on disk cannot be ascertained. e trustworthiness of a mobile device is not guaranteed any further than the trustworthiness established via maintaining traditional key-stores at the mobile device.
In this paper, we combine the concepts presented in [9,12] and add in the missing ingredient of trusted execution of mobile applications on clouds to provide a comprehensive end-to-end security architecture for mobile clients. In Section 4, we discuss our approach for addressing the security and trust establishment issues faced by mobile clients when hosting data and applications on cloud. Most of the work carried out in porting mobile applications to clouds focuses on Android-based mobile phones. is is due to the open platform that Android offers as well as the popularity and increasing market share of Android phones [11]. In this context, the focus of our proposed architecture is on securely augmenting capabilities of Android-based mobile devices by employing trusted cloud backend.

Virtualization.
Virtualization is a mechanism of dividing hardware or some subset of hardware of a computer system among several virtual machines (VMs), which bear resemblance to the physical system. Virtualization is carried out by a virtual machine monitor (VMM), a layer that divides the hardware. XEN [18] provides a virtualization layer that ensures the separation of VMs and executes instructions on their behalf. At the same time, XEN manages a domain (Dom0), which controls the access of VMs to physical hardware and facilitates communication among VMs hosted on the shared hardware. e virtualized system attempts to provide virtualized network and storage devices, thus providing an environment similar to that of a real system. e frontend drivers communicate with backend drivers via sockets. Normally, backend drivers are provided within Dom0 of XEN, but these drivers can also run within other virtual machines. In order to ensure the security, the applications running in one virtual machine should not be interfered by the applications executing on another VM; it is achieved by isolating the VMs by virtual machine monitor. is separation is maintained through different in-built privileged levels in the CPU. is separation can only be trusted if the whole software stack loaded into the system, right from BIOS to the VMM and over the Dom0, is relied upon. Trusted Computing Base (TCB) for a VM is formed only if the software running on the system is correct and works as expected. is issue has been addressed by measurement techniques provided by Trusted Computing Group (TCG).

TCG.
e specifications published by TCG [19,20] provide a mechanism to attest the computing platforms based on a Trusted Platform Module (TPM), a root of trust, and a co-processor mounted on the motherboard of the computer. As per latest specifications [21] TPM contains 24 Platform Configuration Registers (PCRs) that get filled with cryptographic hashes of the software stack loaded and running on the system. ese PCRs are automatically established when the computer goes through the boot cycle; values in these registers can be extended later on but cannot be replaced with chosen values. e BIOS code forms the Core Root of Trust for Measurement (CRTM), and then every link in the chain is measured by the prior one. CRTM first calculates the BIOS, extends values in relevant register, and then transfer controls to the BIOS. en, BIOS measures ROM configurations/data and extends values to the TPM registers. Similarly, all the components are measured right from BIOS to the operating system level and measurements are recorded in the PCRs. Even, up and above the OS, the applications can also be measured [22], stored in the kernel held Stored Measurement Log (SML), and then extended in the related register. is extension process ensures that the values in the PCRs cannot be manipulated and reached via any other route. PCR values are signed by Attestation Identity Key (AIK) residing within TPM, which allows the state of computer to be communicated with other parties, who then validates if the values and platform can be trusted. e validity of TPM is verified by these signing key certified by certification authority during remote attestation procedure.

Trusted Virtualization.
A virtualized system enriched with additional components gets complex to measure. e conventional TCG scheme for measurement can be extended [23] to virtualized systems. It allows trust to be communicated over the full software stack of the system, which includes measurement of BIOS, bootloader, VMM, image for Dom0, additional kernel modules, and associated configuration files. e attestation of the system up to the base level can be achieved through this process; however, the end user may also want to attest the guest operating system, which can be achieved by further extending PCR measurements. e already attested measurement agent in the Dom0 can give directions for the measurement and communication of guest operating systems. Virtual TPM (vTPM) [24] is just an extension of this idea where measurement services along with other TPM functions can be provided by each domain. ese vTPMs can be made available from within Dom0 or from within a separate virtual machine linked to the VM.

The Architecture
e main objective of this work is to provide a mechanism for secure transfer and trusted execution of mobile users' data and applications on the cloud. In order to guarantee end-to-end security, the proposed system establishes the trustworthiness of the cloud node before giving access to the data via a secure channel. e three main participating entities are (a) the Android-based mobile client, (b) a number of cloud nodes (N 1 , . . ., N n ), managed by the Cloud Manager (CM), on which the processing is off-loaded, and (c) a Trusted Coordinator (TC) that acts as the trusted third party and attests the cloud nodes. TC is similar to certificate authority in the TCG adopted Direct Anonymous Attestation protocol [25].
We assume that the cloud nodes, as well as the trusted coordinator, are TPM-enabled platforms and can participate in carrying out remote attestation of the nodes. We also assume that a key-store containing symmetric-keys associated with the mobile client is available at the mobile device. Figure 1 provides an overview of our proposed system architecture. e selection of encryption and attestation technologies is made in keeping with the actual capabilities of each participating entity while ensuring a high level of trust. e Android client can generate and store symmetric keys (AES key ) in its key store along with the trusted key (TK TC public ) of the TC. e details regarding message exchange between each set of communicating party and the role of different keys are discussed in the following sections.
e configuration files at the mobile client provide basic information related to off-loading data and applications to the cloud backend. A detailed model of elastic execution between mobile client and cloud host is given in [5,12].

Establishing Secure Channel.
e data sent from the mobile client to the cloud nodes are encrypted using symmetric key cryptography. Owing to the security, fast speed, and low RAM requirements of AES, it is a suitable encryption algorithm for mobile clients; hence, we use AES key for encryption of the communication channel between mobile client and cloud. Moreover, AES supports encryption of large chunks of data without significant performance overhead at the client. e AES key (AES key ) used by the mobile client for encryption, however, is not readily made available to the cloud node receiving the encrypted message.
e key is itself encrypted and a node can only gain access to it after it has successfully attested itself to the TC (explained in Section 4.3).
It is important to mention that we are interested not only in establishing a secure channel between the mobile client and the cloud node but also in restricting untrusted nodes from gaining access to the data. As the client does not know which node will be selected to process its data, we have not used SSL [26] which enables secure data communication between already trusting parties.

Registration of Cloud Nodes.
In the proposed solution, registration of each cloud node is a required step that is performed before the node can be used in the cloud to perform any computations on behalf of the mobile clients. At the end of registration, the public part of an RSA key pair (TK Ni public , i.e., specific to a particular node) generated by a node and stored in its volatile memory is known to TC that is later used to exchange the key between node and TC as explained in next section. e reasons to store this key pair in volatile memory are (1) to require the node to get itself reregistered whenever its state is changed or is rebooted and (2) to prohibit the key to be used once a node's state is modified which is achieved because only the trusted applications are running on each node.
In our solution, both the cloud nodes (N 1 , . . ., N n ) and the trusted coordinator (TC) contain TPM chip for hardware attestation and hence can utilize the TCG remote attestation mechanism [19] along with registration of the cloud nodes. Instead of encrypting the complete Stored Measurement Log (SML) of the node (SML Ni , i.e., specific to a particular node) and the TC (SML TC ), we encrypt the value of PCR-10 register containing the aggregate hash of the platform's state. is enables the receiving party to verify the SML of the sending party against the value of PCR-10 to check if a node maintains a trusted configuration [27]. Figure 2 shows the messages exchanged between the nodes and TC during the registration process.
Attestation Identity Key (AIK) is used for authentication purpose by the TPM to sign the PCR values and its corresponding public part is used by the other party to verify signatures. It is assumed that the public part of the AIK (AIK public ) of each node is already known to the TC and vice versa. Moreover, each node is also aware of a Trusted Key (TK TC public ) which will be used to encrypt any data to be sent to TC that could be decrypted outside TPM, since the data encrypted with AIK can only be decrypted within the TPM.
When a node wishes to register itself with the TC, (1) it generates a nonce (n Ni ) and sends to the TC. Upon receiving the nonce, (2) TC signs the nonce along with the value of PCR-10 register using its AIK (AIK TC private ). It also sends SML TC and a nonce (n TC ) along with the encrypted content to the node. e node verifies signature of TC using AIK of TC (AIK TC public ) and then verifies the SML of TC against the signed PCR-10 value. Since the nonce generated by the node (n Ni ) is also signed along with the PCR-10 contents by the TC, node can be sure that it is a fresh value reflecting the current configuration of the TC. Afterwards, (3) the node sends the value of its PCR-10 and the nonce sent by TC (n TC ) signed by its AIK (AIK N private ). It also sends the SML Ni so that TC can verify the SML Ni against PCR-10. e node also sends the public part of its Trusted Key (TK Ni public ) to the TC which is stored with the TC and is used during node attestation as explained in the next section. All the message content, except for the SML Ni , is encrypted using the TK TC public so that it is only accessible to the TC.
Upon receiving message (3), TC decrypts the contents using its TK TC private , verifies the signature on PCR-10, and matches the SML Ni against the PCR-10. TC also compares the signed nonce sent back by the node to ensure that the SML Ni are current. If all are verified, (4) TC sends the registration message signed by the newly received TK Ni public of the node. is signals the successful registration of the node with the TC along with the acceptance of the node's TK Ni public . e node registration procedure is independent of the fact that the nodes host data/applications sent by a mobile client or a desktop client. erefore, the notion of Trusted Clouds [19] can be utilized by the mobile clients in the same manner as other clients of cloud computing.

Trusted Computation on Cloud.
is section explains the mechanism for carrying out trusted computation on the cloud on behalf of the mobile client. e mobile client, along with the cloud nodes, has access to the trusted key of TC, TK TC public . e TC also has the trusted keys of the nodes, TK Ni public . As mentioned in Section 4.1, the symmetric key (AES key )-used by the mobile client for encrypting the data sent to cloud-is made available to the node after successful attestation by the TC. is enables the mobile client to offload its data and applications to the cloud nodes in a secure and trusted manner.
When a mobile client wishes to off-load the computation of a resource-intensive task to the cloud, (1) it encrypts the associated data using an AES key before sending it to the cloud. e mobile client also needs to communicate the AES key so that the receiving party can decrypt the information.
e AES key is encrypted using the TK TC public restricting the cloud node to gain access to the AES key and hence the encrypted data, without first contacting the TC and proving that it is in trusted state. e mobile client also sends a nonce (n U , i.e., nonce generated by the user) encrypted alongside the AES key to ensure the freshness of the communication.
Upon receipt of the encrypted message, the node must prove to the TC that it is trustworthy so that the TC may decrypt and send the AES key to the node. e various messages exchanged between communicating parties to achieve trusted computation are shown in Figure 3.
To access the AES key encrypted with the TK TC pbulic , (2) the cloud node passes on the encrypted key and nonce sent by the mobile user n U to the TC. It also sends a nonce n N and node information N to the TC using TK TC pbulic . In order to demonstrate the fact that the node is already registered with the TC, it computes the hash of the above parameters and signs it using node's trusted key TK Ni private . If the node is registered with the TC, TC is able to decrypt this part using TK Ni public of the node -provided at the time of registration (explained in Section 4.2)-decrypts the AES key and (3) sends back to the node the AES key along with n U and n N encrypted with the TK Ni public of the node. In order to ensure that the message is from the TC, TC also computes the hash of the contents and signs it using its TK TC private . In case the node is not already registered, it is first required to register itself with the TC as explained in Section 4.2.
Once the AES key is revealed to the node, it decrypts the message, performs the necessary computations on behalf of the mobile client, and (4) sends back the results encrypted by the same symmetric key (AES key ). e node also sends back the original nonce n U to validate that the results are from a current computation.
It should be noted that the mobile device uses different AES keys for setting up secure communication channel for  erefore, if a node having access to a particular AES key is compromised, it will still not be able to decrypt the mobile devices' data for subsequent interaction.

Discussion
In the proposed architecture, establishment of secure communication channel ensures the confidentiality of customer data while it is under processing or in transit. Each software component loaded on cloud node is measured and extended in the TPM registers ascertaining that cloud node cannot hide or mislead about the software or code running on it. In our solution, the cloud node gets encrypted data while the key to decrypt it is encrypted with the trusted key of TC (TC TK public ). In order to get the key to decrypt data, cloud node has to contact TC with another trusted key (TK Ni public , specific to each client). TK Ni public is stored in the volatile memory at each node and is automatically destroyed whenever the configurations of a node changes or if the node is rebooted, requiring the node to re-register itself with TC. e use of nonce in the above protocols ensures freshness. Prior to revealing the key, TC on behalf of mobile client checks the cloud node, through remote attestation procedure, that it is in trustworthy state and is not executing any malicious software which can store or spy on mobile client data. Trusted software running at each node guarantees confidentiality of client data during computation. e prototype implementation of the proposed system provides encouraging results; however, we believe that the performance can be further improved; hence, we are yet carrying out the experiments. From the initial results, we are convinced of the validity and usefulness of our proposed solution. e overhead caused is perfectly tolerable for large sized data, as the time taken for data processing is directly proportional to the size of the data to be processed, at the cost of security and processing provided for resource-starved devices. ese factors provide strong basis for the practical implication of our proposed architecture. We provide detailed security analysis of the system by evaluating the system against the known threats at each stage in Table 1.
We have catered to the major threats on cloud node and on TC and the threats to mobile client by using the standard security mechanisms while exploiting trusted computing.
e proposed solution provides end-to-end secure communication between mobile client and cloud by employing TPM-based remote attestation of cloud nodes ensuring the confidentiality and integrity of the computations performed by the cloud nodes.
is demonstrates that the mobile devices can securely augment their capabilities by off-

Conclusions and Future Direction
We have defined a mechanism for secure exchange of data between mobile devices and cloud hosts. It guarantees that only trusted cloud nodes are allowed access to the mobile device's data addressing the concerns related to confidentiality and integrity of the computations performed by the cloud node. By utilizing the concepts of elastic execution [9] and trusted clouds [12] and applying our model for secure communication and trust establishment, a comprehensive end-to-end security infrastructure has been provided for mobile clients of cloud computing. e security architecture is tailored to the capabilities of the participating entities. At the mobile device's end, we have employed the AES symmetric key encryption to minimize the encryption overhead. Cloud nodes, on the other hand, are attested by a trusted coordinator TC to establish that they are in a secure and trusted configuration before gaining access to the symmetric key. us, only trusted nodes are selected to carry out the required computation on behalf of the mobile device. e probability of sending any malicious data by rogue mobile clients is high, which can be harmful to the cloud and at the same time can steal the data of other customers, hence compromising the privacy and breaching the security of cloud [28]. us, future researchers would find it interesting to probe the dimensions of attesting the validity and reliability of the mobile clients. is will open a vast field of discussion for researchers to take into account protocols that enable mobile device verification prior to granting them access to cloud resources.
Recently, a new usage scenario that encompasses mobile applications and the cloud is emerging, that is, "testdriving" a potential application on the cloud prior to purchasing it. Consider the case of Amazon testdrive [29,30] that allows users to preview any Android application in the App Store directly from their browsers by launching an emulated instance of Android on its EC2 cloud, allowing direct control from the browser (using Flash). e reader can easily imagine the usefulness of TAME c in securing licensing and customized features in such a scenario. In fact, there are reports [31] that one of the primary reasons testdrive was disabled as soon as it was launched was fear of insecure data exchange.
In addition to implementing a complete prototype of our proposed system, a future direction could be identifying the failure models of the trust establishment mechanism itself. An important question arises that if a nontrusted node receives the encrypted data and is not able to attest itself to the TC, how will the mobile client be notified. In this case, there should be an upper bound on the time after which the mobile device should stop expecting to receive results from the cloud node. e TC may also notify the mobile device of a failed attestation attempt by a node. However, the issue still remains if the node receiving the data never contacts the TC.
is and similar concerns are not necessarily specific to the mobile clients and offer an interesting area to explore. We hope that research in this direction will give useful insight for further enhancing the proposed security infrastructure.

Data Availability
e data used to support the findings of this study are provided within the article.

Conflicts of Interest
e authors declare that they have no conflicts of interest.