Comparative Study of Smart Phone Security Techniques

(1)

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459, ISO 9001:2008 Certified Journal, Volume 5, Issue 2, February 2015)

240

Comparative Study of Smart Phone Security Techniques

Pritam R. Tarle

E&TC, University of Pune, India.

Abstract— Day by day, smart phones are becoming an

integral part of various fields in our life. The increased use of smart phones has raised the issue of security of data stored in android smart phones. Various techniques have been suggested for securing data stored on smart phones. Many of them fall in the category of android extensions i.e. making changes in the android operating system. While in some solutions, mobile virtualization technique is used. This paper gives a brief review of android security solutions implemented using android extensions as well as mobile virtualization.

Keywords— Android, access control, context, virtualization

I. INTRODUCTION

Increasing sales of smart phones speak about vitality of their use in various fields. Fig. 1 shows that android is most popular OS for smart phone development with approximately 82 percent share because Android is open source and freely available to manufacturers or developers of third party application.

82% 18%

Fig 1. Smart phone sOS

Android OS

Other OS

Smart phones are being effectively used in the corporate world these days. Smart phones ensure their users to do various tasks anywhere anytime with high storage and computing speed. Mobile versions of the desktop applications are being developed by many companies which help to improve employee productivity by permitting access to enterprise services with smart phones. So, users need their personal smart phones to be connected to their work place. Fig. 2 shows many companies are accepting the BYOD (Bring Your Own Device concept) to provide mobile access to company’s applications.

Despite this positive scenario, users can install many third-party applications on their smart phones. Many personal apps are not even loyally tested hence fail to satisfy corporate security scale. Every Android app asks for some permission while its installation to access files on phone and user has to grant all permissions to install that application or deny permissions and installation will be cancelled. Hence, third-party applications installation may arise several security problems.

37% 26%

5% 7%

18%

7% 25%

Fig 2. BYOD devices Desktop

Laptop

Ultraportable

Notebook

Smartphone

Tablet

For example, malicious applications may access emails, SMS, MMS, photos and files stored in smart phone containing confidential data of enterprises and chances of stealing sensitive data increase. Android user simply provides login information and smart phone automatically synchronizes applications with data on it. Using this accessed data, applications advertise to users. This constitutes serious security problems to confidential corporate data, mainly when standard security mechanisms fail to protect users from such attacks. Hence, securing the use of smart phones and data separation according to different purposes of their use is of primary importance.

Taking security issues and concerns related to smart phones into consideration, there is a need to provide some effective and user friendly solution making the use of smart phones secure, as far as the rapidly increasing utilization and multiple uses of these devices is considered. Various techniques have been suggested for securing data stored on smart phones. Many of them fall in the category of android extensions i.e. making changes in the android operating system. While in some solutions, mobile virtualization technique is used. This paper gives a brief review of android security solutions implemented using android extensions as well as mobile virtualization.

II. RELATED WORK

(2)

International Journal of Emerging Technology and Advanced Engineering

241

A. Android Security Extensions

In Android, at installation time users grant applications the permissions asked for in the manifest file. Android carries all-or-nothing approach, i.e. the user has to either allow all the permissions specified in the manifest or terminate the installation of the application. Moreover, permission cannot be cancelled at runtime. To avoid this coarse-grained approach, many solutions have been suggested.

[image:2.595.50.279.394.478.2]

CRêPE i.e. context related policy enforcement system is one solution [1]. Context-related access control is not new, but this work used this concept into the smart phone environment first. It allows context-related policies to be set (even at runtime) by both the user and authorized third parties locally or remotely. It allows users and other predefined trusted parties to define context-related policies, which can be installed, updated and applied also system-wide at runtime. Alternatively, these policies can be applied in a fine-grained manner. So, with this approach user can create policies that automatically control granting of permissions during runtime.

Fig.3. Access control model

