\documentclass[11pt,twoside]{article}\makeatletter \IfFileExists{xcolor.sty}% {\RequirePackage{xcolor}}% {\RequirePackage{color}} \usepackage{colortbl} \usepackage{wrapfig} \usepackage{ifxetex} \ifxetex \usepackage{fontspec} \usepackage{xunicode} \catcode`⃥=\active \def⃥{\textbackslash} \catcode`❴=\active \def❴{\{} \catcode`❵=\active \def❵{\}} \def\textJapanese{\fontspec{Noto Sans CJK JP}} \def\textChinese{\fontspec{Noto Sans CJK SC}} \def\textKorean{\fontspec{Noto Sans CJK KR}} \setmonofont{DejaVu Sans Mono} \else \IfFileExists{utf8x.def}% {\usepackage[utf8x]{inputenc} \PrerenderUnicode{–} }% {\usepackage[utf8]{inputenc}} \usepackage[english]{babel} \usepackage[T1]{fontenc} \usepackage{float} \usepackage[]{ucs} \uc@dclc{8421}{default}{\textbackslash } \uc@dclc{10100}{default}{\{} \uc@dclc{10101}{default}{\}} \uc@dclc{8491}{default}{\AA{}} \uc@dclc{8239}{default}{\,} \uc@dclc{20154}{default}{ } \uc@dclc{10148}{default}{>} \def\textschwa{\rotatebox{-90}{e}} \def\textJapanese{} \def\textChinese{} \IfFileExists{tipa.sty}{\usepackage{tipa}}{} \fi \def\exampleFont{\ttfamily\small} \DeclareTextSymbol{\textpi}{OML}{25} \usepackage{relsize} \RequirePackage{array} \def\@testpach{\@chclass \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else \ifnum \@lastchclass=7 5 \else \ifnum \@lastchclass=8 \tw@ \else \ifnum \@lastchclass=9 \thr@@ \else \z@ \ifnum \@lastchclass = 10 \else \edef\@nextchar{\expandafter\string\@nextchar}% \@chnum \if \@nextchar c\z@ \else \if \@nextchar l\@ne \else \if \@nextchar r\tw@ \else \z@ \@chclass \if\@nextchar |\@ne \else \if \@nextchar !6 \else \if \@nextchar @7 \else \if \@nextchar (8 \else \if \@nextchar )9 \else 10 \@chnum \if \@nextchar m\thr@@\else \if \@nextchar p4 \else \if \@nextchar b5 \else \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi \fi \fi \fi \fi \fi \fi \fi \fi \fi \fi \fi \fi} \gdef\arraybackslash{\let\\=\@arraycr} \def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}} \def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}} \def\abbr{} \def\corr{} \def\expan{} \def\gap{} \def\orig{} \def\reg{} \def\ref{} \def\sic{} \def\persName{}\def\name{} \def\placeName{} \def\orgName{} \def\textcal#1{{\fontspec{Lucida Calligraphy}#1}} \def\textgothic#1{{\fontspec{Lucida Blackletter}#1}} \def\textlarge#1{{\large #1}} \def\textoverbar#1{\ensuremath{\overline{#1}}} \def\textquoted#1{‘#1’} \def\textsmall#1{{\small #1}} \def\textsubscript#1{\@textsubscript{\selectfont#1}} \def\textxi{\ensuremath{\xi}} \def\titlem{\itshape} \newenvironment{biblfree}{}{\ifvmode\par\fi } \newenvironment{bibl}{}{} \newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par } \newenvironment{citbibl}{}{\ifvmode\par\fi } \newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi } \newenvironment{docDate}{}{\ifvmode\par\fi } \newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi } \newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par } \newenvironment{msHead}{\vskip 6pt}{\par} \newenvironment{msItem}{\vskip 6pt}{\par} \newenvironment{rubric}{}{} \newenvironment{titlePart}{}{\par } \newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}} \newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}} \newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}} \newcolumntype{P}[1]{){\arraybackslash}p{#1}} \newcolumntype{B}[1]{){\arraybackslash}b{#1}} \newcolumntype{M}[1]{){\arraybackslash}m{#1}} \definecolor{label}{gray}{0.75} \def\unusedattribute#1{\sout{\textcolor{label}{#1}}} \DeclareRobustCommand*{\xref}{\hyper@normalise\xref@} \def\xref@#1#2{\hyper@linkurl{#2}{#1}} \begingroup \catcode`\_=\active \gdef_#1{\ensuremath{\sb{\mathrm{#1}}}} \endgroup \mathcode`\_=\string"8000 \catcode`\_=12\relax \usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry} \usepackage{framed} \definecolor{shadecolor}{gray}{0.95} \usepackage{longtable} \usepackage[normalem]{ulem} \usepackage{fancyvrb} \usepackage{fancyhdr} \usepackage{graphicx} \usepackage{marginnote} \renewcommand{\@cite}[1]{#1} \renewcommand*{\marginfont}{\itshape\footnotesize} \def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif} \pagestyle{fancy} \usepackage[pdftitle={Evaluating Smartphone Application Security: A Case Study on Android}, pdfauthor={}]{hyperref} \hyperbaseurl{} \paperwidth210mm \paperheight297mm \def\@pnumwidth{1.55em} \def\@tocrmarg {2.55em} \def\@dotsep{4.5} \setcounter{tocdepth}{3} \clubpenalty=8000 \emergencystretch 3em \hbadness=4000 \hyphenpenalty=400 \pretolerance=750 \tolerance=2000 \vbadness=4000 \widowpenalty=10000 \renewcommand\section{\@startsection {section}{1}{\z@}% {-1.75ex \@plus -0.5ex \@minus -.2ex}% {0.5ex \@plus .2ex}% {\reset@font\Large\bfseries}} \renewcommand\subsection{\@startsection{subsection}{2}{\z@}% {-1.75ex\@plus -0.5ex \@minus- .2ex}% {0.5ex \@plus .2ex}% {\reset@font\Large}} \renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}% {-1.5ex\@plus -0.35ex \@minus -.2ex}% {0.5ex \@plus .2ex}% {\reset@font\large}} \renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}% {-1ex \@plus-0.35ex \@minus -0.2ex}% {0.5ex \@plus .2ex}% {\reset@font\normalsize}} \renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}% {1.5ex \@plus1ex \@minus .2ex}% {-1em}% {\reset@font\normalsize\bfseries}} \def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt} \@tempdima 1.5em \begingroup \parindent \z@ \rightskip \@pnumwidth \parfillskip -\@pnumwidth \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par \endgroup} \def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}} \def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}} \def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}} \def\l@subparagraph{\@dottedtocline{5}{10em}{5em}} \@ifundefined{c@section}{\newcounter{section}}{} \@ifundefined{c@chapter}{\newcounter{chapter}}{} \newif\if@mainmatter \@mainmattertrue \def\chaptername{Chapter} \def\frontmatter{% \pagenumbering{roman} \def\thechapter{\@roman\c@chapter} \def\theHchapter{\roman{chapter}} \def\thesection{\@roman\c@section} \def\theHsection{\roman{section}} \def\@chapapp{}% } \def\mainmatter{% \cleardoublepage \def\thechapter{\@arabic\c@chapter} \setcounter{chapter}{0} \setcounter{section}{0} \pagenumbering{arabic} \setcounter{secnumdepth}{6} \def\@chapapp{\chaptername}% \def\theHchapter{\arabic{chapter}} \def\thesection{\@arabic\c@section} \def\theHsection{\arabic{section}} } \def\backmatter{% \cleardoublepage \setcounter{chapter}{0} \setcounter{section}{0} \setcounter{secnumdepth}{2} \def\@chapapp{\appendixname}% \def\thechapter{\@Alph\c@chapter} \def\theHchapter{\Alph{chapter}} \appendix } \newenvironment{bibitemlist}[1]{% \list{\@biblabel{\@arabic\c@enumiv}}% {\settowidth\labelwidth{\@biblabel{#1}}% \leftmargin\labelwidth \advance\leftmargin\labelsep \@openbib@code \usecounter{enumiv}% \let\p@enumiv\@empty \renewcommand\theenumiv{\@arabic\c@enumiv}% }% \sloppy \clubpenalty4000 \@clubpenalty \clubpenalty \widowpenalty4000% \sfcode`\.\@m}% {\def\@noitemerr {\@latex@warning{Empty `bibitemlist' environment}}% \endlist} \def\tableofcontents{\section*{\contentsname}\@starttoc{toc}} \parskip0pt \parindent1em \def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}} \newenvironment{reflist}{% \begin{raggedright}\begin{list}{} {% \setlength{\topsep}{0pt}% \setlength{\rightmargin}{0.25in}% \setlength{\itemsep}{0pt}% \setlength{\itemindent}{0pt}% \setlength{\parskip}{0pt}% \setlength{\parsep}{2pt}% \def\makelabel##1{\itshape ##1}}% } {\end{list}\end{raggedright}} \newenvironment{sansreflist}{% \begin{raggedright}\begin{list}{} {% \setlength{\topsep}{0pt}% \setlength{\rightmargin}{0.25in}% \setlength{\itemindent}{0pt}% \setlength{\parskip}{0pt}% \setlength{\itemsep}{0pt}% \setlength{\parsep}{2pt}% \def\makelabel##1{\upshape ##1}}% } {\end{list}\end{raggedright}} \newenvironment{specHead}[2]% {\vspace{20pt}\hrule\vspace{10pt}% \phantomsection\label{#1}\markright{#2}% \pdfbookmark[2]{#2}{#1}% \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}% }{} \def\TheFullDate{2013-01-15 (revised: 15 January 2013)} \def\TheID{\makeatother } \def\TheDate{2013-01-15} \title{Evaluating Smartphone Application Security: A Case Study on Android} \author{}\makeatletter \makeatletter \newcommand*{\cleartoleftpage}{% \clearpage \if@twoside \ifodd\c@page \hbox{}\newpage \if@twocolumn \hbox{}\newpage \fi \fi \fi } \makeatother \makeatletter \thispagestyle{empty} \markright{\@title}\markboth{\@title}{\@author} \renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@ \belowdisplayskip \abovedisplayskip \abovedisplayshortskip \z@ plus2\p@ \belowdisplayshortskip 4\p@ plus2\p@ minus2\p@ \def\@listi{\leftmargin\leftmargini \topsep 2\p@ plus1\p@ minus1\p@ \parsep 2\p@ plus\p@ minus\p@ \itemsep 1pt} } \makeatother \fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm} \fancyhf{} \setlength{\headheight}{14pt} \fancyhead[LE]{\bfseries\leftmark} \fancyhead[RO]{\bfseries\rightmark} \fancyfoot[RO]{} \fancyfoot[CO]{\thepage} \fancyfoot[LO]{\TheID} \fancyfoot[LE]{} \fancyfoot[CE]{\thepage} \fancyfoot[RE]{\TheID} \hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true} \fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}} \date{} \usepackage{authblk} \providecommand{\keywords}[1] { \footnotesize \textbf{\textit{Index terms---}} #1 } \usepackage{graphicx,xcolor} \definecolor{GJBlue}{HTML}{273B81} \definecolor{GJLightBlue}{HTML}{0A9DD9} \definecolor{GJMediumGrey}{HTML}{6D6E70} \definecolor{GJLightGrey}{HTML}{929497} \renewenvironment{abstract}{% \setlength{\parindent}{0pt}\raggedright \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}} \vskip16pt \textcolor{GJBlue}{\large\bfseries\abstractname\space} }{% \vskip8pt \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}} \vskip16pt } \usepackage[absolute,overlay]{textpos} \makeatother \usepackage{lineno} \linenumbers \begin{document} \author[1]{Muneer Ahmad Dar} \author[2]{Javaid Parvez} \affil[1]{ National Institute of Electronics and Information Technology (NIELIT) Srinagar/Jammu} \renewcommand\Authands{ and } \date{\small \em Received: 8 December 2012 Accepted: 2 January 2013 Published: 15 January 2013} \maketitle \begin{abstract} Currently, smart phones are becoming indispensable for meeting the social expectation ofalways staying connected and the need for an increase inproductivity are the reasons for the increase in smartphone usage. One of the leaders of the smart phone evolution is Google?s Android operating system. It ishighly likely that Android is going to be installed in manymillions of cell phones during the near future. With thepopularity of Android smart phones everyone finds it convenient to make transactions through these smartphones because of the openness of Android applications. The malware attacks are also significant. Androidsecurity is complex and we evaluate an applicationdevelopment environment which is susceptible tomalware attacks. This paper evaluates Android securitywith the purpose of identifying a secure applicationdevelopment environment for performing securetransactions on Android-based smart phones. \end{abstract} \keywords{smartphone, android, malware, spam, vulnerabilities, attacks, mobility, API.} \begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) \textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark} \end{textblock*} \begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) \textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}} \end{textblock*} \let\tabcellsep& \section[{Introduction}]{Introduction}\par martphones have become indispensable part of our daily lives in recent years, since they are involved in keeping in touch with friends and family, doing business, accessing the internet and other activities. Andy Rubin, Google's director of mobile platforms, has commented: "There should be nothing that users can access on their desktop that they can't 0access on their cell phone" \hyperref[b0]{[1]}. Growth in smartphone sales is depicted in the figure below. It indicates that smart phone sales are continuously on rise and more and more people are becoming dependent on these devices. As these Smartphones are going to outnumber the world's total population in 2014, securing these devices has assumed paramount importance. Owners use their smart phones to perform tasks ranging from everyday communication with friends and family to the management of banking accounts and accessing sensitive Work related data. These factors, combined with limitations in administrative device control through owners and security critical applications like the banking transactions, make Android-based Smart phones a very attractive target for hackers, attackers and malware authors with almost any kind of motivation.\par In this paper we analyze the security architecture of Smartphones in section II and identify the security loopholes of the current framework in section III. We then have a detailed description of the existing work done by the researchers in section IV. Finally we draw our conclusions in section V. \section[{II. Security Framework of Smartphone}]{II. Security Framework of Smartphone}\par A Smartphone is an intricate combination of a mobile phone and a computing platform, with highspeed connectivity and powerful computing ability. Therefore, the Smartphone has necessary components of the computing platform: an operating system, applications and hardware. Furthermore, as a personal communication device, the Smartphone also often has multiple communication capabilities and ability to store large amounts of sensitive user data \hyperref[b1]{[2]}. indispensable for meeting the social expectation of always staying connected and the need for an increase in productivity are the reasons for the increase in smart phone usage. One of the leaders of the smart phone evolution is Google's Android operating system. It is highly likely that Android is going to be installed in many millions of cell phones during the near future. With the popularity of Android smart phones everyone finds it convenient to make transactions through these smart phones because of the openness of Android applications. The malware attacks are also significant. Android security is complex and we evaluate an application development environment which is susceptible to malware attacks. This paper evaluates Android security with the purpose of identifying a secure application development environment for performing secure transactions on Android-based smart phones.\par Android is a Linux-based platform programmed with Java and enhanced with its own security mechanisms tuned for a mobile environment. Android combines OS features like efficient shared memory, preemptive multi-tasking, Unix user identifiers (UIDs) and file permissions with the type-safe Java language and its familiar class library. The resulting security model is much more like a multi-user server than the sandbox found on the J2ME or Blackberry platforms. Unlike a desktop computer environment where a user's applications all run under the same UID, Android applications are individually siloed from each other.\par Android applications run in separate processes under distinct UIDs each with distinct permissions. Programs can typically neither read nor write each other's data or code, and sharing data between applications must be done explicitly. The Android GUI environment has some novel security features that help support this isolation \hyperref[b9]{[10]}. \section[{III.}]{III.} \section[{Limitations of Current Security Model}]{Limitations of Current Security Model}\par Android is based on open source framework and it comes with a pre-built suite of applications like dialer, address book, browser, etc. Developers can code their own applications and publish to the Android market after a self-signing phase that does not require any certifying authority i.e., developer can use selfcreated certificates to sign their applications. This helps in providing a wide range of applications and services to the device-holders. Since there is no support for root Certification Authorities in Android (Android is based on open source framework, while introducing root certification mechanisms contradicts the openness of Android) it is very difficult to scrutinize and/or block applications coming from unreliable sources. There is a higher possibility that an average Android user will easily be tricked by unsafe applications and will avoid the warning messages at time of installation. The permission model is the core mechanism for securing access to various resources in Android. Although the permissions are categorized to different protection levels such as Normal, Dangerous, Signature and Signature-Or-System but the assignment of these protection levels is left to the developer's will and own understanding. This leads to a number of vulnerabilities in the permission model. When an application is installed on Android, the Android framework prompts the user with a list of required permissions, the user may grant all of the permissions in order to install the application or deny the permissions to decline the installation. Practically, there are a number of issues in such a model: 1) The user must grant all of the required permissions in order to install the application, 2) once the permissions are granted; there is no mechanism for further restricting an application to use the granted permissions, 3) there is no way of restricting access to the resources based on dynamic constraints as the permission model is based on install-time check only, 4) granted permissions can only be revoked by uninstalling the application. There are four security loopholes that endanger the information stored in a Smartphone \hyperref[b17]{[18]}:\par ? The capability to sniff the data transmitted by any network where the device is connected. ? The lack of strong security control of user´s private information that permits malware to access the information stored in the device. Year These are the most common security problems in the smart phones. Powerful hardware and advanced operating system with flexible APIs \hyperref[b21]{[23]}, \hyperref[b22]{[24]} not only increase capability and functionality of smartphones but also present rising security threats to smartphones. Other features of smartphones also exacerbate threats to smartphones: higher bandwidth not only accelerates the Internet access, but also speeds up virus transmission; multiple peripheral interfaces not only increase Smartphone connectivity, but also provide much more avenues for virus injection. Compared with personal computers, smartphones also have always-on \& always-connected mobility and are therefore hard to reinstall. Therefore, disabling or making smartphones nonfunctional as a result of attacks will have much greater impact and prove more costly than in the case of personal computers. A threat means potential violation of Smartphone security, which can be clustered into two categories according to its cause: vulnerabilities \hyperref[b4]{[5]} and attacks \hyperref[b5]{[6]}. Vulnerabilities mean weakness of smartphones and inabilities to withstand hostile environment effects. Attacks are any attempts to intentional destroy unauthorized use, maliciously modify or illegally obtain Smartphone assets. Generally, attackers bypass or exploit deficiencies of Smartphone security mechanisms to initiate negative activities. That is, vulnerabilities are the internal attributes of smartphones, while attacks are the outside offensive activities to smartphones. As a matter of fact, most attacks exploit vulnerabilities of smartphones. \section[{a) Vulnerabilities}]{a) Vulnerabilities}\par As comparatively complicated devices, smartphones inevitably have numerous vulnerabilities, which can lead to insecurity or be exploited by malicious persons to initiate attacks. Smartphone vulnerabilities typically include system defects, insufficient management of APIs, deficiency of user awareness and unsecure wireless channels, shown in Fig. {\ref 4}.\par i. Deficiency of User Awareness Some applications are installed without user confirmation or with limited information. Based on these situations, attackers can give deceptive information for applications infected by malicious codes. Users may install them without accurate or sufficient information. In addition, some sensitive operations, such as sending and receiving messages, deleting important files, activating wireless interfaces, can also be executed secretly. Consequently, Smartphone users cannot know about occurrences of malicious security-sensitive operations until the negative effects start appearing.\par ii. System Defects It is nearly impossible to detect and rectify all defects in Smartphone hardware and software. Some immediately non-conforming defects can be observed soon, but most other defects cannot be found for a certain time. Even if they are discovered, these defects, especially hardware defects are hard to be remedied. As a result, system defects can cause Smartphone abnormalities and malfunctions. Furthermore, malicious persons generally take advantage of existing system defects to initiate attacks and compromise Smartphone systems. \section[{iii. Unsecure Wireless Channels}]{iii. Unsecure Wireless Channels}\par In wireless environments including cellular networks, user data and control signals transmitted between smartphones and network devices can be easily captured. If these data and signals are compromised, the transmitted information will be exposed. \section[{iv. Insufficient API Management}]{iv. Insufficient API Management}\par The most distinct characteristic of smartphones is flexible APIs, which are used for application development \hyperref[b20]{[22]} and installation. However, insufficient API management is also the main reason for malicious codes. Generally, Smartphone APIs are clustered into open APIs for third-party application developments and controlled APIs for remote maintenance. Controlled APIs have higher privileges, which can be used for remote system update, file erasure and information retrieval. If malicious persons obtain controlled APIs, they can initiate negative activities such as backdoor attacks. Even some open APIs may have inappropriate privileges so that they might be utilized to acquire certain privileges and initiate attacks. \section[{b) Attacks}]{b) Attacks}\par It is well known that smartphones have much valuable user data, especially financial data and identification information. Driven by economic benefits, many hackers have focused on smartphones and initiated multifarious attacks, shown in Fig. \hyperref[fig_2]{3}: Due to portability and mobility, smartphones are likely to be lost or stolen. Then, sensitive information stored in smartphones including address book, communication records, usernames and passwords, etc. can be accessed directly. Incorrect disposals of old and damaged devices will cause similar problems.?\par ii. Spam Spam is generally sent in SMS, MMS and email. VoIP and Instant Messaging (IM) have also become common ways for spamming. Spam may generally cause virus infection, economic loss, or worse influences.\par iii. Malware Malware \hyperref[b3]{[4]}, \hyperref[b4]{[5]} is becoming the main threat to smartphones. Flexible APIs not only enrich application development, but also facilitate malware development. Meanwhile, powerful connectivity also aggravates malware spreading. In addition, smartphones can be infected by malicious codes during synchronization with personal computers or virus-infected storage media. Furthermore, malware can also be spread in a variety of ways, including Internet downloading, messaging services and Bluetooth communications. In reality, users are not always aware of downloaded applications' functions. Even if applications have acquired explicit user consent, users may be unaware that the applications are executing malicious code. \section[{iv. Backdoor}]{iv. Backdoor}\par Backdoor attacks mainly result from system bugs and disclosure of controlled APIs. Some operating systems have security loopholes such as insufficient authentication and inappropriate privileges. Based on these vulnerabilities, attackers can bypass security policies to access smartphones. In addition, if attackers have controlled APIs, they can also access smartphones like legitimate entities. \section[{v. Peripheral Interfaces Attacks}]{v. Peripheral Interfaces Attacks}\par Smartphones usually have many peripheral interfaces, such as Wi-Fi, Bluetooth, USB, etc. While peripheral interfaces can increase smartphones communication capabilities, unfortunately, they also become a popular steppingstone for outside attacks. \section[{vi. Radio and Wireless Attacks}]{vi. Radio and Wireless Attacks}\par Due to the openness of wireless communications, attackers can easily initiate wireless attacks, which can be clustered into two categories: active attacks (spoofing, corruption, blocking, modifying, etc.) and passive attacks (sniffing, eavesdropping, etc.). Generally, passive attacks are used as a prelude to active attacks, by acquiring necessary information such as addresses and to identify vulnerabilities of potential targets. \section[{IV.}]{IV.} \section[{Related Research Work a) Kirin}]{Related Research Work a) Kirin}\par Enck, et al. \hyperref[b20]{[22]} have proposed a framework known as Kirin -install-time certification mechanismthat allows the mobile device to enforce a list of predefined security requirements prior to installation process of an application. During installation of an application the Android framework informs the user regarding the resources that can be accessed by the application but it cannot reflect the possibility of using different combinations of permission in a malicious manner. The Kirin framework is contacted when installation process for an application package is initiated. Kirin utilizes the application's manifest file where all the required permissions are listed and uses the action string along with the permissions to construct a set of Prolog facts Although Kirin is one of the first security policy extension for Android platform, it suffers from the common limitation of Smartphone security systems i.e. the policy expressibility is not sufficient enough to express certain policies. Furthermore, the policies used by the Kirin framework are based on blacklisting and must be defined upfront. This means that certain set of permissions would be considered as dangerous by the policy writer but any combination of these permissions that is not explicitly termed as dangerous is treated safe by default. \section[{b) SCanDroid}]{b) SCanDroid}\par Fuchs, et al. \hyperref[b21]{[23]} proposed SCanDroid framework for Android to perform information flow analysis on applications in order to understand the flow of information from one component to another component. Consider a case where an application request permission to access multiple data stores i.e., public data store and private data store. The application requires permission for reading the data from the private store and writing data to the public store. SCanDriod analyzes the information flow of the application and report whether the application will transfer the information in the private store to the public store or not. However, SCanDroid also suffers from the same limitation of security policy expressibility. In order to policy writers must define certain constraints prior to executing the policy. Similarly, if an information flow is not explicitly added to the set of constraints the framework will consider it to be safe. \section[{c) Saint}]{c) Saint}\par Ongtang, et al. \hyperref[b12]{[13]} proposed Saint -a framework that provides security policy constraints in a more expressive manner by defining install-time permission granting policies and runtime policies for inter-component communication. The framework places a number of dependency constraints on the permissions requested by the applications. These constraints may include the name of application, versions, signatures and set of other permissions. The effectiveness of Saint is based on its runtime policies for which reference monitors are used in the Android framework. The runtime policies are used to specify constraints for both the caller and callee applications. These constraints include permissions, configurations, signatures and/or the context in which the application is used e.g., time, location etc. The framework enables an application to protect and restrict its interface from being used by another application. However, this framework is not usercentric as it gives the option of policy specification to the application developers and not to the user. In our opinion, as the owner of the device, the decision to grant or deny access to the device resources should remain with the user and not with the application developers. \section[{d) Apex}]{d) Apex}\par Apex \hyperref[b22]{[24]} is an extension to the Android permission model that is more user-centric in allowing applications to access the device resources. Apex allows users to specify detailed runtime constraints to restrict the use of sensitive resources by applications. It is designed to overcome the limitation that the Android framework grants all the permissions to an application, which the application requests at install time. At install time the only way to deny the permissions requested by an application is to abort the installation. In the same way, the only way of revoking permissions once they are granted to an application is to uninstall the application. Contrary to this, Apex enables users to define conditions that must be fulfilled by an application in order to grant requested permissions to it. This means that it allows a subset of the requested permissions to be granted to the application at install-time. This way, user can start using the application with a limited number of permissions. The user may extend the granted permissions at a later stage. However, there are some limitations in the Apex framework. In the current Android architecture, the application developers assume that all the permissions that their application requests will be present in the manifest file. The developers often do not handle the unexpected security exceptions that are thrown when an application requests to access some resource(s) but the application does not have the required permissions to access it. If these exceptions are not properly handled -as may be the case in general -then we assume that most of the Android applications will not catch the exceptions and the exception will reach to the end of the call stack resulting in the termination of the thread. \section[{e) Porscha}]{e) Porscha}\par Ongtang, et al. \hyperref[b23]{[25]} have proposed Porscha -a framework that enforces Digital Rights Management (DRM) policies -designed specifically for SMS, MMS and Email services allowing the content owners to restrict access to their content by specifying access control policies based on certain conditions like location and number of times to view a particular content etc. However, it is designed to facilitate different enterprises and government organizations with strictly controlled access policies. f) CRePE g) XManDroid Bugiel, et al. \hyperref[b25]{[27]} have proposed XManDroidextending monitoring on Android -to alleviate the problem of application-level privilege escalation attacks on Android. It analyzes the intercomponent communication mechanism among different applications in Android to ensure that these communication links comply with the predefined security policy. One of the major obstacles for the XManDroid is to define and maintain useful policies as well as policy exceptions. Some similar countermeasures against such malicious applications have already been proposed. Enck et al proposed "TaintDroid", a system-wide dynamic taint tracking system, in which multiple sources of sensitive data are tainted and the taint is used as a marker capable of real-time tracking of sensitive data \hyperref[b4]{[5]}. They implemented "TaintDroid" and the evaluation results suggest that the overhead time for taint tracking is about 29\% at most.\par Takemori et al proposed the "white-list" measure which allows only secure and necessary Conti, et al. \hyperref[b24]{[26]} have proposed CRePE -a framework that enforces context-related fine-grained access control policies. It allows users to define policies that enable/ disable certain functionalities such as GPS, read SMS or Bluetooth discovery, based on the context of the device (e.g., location, noise, temperature, time, and nearby devices etc.). Furthermore, the context may also be defined by a trusted third party in scenarios where enterprise wide policy need to be deployed for all employees having Android smartphones. However, this framework only focuses on enabling/disabling of certain features of applications and cannot cope with the vulnerabilities that are formed by the permission usage across different applications.\par applications are shown. In order to prevent malicious applications from intruding, any unlisted application will be immediately deleted even if it is installed. Kawabata et al pointed out the risk that attackers could execute Java method by using JavaScript downloaded from the server and it may in turn cause malicious behavior \hyperref[b6]{[7]}. To counter this, they proposed to conduct a static analysis for Android applications with JavaScript to ascertain its threat level.\par Chin et al mentioned vulnerability of interapplication Communication in Android \hyperref[b7]{[8]}. They pointed out that some malicious components can eavesdrop and tamper with the "Intent" while sending and receiving a message between applications. They surveyed 100 applications and revealed that they undoubtedly have such vulnerabilities. To realize this security goal without adding unnecessary burden to developers, Harunobu Agematsu proposed to prepare a dedicated API called "ADMS API" and to create "Knowledge Database" which security manager could use to judge malicious behavior \hyperref[b3]{[4]}.\par The United States National Security Agency has recently announced the commencement of the SEAndroid (Security Enhanced Android) project as an addition to the Android kernel \hyperref[b19]{[20]}. Similar to the well known and widely deployed SELinux Linux kernel patch, the SEAndroid project aims to establish a fine grained Mandatory Access Control model. It is further adjusted and extended to meet the requirements which arise on the Android platform, e.g., to secure inter process communication {\ref [21]}. Once integrated into Android, SEAndroid may indeed prevent some of the attacks presented. SEAndroid is still in a very early development stage. It is unknown when or if SEAndroid will be integrated into the default code base of the operating system.\par V. \section[{Summary and Conclusion}]{Summary and Conclusion}\par We have elaborated the limitations in the current Android security model in detail and in previous section we have presented the existing research proposals for improving overall Android security model. In this section we detail some of the security requirements that need to be taken into consideration while designing security mechanisms for smartphones in general and Android in particular. In order to alleviate the limitations and further strengthen the Android security model, one of the most important security concerns for the current smartphones is the lack of a model that allow users to specify, at a fine-grained level, which of the phone's resources should be accessible to third party applications. To design policies that are fine-grained in expressibility and are targeted to cater application-specific requirements is one of the biggest challenges in proposing new security enhancements. It requires a pre-design analysis of real applications to gather a larger collection of likely scenarios where the fine-grained policies are applicable. While designing a new framework, it should be capable of specifying a set of detailed runtime constraints to restrict the use of sensitive resources by applications. For example, the user may want to restrict certain applications to access a particular resource in a particular context (e.g., time, location, and maximum number of usage etc.) without uninstalling the application. This could be achieved by designing a framework that allows granting selective permissions at install time as well as monitor the use of these permissions at runtime by employing certain usage control mechanisms. The growing number of malware vulnerabilities has augmented serious concerns over security models for the smartphones. The recent attacks discussed in \hyperref[b16]{[17]}, \hyperref[b18]{[19]}, \hyperref[b19]{[20]} have shown how easily some of the Android security features can be overturned by the malware developers. While designing new framework or proposing enhancement to the Android security model, we should consider that the model should not be by-passable by the sophisticated malware and/or the applications installed on the device as well as new applications. The framework should be designed in such a manner that it can validate that the system is not tampered with. It should be able to prevent information leakage from the device in scenarios where a legitimate application is replaced with a similar one containing Trojans that spy on user's sensitive information such as location, or, logs the phone calls and transfers that information to a remote server. \begin{figure}[htbp] \noindent\textbf{1}\includegraphics[]{image-2.png} \caption{\label{fig_0}Figure 1 :}\end{figure} \begin{figure}[htbp] \noindent\textbf{2}\includegraphics[]{image-3.png} \caption{\label{fig_1}Figure 2 :E}\end{figure} \begin{figure}[htbp] \noindent\textbf{3}\includegraphics[]{image-4.png} \caption{\label{fig_2}Figure 3 :}\end{figure} \begin{figure}[htbp] \noindent\textbf{}\includegraphics[]{image-5.png} \caption{\label{fig_4}}\end{figure} \begin{figure}[htbp] \noindent\textbf{5}\includegraphics[]{image-6.png} \caption{\label{fig_5}Figure 5 :}\end{figure} \backmatter \begin{bibitemlist}{1} \bibitem[ Google bets on Android future]{b0}\label{b0} \textit{}, \url{http://news.bbc.co.uk/2/hi/technology/7266201.stm} \textit{Google bets on Android future} \bibitem[Selinux Project and Seandroid (2012)]{b14}\label{b14} \textit{}, Selinux Project , Seandroid . August 2012. \bibitem[Agematsu et al.]{b3}\label{b3} ‘A proposal to realize the provision of secure Android applications’. Harunobu Agematsu , Junya Kani , Kohei Nasaka , Hideaki Kawabata . \textit{IEEE 2012 Sixth International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing}, \bibitem[Felt et al.]{b8}\label{b8} ‘A survey of mobile malware in the wild’. A Felt , M Finifter , E Chin , S Hanna , D Wagner . \textit{Proceedings of the 1st ACM workshopon Security and privacy in smartphones and mobile devices}, (the 1st ACM workshopon Security and privacy in smartphones and mobile devices) \bibitem[Nauman et al. ()]{b22}\label{b22} ‘Apex: Extending android permission model and enforcement with user-defined runtime constraints’. M Nauman , S Khan , X Zhang . \textit{Proceedings of the 5th ACM Symposium on Information, Computer and Communications Security}, (the 5th ACM Symposium on Information, Computer and Communications Security) 2010. ACM. p. . \bibitem[Rogers et al. ()]{b10}\label{b10} \textit{application development: Programming with the Google SDK}, R Rogers , J Lombardo , Z Mednieks , B Meike . 2009. Reilly Media, Inc. \bibitem[Conti et al. ()]{b24}\label{b24} \textit{Crepe: Context-related policy enforcement for android}, M Conti , V Nguyen , B Crispo . 2011. p. . (Information Security) \bibitem[Enck et al. ()]{b5}\label{b5} William Enck , Peter Gilbert , Byung-Gon Chun , Landon P Cox , Jaeyeon Jung , Patrick Mcdaniel , Anmol N Sheth . \textit{TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring on Symposium on Operating Systems Design and implementation (OSDI'10)}, 2010. Canada. \bibitem[Kawabata et al. ()]{b7}\label{b7} Hideaki Kawabata , Takamasa Isohara , Keisuke Takemori , Ayumu Kubota . 2011-CSEC-53-3. \textit{Threat of Script abuse Android Permissions and Static Analysis}, 2011. p. . (IPSJ SIG technical reports. in Japanese) \bibitem[Jamaluddin et al. ()]{b4}\label{b4} ‘Mobile phone vulnerabilities: a new generation of malware’. J Jamaluddin , N Zotou , P Coulton . \textit{IEEE International Symposium on}, 2004. 2004. IEEE. p. . (Consumer Electronics) \bibitem[Dagon et al. ()]{b12}\label{b12} ‘Mobile Phones as Computing Devices: the Viruses Are Coming’. C Dagon , T Martin , T Starner . \textit{IEEE Pervasive Computing} 2004. 3 (4) p. . \bibitem[Enck et al. ()]{b20}\label{b20} ‘On lightweight mobile phone application certification’. W Enck , M Ongtang , P Mcdaniel . \textit{Proceedings of the 16th ACM conference on Computer and Communications Security}, (the 16th ACM conference on Computer and Communications Security) 2009. ACM. p. . \bibitem[Pelino ()]{b16}\label{b16} M Pelino . \textit{Predictions 2010: Enterprise Mobility Accelerates Again}, (Forrester) 2009. \bibitem[Salah et al. ()]{b15}\label{b15} ‘Performance analysis of intrusion detection systems for smartphone security enhancements’. S Salah , S Abdulhak , H Sug , D Kang , H Lee . \textit{2011 International Conference on}, 2011. IEEE. p. . (in Mobile IT Convergence (ICMIC) \bibitem[Ongtang et al. ()]{b23}\label{b23} ‘Porscha: Policy oriented secure content handling in android’. M Ongtang , K Butler , P Mcdaniel . \textit{Proceedings of the 26 th Annual Computer Security Applications Conference}, (the 26 th Annual Computer Security Applications Conference) 2010. ACM. p. . \bibitem[ P ()]{b2}\label{b2} \textit{Pro Android Python with SL4A}, P . 2011. p. . (Exploring the android api) \bibitem[Takemori et al. ()]{b6}\label{b6} ‘Restriction framework for Android application -Whitelist-based installation’. Keisuke Takemori , Hideaki Kawabata , Takamasa Isohara , Ayumu Kubota , Jyunichi Ikeno . \textit{of Japan) SIG (The Special Interest Group) technical reports}, 2011. The Information Processing Society. p. . (in Japanese) \bibitem[Fuchs et al.]{b21}\label{b21} ‘Scandroid: Automated security certification of android applications’. A Fuchs , A Chaudhuri , J Foster . \url{http://www.cs.umd.edu/?avik/projects/scandroidascaa} \textit{Manuscript, Univ. of Maryland} \bibitem[Alonso Parrizas and Sans Institute (2011)]{b17}\label{b17} \textit{Securely deploying Android devices}, Angel Alonso Parrizas , Sans Institute . September 2011. \bibitem[Vargas ()]{b9}\label{b9} ‘Security Controls for Android’. Ruben Jonathan Garcia Vargas . \textit{IEEE Fourth International Conference on Computational Aspects of Social Networks} 2012. CASoN. p. 215. \bibitem[Smalley (2012)]{b19}\label{b19} \textit{SELinux Mailing List, Mailing List Archives (marc.info)}, S Smalley . l=selinux\&m=132588456202123\&w =2. 21. \url{http://selinuxproject.org/page/SEAndroid} January 2012. National Security Agency (SEAndroid Project Page) \bibitem[Goadrich and Rogers ()]{b13}\label{b13} ‘Smart smartphone development: ios versus android’. M Goadrich , M Rogers . \textit{Proceedings of the 42nd ACM technical symposium on Computer science education}, (the 42nd ACM technical symposium on Computer science education) 2011. ACM. p. . \bibitem[Guo et al. ()]{b11}\label{b11} ‘Smart-phone attacks and defenses’. C Guo , H Wang , W Zhu . \textit{HotNets III}, 2004. \bibitem[Jeter et al. (2011)]{b18}\label{b18} \textit{SmartPhone Malware: The danger and protective strategies}, L Jeter , M Mani , T Reinschmid . 2011 August.[20. 2011. (Android Security Overview) \bibitem[Luo et al.]{b1}\label{b1} ‘Towards Hierarchical Security Framework for Smartphones’. Hongwei Luo , ? ? , Guili He , ? , Xiaodong Lin , § , Xuemin( Sherman) Shen , ? . \textit{First IEEE International Conference on Communications in China: Communications Theory and Security}, CTS. p. 2012. \bibitem[Bugiel et al. (2011)]{b25}\label{b25} \textit{Xmandroid: A new android evolution to mitigate privilege escalation attacks}, S Bugiel , L Davi , A Dmitrienko , T Fischer , A Sadeghi . TR-2011-04. April. 2011. Technische Universit¨at Darmstadt (Tech. Rep) \end{bibitemlist} \end{document}