The model is illustrated in Fig 3 shows access control model for this technique. In this model, policies are linked to contexts, and the dynamic activation/deactivation of contexts (that decides which policies have to be imposed) is identified automatically by the sensors present in every smartphone. This model allows to change/adapt policies at application runtime and at installation time as well. Furthermore, it supports dynamic policy management, thus at any time the administrator can set, delete and modify new contexts/policies at runtime. If such changes require the system to raise/end existing service/application, this is supported as well by the model.

The letters a, b, c, and d show the progression flow of a runtime way in request: the request is interrupted (arrow) by the Policy Enforcement Point (PEP); this, sequentially asks (b) the Policy Decision Point (PDP) whether the request should be approved based on the Answer (c), the request will be granted (d) or not. The roman numbers I, and II show the flow of progression due to executive commands. In fact, certified parties can set contexts and associated policies in the system (arrow 1). As a result of this, the Policy Administration Point (PAP), informs the Context Detector that the newly set contexts need to be observed (II).

The Arabic numbers 1, 2, 3, 4, and 5 specify the course of processing started by context becoming active/non active.

The Context Detector continuously observes the environment via phone sensors (arrow 1). The moment a registered context (set as described before) becomes active/non active, the Context Detector informs the PAP (2) that has to activate/deactivate the new policy (composed by access control rules and obligations). From all the contexts that are currently active, the PAP makes a decision (resolving conflicts) the set of rules that need to be implemented. Hence, this information is given to the PDP (3). PDP saves the information related to access control, though sends to the PEP obligations (4). PEP, in turn, is responsible for taking the actions specified by the obligation policies, this is done with a component called Action Executor(5).

YAASE (Yet Another Android Security Extension) introduces a flexible and powerful privacy enforcement framework [2] transparent to the applications in the Android platform. It modified part of the Android framework and core libraries, and a set of services and managers that reside outside the application VM. It provides a very fine-grained policy enforcement mechanism where policies define several levels of control granularity over accesses to phone resources. This system leverages user-defined labels associated with data and enforces the correct dissemination of the tagged data for both communications. System policies define the data labels that an application is authorized to handle as defined by the user. When applications try to access labelled data for which policy doesn’t grant the access, then the application will not be permitted to access the data. Hence, this solution implemented fine grained security mechanism protecting user from malicious applications. But, provided user setting interface is not simpler enough for average user to express security requirements.

policy Requester can do operation on Resource [have to perform action]

handle dataLabelExpression

Fig. 4. Syntax.

(3)

International Journal of Emerging Technology and Advanced Engineering

242

The handle names an expression on the labels connected with the data that is being passed from the Requester to the Resource if operation is a method that does not return any data. Else, if the operation is a getter method giving data from the Resource to the Requester, the expression described in handle clause refers to the labels connected with returned value.

But, above solutions are Android security extensions i.e. modifications of Android operating system itself. Hence, removing these systems is not just as simple as removing an application and their removal would result in a non working system.

Another is a flexible data driven security for Android [3] that encompasses data-driven usage control, a generalization of access control to the time after data has been accessed. Objective is to enhance Android security in a way that the usage of resources can be observed and controlled through the specification of explicit, fine-grained security policies. To this end, it adds a reference monitor to Android that can observe and control events that pertain to the behaviour of applications and the usage of resources. By the integration of data-driven usage control concepts, data or resource usage can flexibly be restricted.

Flexible security checks can be implemented at different system layers. For this system, enforcement at the application framework level is best solution. It serves as middleware, provides hardware abstraction and system services for multiple purposes hence ideal place to monitor events and to enforce security policies. It monitors four types of events: permission checks, queries to content providers, intents and certain data sinks like the network, file system and IPC. Hence, in this solution policy enforcement is based on events and actions. Policies have these parts: A set of event declarations (events that can occur in a actual system) and a set of mechanism descriptions, with preventive and detective event-condition-action (or ECA) rules. Preventive systems can obstruct or modify the event, while detective systems can only monitor that an event occurred under the condition specified in the rule. Both strategies can perform additional actions. But, this system assumes a non-rooted and vulnerability-free device. Both assumptions in practice are quite questionable. This is because, rooting an Android device is quite simple even for unexperienced users and vulnerability reports are quite frequent.

Other research presented a framework for the run time enforcement of privacy policies on smart phones, mainly, protecting privacy of enterprise data on smart phones [4]. These privacy policies are defined in terms of permissible information flows on the phone during different contexts. This gives users more fine grained control over information access by different applications.

In this policy framework, an information flow is defined based on the entities involved in the corresponding inter-process communication (IPC) viz, the caller, callee and the associated IPC data. Information flow policy says the conditions under which an IPC flow may be permitted (or denied). System tracks information flows at run time and insist that, only flows satisfying every current policies are permitted on the phone. Information flow policies are based on:

1) IPC call chain defined by the set of processes/apps requesting access

2) Attributes of the data viz. enterprise or personal data 3) Phone state determined by various attributes such as location, battery status etc. And, the phone state determines the current policy to be enforced on the phone.

To start an enterprise app, access control policy can be given as follows:

1Start App( tgtApp,srcApp ): 2tgt App.type = Enterprise ∧

3System.DeviceContext=EnterpriseContext 4∧ srcApp.type=Enterprise/System → 5allow(tgtApp,srcApp)

Fig. 5 Example of an access control policy

This policy interpretes that: An application or component, scrApp, is authorized to start/bind to an enterprise app or component, tgtApp, if srcApp is an enterprise/system application and the machine is in Enterprise Context. But it is unable to trace implicit flows and prevent the load of shared libraries by third party applications. And, number of policies may grow bulky and could potentially result in policy conflicts.

FlaskDroid [5], another approach provides mandatory access control simultaneously on both Android’s middleware and kernel layers. FlaskDroid works on two levels.

1. System-according security framework: Android security framework operates on both the middleware and kernel layer. It addresses many problems of the stock Android permission framework and of related solutions which target either the middleware or the kernel layer.

(4)

International Journal of Emerging Technology and Advanced Engineering

243

Hence, to address these attacks efficiently, more flexible policies are required.

B. Mobile Virtualization

Virtualization provides environments that are isolated, and are indistinguishable from “bare” hardware, from OS point of view. Hypervisor is responsible for guaranteeing such isolation and for coordinating the activities of the virtual machines. Virtualization technique has been greatly used in traditional computers because it can: (i) increase security, and (ii) reduce the cost of deployment of applications (the hardware is shared in a secure way).

With the spreading of mobile devices and with the increase of their performance capabilities, the porting virtualization to mobile platforms became actual. Virtualization for mobile devices provides specific advantages like: (i) the possibility to separate communication subsystems (backed by real-time operating system) from high-level application code (which requires functional rich operating system with good interfaces); (ii) an opportunity to provide licence separation; (iii) a chance to increase the security of the communication stack.

However, there are still several barriers for the adoption of virtualization in mobile devices. The main one is that ARM architecture, that is popular architecture for mobile devices, has a non-virtualizable instruction set. So as efficiency is a major concern in embedded virtualization, full virtualization approaches (emulation and binary translation) are not yet applicable for these devices because they are computationally expensive. Thus, for embedded devices para-virtualization is used, which requires source-code modification of guest operating system.

[image:4.595.346.516.142.251.2]

There are several approaches to port popular Linux hypervisors to ARM architecture: Xen described design and implementation of Xen on ARM, which is a secure system virtualization of ARM architecture [6]. It described how the open source Xen hypervisor is migrated to ARM architecture and guest OS kernel protected from applications as guest OS, applications are performing in user mode. Secure and non secure guest Linux virtual machines are executing under Xen on ARM isolated with each other. Security issue can be handled by system virtualization since it provides isolation of guest OS running under VMM, so that any compromised guest OS cannot be propagated to other guest OS domains.

Fig. 6. VCPU mode transitions

t10: on interrupt/fault/abort/hypercall, t20: on interrupt/fault/abort/system call, t01: upcall or return from exception, t02: back from exceptions

Virtual CPU is represented by a state machine as shown in Fig. 6 where each state leads to a virtual privilege mode. VMM mode starts when exceptions like interrupt, fault, abort, and software interrupt happens. On start of VMM mode, ARM CPU’s SPSR (Saved Program Status Register) is saved in the VSPSR (virtual SPSR) which will be re-established later when guest OS returns from exception. Stack pointer register is also saved in VSP register for afterwards restoration. Xen call upons upcall to carry exceptions to kernel mode as virtual exception events. On upcall, Xen places the VSPSR information on the kernel’s stack so that kernel can obtain last running virtual processor mode. The upcall mechanism matches to hardware level exception handling that leads CPU to jump into exception vector table.

However, since all these virtual machines are simply ported to mobile platforms while being designed for PCs, they all share low performance. And switching between virtual environments requires user interactions, and the configuration of each virtual environment is hardcoded and cannot be changed by the end-user. They offer only profiles predefined by the solution developers. Considering android OS security [7], [8], it can have different aspects and needs improvement on issues discussed above.

III. CONCLUSION

(5)

International Journal of Emerging Technology and Advanced Engineering

244

Further, system virtualization for ARM based mobile phones using Xen hypervisor shows low performance. Common drawback to some of these solutions is switching between virtual environments requires user interactions, and the configuration of each virtual environment is hardcoded and cannot be changed by the end-user. None of these solutions detects when a profile is active without user interaction.

Better security can be provided to android smartphones by developing user defined security profiles and their automatic operation based context detection. Also, data access by applications can be restricted by embedding rules with security profiles.

REFERENCES

[1] M. Conti, B. Crispo, E. Fernandes, and Y. Zhauniarovich, “CR^ ePE: A System for Enforcing Fine-Grained Context-Related Policies on Android,” IEEE Trans. Information Forensics and Security, vol. 7, no. 5, pp. 1426-1438, Oct. 2012.

[2] G. Russello, B. Crispo, E. Fernandes, and Y. Zhauniarovich, “YAASE: Yet Another Android Security Extension,” Proc. IEEE Third Int’l Conf. Social Computing and Privacy, Security, Risk and Trust (SocialCom/PASSAT), pp. 1033-1040, 2011.

[3] D. Feth and A. Pretschner, “Flexible Data-Driven Security for Android,” Proc. IEEE Sixth Int’l Conf. Software Security and Reliability (SERE ’12), pp. 41-50, 2012.

[4] P.B. Kodeswaran, V. Nandakumar, S. Kapoor, P. Kamaraju, A. Joshi, and S. Mukherjea, “Securing Enterprise Data on Smartphones Using Run Time Information Flow Control,” Proc. IEEE 13th Int’l Conf. Mobile Data Management (MDM ’12), pp. 300-305, 2012.

[5] S. Bugiel, S. Heuser, and A.-R. Sadeghi, “Flexible and Fine- Grained Mandatory Access Control on Android for Diverse Security and Privacy Policies,” Proc. 22nd USENIX Conf. Security (Security’13), 2013.

[6] J.-Y. Hwang, S.-B. Suh, S.-K. Heo, C.-J. Park, J.-M. Ryu, S.-Y. Park, and C.-R. Kim, “Xen on ARM: System Virtualization Using Xen Hypervisor for ARM-Based Secure Mobile Phones,” Proc. IEEE Fifth Consumer Comm. and Networking Conf. (CCNC ’08), pp. 257- 261, 2008.

[7] W. Enck, M. Ongtang, and P. McDaniel, “Understanding Android Security,” IEEE Security and Privacy, vol. 7, no. 1, pp. 50-57, Jan. / Feb. 2009.

[8] A. Shabtai, Y. Fledel, U. Kanonov, Y. Elovici, S. Dolev, and C. Glezer, “Google Android: A Comprehensive Security Assessment,” IEEE Security and Privacy, vol. 8, no. 2, pp. 35-44, Mar./Apr. 2010.

[9] E. Yuan and J. Tong, “Attributed Based Access Control (ABAC) for Web Services,” Proc. IEEE Int’l Conf. Web Services (ICWS ’05), pp. 561-569, 2005.