TECHNICAL SEMINAR REPORT ON

ANALYSIS AND RESEARCH OF SYSTEM SECURITY BASED ON ANDROID

BY P.SAILAJA KUMARI CSE -II 10071A05A7

ANALYSIS AND RESEARCH OF SYSTEM SECURITY BASED ON ANDROID

A technical seminar report submitted in partial requirements for the award of the degree of BACHELOR OF TECHNOLOGY IN COMPUTER SCIENCE AND ENGINEERING Submitted by

Roll number: 10071A05A7 CSE Department

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING VNR VIGNANA JYOTHI INSTITUTE OF ENGINEERING AND TECHNOLOGY (Affiliated to JNTU Hyderabad &Recognized by AICTE) Bachupally , Hyderabad. March,2014

VALLURUPALLI NAGESHWARA RAO VIGNANA JYOTHI INSTITUTE OF ENGINEERING AND TECHNOLOGY (AFFILIATED TO JNTU HYDERABAD & RECOGNISED BY AICTE) BACHUPALLY,(VIA) KUKATPALLY, HYDERABAD-500 072.

CERTIFICATE
This is to certify that the seminar entitled ANALYSIS AND RESEARCH OF SYSTEM SECURITY BASED ON ANDROID is a bonafide work done and submitted by P.SAILAJA KUMARI under the guidance of Ms. P. Radhika for the partial fulfillment of the requirements for the award of the B.Tech (IV year, II semester) Degree in Computer Science and Engineering, VNRVJIET, Hyderabad, during the academic year 2013-2014 and has not been submitted to any other university for the award of any degree/diploma.

Ms.P.Radhika Seminar In charge Assistant professor CSE Department

DR.B.Raveendra Babu Professor and Head CSE Department

ACKNOWLEDGEMENT

Firstly I would like to express my immense gratitude and heartfelt thanks to our institute VNR VIGNANA JYOTHI INSTITUTE OF ENGINEERING AND TECHNOLOGY, which created a great platform to attain profound technical skills in Computer Science, thereby fulfilling my most cherished goal. I am thankful to our Head of the Department Dr.B. Raveendra Babu for his valuable advice and support. I extend heartfelt thanks to our seminar in charge Ms.P. Radhika, Assistant Professor, CSE Department for her excellent guidance and supervision. Last but not the least my appreciation goes to all the teaching and the non-teaching staff of Computer Science and Engineering Department and to my parents for their moral support and cooperation. I would also like to thank my friends, whose direct and indirect help has enabled me to carry out this work successfully.

CONTENTS

ABSTRACT INTRODUCTION ANDROID ARCHITECTURE FEATURES OF ANDROID INTRODUCTION TO SECURITY ASPECTS RELATED WORK APPICATIONS CONCLUSION AND FUTURE WORK REFERENCES

ANALYSIS AND RESEARCH OF SYSTEM SECURITY BASED ON ANDROID Abstract:

The market for smart phones has been booming in the past few years. There are now over 400,000 applications on the Android market. Over 10 billion Android applications have been downloaded from the Android market. Due to the Android popularity, there are now a large number of malicious vendors targeting the platform. Many honest end users are being successfully hacked on a regular basis. In this work, a cloud based reputation security model has been proposed as a solution which greatly mitigates the malicious attacks targeting the Android market. Our security solution takes advantage of the fact that each application in the android platform is assigned a unique user id (UID). Our solution stores the reputation of Android applications in an anti-malware providers cloud (AM Cloud). The experimental results witness that the proposed model could well identify the reputation index of a given application and hence its potential of being risky or not.

Introduction
1.1 ANDROID : Android is an operating system based on the Linux kernel, and designed primarily for touch screen mobile devices such as smartphones and tablet computers. Android is a smart mobile terminal operating platform core on Linux. But due to its open-source software and programmable framework character, it leads the Android system vulnerable to get virus attacks. Initially developed by Android, Inc., which Google backed financially and later bought in 2005, Android was unveiled in 2007 along with the founding of the Open Handset Alliancea consortium of hardware, software, and telecommunication companies devoted to advancing open standards for mobile devices. The first publicly available smartphone running Android, the HTC Dream, was released on October 22, 2008. 1.2 ANDROID PLATFORM ARCHITECTURE: Android has built in tools. Android platform is composed of linux kernel, system libraries, android runtime,application framework.

1.2.1 APPLICATIONS LEVEL : 1.2.1.1 Linux Kernel The basic layer is the LINUX KERNEL. The whole Android OS is built on top of the Linux 2.6 Kernel with some further architectural changes made by Google. It is this Linux that interacts with the hardware and contains all the essential hardware drivers. Drivers are programs that control and communicate with the hardware. For example, consider the Bluetooth function. All devices has a Bluetooth hardware in it. Therefore the kernel must include a Bluetooth driver to communicate with the Bluetooth hardware. The Linux kernel also acts as an abstraction layer between the hardware and other software layers. Android uses the Linux for all its core functionality such as Memory management,PROCESS MANAGEMENT, networking, security settings etc. As the Android is built on a most popular and proven foundation, it made the porting of Android to variety of hardware, a relatively painless task.

1.2.1.2 Libraries
The next layer is the Androids native libraries. It is this layer that enables the device to handle different types of data. These libraries are written in c or c++ language and are specific for a particular hardware. Some of the important native libraries include the following: Surface manager: It is used for compositing window manager with off-screen buffering. Off-screen buffering means you cant directly draw into the screen, but your drawings go to the off-screen buffer. There it is combined with other drawings and form the final screen the user will see. This off screen buffer is the reason behind the transparency of windows. Media framework: Media framework provides different media codecs allowing the recording and playbackof different media format.

SQLite: SQLite is the database engine used in android for data purposes. WebKit: It is the browser engine used to display HTML content OpenGL: Used to render 2D or 3D graphics content to the screen

1.2.1.3 ANDROID RUNTIME

Android Runtime consists of Dalvik Virtual Machines and Core Java libraries.

1.2.1.3.1 Dalvik Virtual Machine It is a type of JVM used in android devices to run apps and is optimized for low processing power and low memory environments. Unlike the JVM, the Dalvik Virtual Machine doesnt run .class files, instead it runs .dex files. .dex files are built from .class file at the time of compilation and provideshifger efficiency in low resource environments. The Dalvik VM allows multiple instance of Virtual machine to be created simultaneously providing security, isolation, memory management and threading support. It is developed by Dan Bornstein of Google.

1.2.1.3.2 Core java Libraries These are different from Java SE and Java ME libraries. However these libraries provides most of the functionalities defined in the Java SE libraries. Application Framework These are the blocks that our applications directly interacts with. These programs manage the basic functions of phone like resource management, voice call management etc. As a developer, you just consider these are some basic tools with which we are building our applications. Important blocks of Application framework are: Activity Manager: Manages the activity life cycle of applications Content Providers: Manage the data sharing between applications Telephony Manager: Manages all voice calls. We use telephony manager if we want to access voice calls in our application. Location Manager: Location management, using GPS or cell tower Resource Manager: Manage the various types of resources we use in our Application Applications Applications are the top layer in the Android architecture and this is where our applications are gonna fit. Several standard applications comes pre-installed with every device, such as:

SMS client app Dialer Web browser Contact manager

As a developer we are able to write an app which replace any existing system app. That is, you are not limited in accessing any particular feature. You are practically limitless and can whatever you want to do with the android (as long as the users of your app permits it). Thus Android is opening endless opportunities to the developer.

Some of the phones and tablets based on android

HTC G1 DROID,TATTOO

Motorola Droid

Sony Ericson

Samsung Galaxy

1.3 IMPORTANT FEATURES:

1) Application framework 2) DALVIK Virtual machine

3) Integrated browser 4) Optimized graphics 5) SQLite 6) Media support 7) GSM Telephony 8) BLUETOOTH,EDGE,3G WIFI 9) CAMERA,GPS, Compass, Accelerometer

1.4 INTRODUCTION TO SECURITY ASPECTS:

Android is a Linux-based open-source operating system, with a layered structure of services including core native libraries and application frameworks. Android isolates different applications and provides safety through OS primitives and environmental features such as type safety. At the application level, each software package is partially sandboxed by the kernel, making Android a widely deployed system that employs privilege separation as a matter of course. More specifically, by default, each application is not allowed to read, update or delete another application's files. On the other hand, the Android user has the ability to allow or deny one application to communicate with other applications via inter process communication (IPC). If the user grants this permission, malware applications may be able to compromise the Android system. If the application requests this permission, and the user denies this permission, the possibly valid application will not install. Access control lists (ACLs) and permission-based security models allow administrators and operating systems to restrict actions on specic resources. In practice, designing and conguring ACLs (particularly those with a large number of conguration parameters) is a complicated task. More specically, reaching a balance between the detailed expressiveness of permissions and the usability of the system is not trivial, especially when a system will be used by novices and experts alike. One of the main problems with ACLs and permission models in general is that they are typically not designed by the users who will ultimately use the system, but rather by developersexperts to blindly attempt to make them better without knowing where to start. While there are many widely deployed systems which use permissions, we focus on the empirical analysis of the permission model included in Android OS. Android is a newcomer to the smart phone industry and in just a few years of existence has managed to obtain signicant media attention, market share, and developer base. Android uses ACLs extensively to mediate inter-process communication (IPC) and to control access to special functionality on the device (e.g., GPS receiver, text messages, vibrator, etc.). Android developers must request permission to use these special features in a standard format which is parsed at install time. The OS is then responsible for allowing or denying use of specic resources at run time. The permission model used in Android has many advantages and can be effective in preventing malware while also informing users what applications are capable of doing once installed.

The main objectives of our empirical analysis are: To investigate how the permission-based system in Android is used in practice (e.g., whether the design expectations meet the real-world usage characteristics and To identify the strengths and limitations of the current implementation. We believe such analysis can reveal interesting usage patterns, particularly when the permission-based system is being used by a wide spectrum of users with varying degrees of expertise. The Android Operating System (OS) provides a rich set of IPC capabilities. Unfortunately there are many security issues in the OS. Since the Android phones are limited in processing power, memory and speed, there are some additional constraints in running strong security defenses such as live antivirus and firewall programs. Privacy issues are common in all OSes. However with Android's Global Positioning System (GPS) and Locations Based Services (LBS), hackers may be able to track the movements and location of the Android phone owner. Microsoft Windows applications do not have their own UID. When a Microsoft Windows application runs, it uses the security impersonation feature, which allows the application to run, in the security context of the user who runs the application. When the Android application runs, they run in the security context of their own UID. Therefore, with Android, we can have more control over the security of the application. I.e., the Android applications do not, by default, have the security permissions of the phone user. However, we are missing some tools to fine tune the control the applications security, based on these unique application UID's. We have the following different types of application components, in the Android OS: Activities, Services, Content providers and Broadcast receivers. A service in Android runs in the background. Other components, from various different applications can interact with the service and exchange data. When a service is installed, the developer has the option to make its service available to the applications. To do this, the installation manifest file must include a permission statement and give a name to the shared service (for example SuperService). If a user installs an application, which requires the use of SuperService, that application, must request access to SuperService via its installation manifest file. There are three problems with the above permissions strategy: The installation options are either take it or leave it. If the user wants to prevent an application, from accessing just one service, the user is must not install the application. It would be better if the user could install the application, but just prevent the application from accessing that one service. The permission to use SuperService, is only checked at installation time. To make any permission changes (revoke or grant), requires the user to completely uninstall and reinstall the application, which uses SuperService. 3. It is the end user who must make the decision, if a newly installed application should be allowed to use the SuperService. Users are not in a good position to know which combinations of applications services are used by malware. The purpose of this paper is to present a solution to identify the reputation of applications. These reputations can be stored in the AM Cloud which will mitigate all three of these Android

permission security limitations. In peer to peer network environments, the trust mechanism, integrality grade of force access control can be improved by calculating the reputation grade which the application have developed. Through the trust mechanism, users can get the historical experiences of target nodes, thus the network resource security and the integrity of download resources (including applications) will be ensured 1.4.1 ANDROID SECURITY SYSTEM: In the default settings,no application has permission to perform any operations that would adversely impact other applications, the OS or the user. Android security mechanism is mainly reflected in 2 aspects. Android system security and data security.

1.4.2 ANDROID SYSTEM SECURITY PROTECTION: Android system safety inherited the design of Linux in the design ideology. In practice, each Android application runs in its own process. In the OS, each application runs with a unique system identity. Most of the security functions are provided by the permission mechanism. Permission can be restricted to particular specific process operations.

1.4.3 ANDROID DATA SECURITY PROTECTION Android is privilege separated. security mainly relies on software signature mechanism It uses AndroidManifest.xml file When specified software services are called,the system first checks this file. To make use of protected features of the device, one must include in AndroidManifest.xml,one or more <uses-permission> tags declaring the permissions. <manifest> <uses-permission android:name=android.permission.READ/> <uses-permission android:name=android.permission.RECEIVE/>

<uses-permission android:name=android.permission.SEND/> </manifest>

1.5 RELATED WORK

Shabtai et al. provided a security assessment of the Android framework after identifying high-risk threats to the framework. An Android Application Sandbox (AASandbox) being able to perform dynamic analysis on Android programs. Also, it automatically detects suspicious applications. Dynamic analysis executes the application in a fully isolated environment, which intervenes and logs low-level interactions with the system for further analysis. Ongtang et al. pointed out that smartphone security is not yet fully developed. They considered security requirements of smartphone applications and augmented the existing Android OS with a framework to meet them. Having presented a modified infrastructure, called Secure Application Interaction(Saint), governing install-time permission assignment and their run-time use as dictated by application provider policy, the authors provided an in-depth description of the semantics of application policy. Shin et al.specified the permission mechanism for the Android OS representing it in terms of a state machine. Security needs were identified and the authors showed that the specified system is secure over the specified states and transitions. Teufl et al. describe a method for extracting knowledge about security permissions for apps and their relations, description terms, and download counts. Based on their earlier work on Activation Patterns the paper highlights its benefits and provides a number of examples. Orthacker et al. presented a method circumventing the Android permission system by spreading the permissions over two or more apps that communicate with each other viaarbitrary communication channels. Three apps were demonstrated as well as a possible detection method.Burns created a guide intended for developers of Android applications. Burns takes the developer through the security model of Android, including many of the key security mechanisms and how they can be used safely. We take the next logical step and propose a solution to some of the Android security model weaknesses. Burguera et al. suggested earlier approaches for dynamic analysis of application behavior as a means for detecting malware in the Android platform An application can share a service and specify which permissions the consumer needs. During install, the end user can allow these consumers to access the service. Theapplication service can further restrict access, via any authentication methods. To the best of our knowledge, there are currently no published results to further restrict permissions. Neither are there published solutions to check whether a given application is malicious or not based on its reputation record on the fly. 1.5.1 PROPOSED SOLUTION Reputation based security trust model As part of a solution to the above identified pitfalls in the android security model, we propose a reputation based security trust model to evaluate and

validate the applications prior to installation. We have also analyzed the consequences of a malicious application that has managed to get installed with the full consent of the end user. The Internet is full of genuine and malicious applications.

An Android mobile owner can download different applications with varying reputation ratings. In this model, it is proposed that after downloading and before installing, the mobile device asks the AM Cloud for the reputation of the downloaded application.

Figure 1.Schematic overview of the proposed protocol.

Based on the downloaded applications behavior and reputation index the downloaded application can beclassified in any of the following three ways.

1. The application has built a good reputation and there is likely no harm installing it on the clients device. Good reputation will be set after some threshold of positive feedback from those clients that have downloaded and automatically reported. 2. The application has not yet developed any good or bad reputation in the AM Cloud. In general, if an application has not developed a good reputation, we should be extremely cautious with such an unknown application. In this scenario, the anti-malware provider may wish to recommend that the user does not install the application or that the user installs the application in a sandbox.

Example :Lets assume that the user, Fred, installed the application anyway, in a sandbox. Our solution proposes that the anti-malware provider keep track of which unknown applications were installed on which users Android devices. As time goes on, more information will be received from thousands of other user, who have installed the identical application. As the unknown application builds a reputation (good or bad), the anti-malware provider can inform all users, including Fred, that the unknown application has now been reclassified (as good or perhaps bad)

. 3. The application has a bad reputation. In this case, the user is warned about the applications bad reputation. All Android applications and updates must include a digital signature. However vendors are allowed to use the same certificate in different applications. Also the application updates can be signed with the same certificate. Therefore a certificate does not uniquely identify any given application. Our solution requires a unique identifier for each application from a given vendor (even if they use the same certificate). Therefore our solution must create a unique application identifier. Our solution is the following. As depicted in figure 1 of the proposed protocol, we take the cryptographic hash (ex. MD5, SHA, ) of the application (APK file). Our unique application identifier is a combination of the certificate and the hash. So if a given vendor uses the same certificate for ten applications and each application has five versions, we will maintain the reputation of 50 unique applications. So our Android security application sends just the certificate and hash to the AM Cloud. We normally do not need to send the entire application (APK file) to the cloud. The AM Cloud then sends the reputation back to the Android. Then based on the reputation, the Android takes the appropriate action (as discussed above) .The reputation building protocol also considers the vendors reputation. For example, applications from the vendor Google would have a much higher (good) reputation than applications from an unknown vendor. If a vendor releases even just one malware, that vendor past and future applications would immediately have a much lower (bad) reputation. If an application does not indicate who the vendor is, that application would begin with a very low reputation. A given anti-malware provider is able to keep track of the number of their users, who are running any given Android application. If a given vendors application has under ten users, the reputation would be extremely low (unknown reputation). The reputation would increase (good reputation) as hundreds, thousands and even millions of users run a given application. The reputation value of the application increases as more positive feedback is collected from Android phones that have installed that application.

1.5.2 EXPERIMENTS

Concerning just the applications which have not yet developed a strong reputation, we need to analyze those applications. To analyze the behavior of an Android application, it is easier to start with analyzing the set of permissions that the application has set in the Android application package file which includes all of the applications code, resources, assets, and manifest file. This can be done by some cloud based servers. The servers can then estimate the reputation based on the above analysis. This way, future client requests will receive the reputation based on the above analysis. If and when any new malware is detected, the cloud based reputation can be immediately updated (based on the applications certificate and hash value). To do this, we have experimented with a reputation based security model for Android applications. A second experiment was also done to analyze how a malicious application could track a mobile owners location and report it to a third party. The results were achieved using two experiments. 1.5.2. 1 Experiment 1 One solution which has been used by anti-malware vendors is to perform analysis of the application, on the Android platform. However the Android is low on resources, such as performance, battery life and main memory. So it makes more sense to perform the analysis in the AM Cloud. To overcome these issues, another solution which has been used by anti-malware providers is to upload the entire application for analysis (for each user). For our solution, we will minimize the uploading of applications to the AM Cloud. I.e., we do not want two users, with the same exact application, to both upload the same application. Our approach to minimize the uploading of applications now follows. Prior to installing the application, the hash value of the application will be computed. The combination of certificate and hash value will be unique (not vulnerable to forced hash collisions). The combination of certificate and unique hash value will now be referred to as the Application Identifier. So instead of uploading the entire application, only the Application Identifier will be uploaded to the AM Cloud. The AM Cloud will then perform a database look up, based on the Application Identifier. The AM Cloud will retrieve the applications reputation from the database. The AM Cloud can then send the applications reputation information to the Android user. The Android phone can then advise the user of any security issues or take automatic actions. If the reputation based security model or another security safe guarding mechanism is breached, the malware can tweak the android platform permission model to access private values of the mobile holder, like SMS, GPS position, contacts, call history and so forth. 1.5.2.2 Experiment 2 In this second experiment, we have developed two applications namely LocationTracker, see figure 1, and ProxyMailer. The LocationTracker application has ACCESS_FINE_LOCATION, ACCESS_MOCK_LOCATION, and ACCESS_COARSE_LOCATION permissions in the user permission manifest file of the application. The manifest file declares which permissions the application must have in order to access protected parts of the API and interact with other applications . It also declares the permissions that others are required to have in order to interact with the application's components [18]. On the other hand the ProxyMailer is granted only the INTERNET permission. The LocationTracker application implements a location listener class that returns the latitude and longitude of the present location by consulting the LocationManager, which provides access to the system location services. We can use the latitude

and longitude to locate the associated geographic place such as the street address, hotel, and zip codes.

The user permission line of the LocationTracker application was granted the following permissions, see figure3.

Figure 3.User permission line of Location Tracker.

The GPS setting has to be enabled for the access location permissions to have access to requestLocationUpdates, which returns the present geographical location of the device by requesting for location updates from a GPS server. The ProxyMailer application makes use of the ACTION_SEND intent of the Android platform, which is used to share contents (Email, Twitter, and Facebook). After receiving the current geographic location from the LocationTracker application, it composes a rogue email to a third party and includes the location as its email body part. The AndroidManifest.xml file of the LocationTracker application includes a declaration of a service that will be used by the ProxyMailer client intent application to have access to the coordinates, see figure 4.

Figure 4.ProxyMailer accessing location parameters and sending to third party. The LocationTracker application has been denied of the INTERNET permission but gives Service line permission to the ProxyMailer application. The ProxyMailer application accesses the Service of the LocationTracker application by defining Intent-an abstract description of an operation to be performed. 1.5.3 RESULTS The results of the first experiment set up, as depicted in figure 6 show that the device downloading a specific application can check for the reputation value preinstallation. For our example, we used a threshold for applications with reputation index greater than 20 to indicate a good and reputable application. For applications with a reputation index between 10 and 20, our policy allows the application to be installed. However, the application is sandboxed and monitored. For applications with reputation index less than 10, users should be warned to not install the application unless they know it is trustworthy. The user can even be informed as to the specific type of any malware previously associated with the untrustworthy application. Figure 5.Results of the reputation matrix of each application.

As stated in the second experimental set up, the two applications were developed and installed separately with the consent of the user to the permissions in each applications manifest file. The ProxyMailer application, with its defined intent, has managed to access the present location coordinates from the LocationTracker application, which demonstrates that a malicious application can seamlessly access another applications services without the knowledge of the user. The ProxyMailer can then send the innocent users current location to a third party email without the mobile holders consent. The service intent of the ProxyMailer defined in the applications Activity is used to move the new location data between the processes, as it is the messenger that crosses the actual system security boundaries. Intents are actually at the core of much of Androids IPC. The LocationTracker Activity will keep updating its new area coordinates whereas the ProxyMailer has to be manually run in order for the intent to have access to the client application. The Intent object is passed to the Conext.startService() to initiate the service or deliver new instructions to an the service in the LocationTracker application. startService() called over a context object is an android built-in function that enables one application to start the service of another . In a similar implementation, the Intent could be passed to Context.bindService() to establish a connection between the calling Activity from the ProxyMailer and a targeted service in the LocationTracker application. The android bindService() function called over a context object can initiate the service if it isnt already running.

Figure 6.ProxyMailer after location retreival.

Reverse geo-coding can be used to get the actual geographical name of the new location of the mobile holder except that the experiment was done on the Android SDK emulator.

1.6 EXAMPLE APPLICATIONS OF ANDROID

ANDROID ANTI THEFT SECURITY JUNOS PULSE FOR ANDROID PHONE SECURITY ALARM SYSTEM 1.6.1 ANDROID ANTI THEFT SECURITY The ultimate security for Android device in case it is ever lost or stolen

Accurate tracking Data encryption Spy camera activation Device lockdown Some reasons why Android Anti-Theft Security is a must for your smartphone or tablet device: Device Location Tracking

 ENCRYPTION AND HIDING OF DATA AUTOMATIC REGISTRATION SPY CAMERA SOUND AUDIBLE ALARM SIM CHANGE DETECTION UNAUTHORISED SIM INFORMATION CAPTURE LOCK DOWN OF THE DEVICE SET YOUR OWN LOCK LOST DEVICE REPORT GENERATION Other supported platforms: WINDOWS, MAC, BLACKBERRY Permissions SEND SMS MESSAGES HARDWARE CONTROLS TAKE PICTURES AND VIDEOS YOUR LOCATION FINE (GPS) LOCATION RECEIVE SMS READ SMS OR MMS EDIT SMS OR MMS FULL INTERNET ACCESS READ CONTACT DATA WRITE CONTACT DATA

1.6.2 JUNOS PULSE FOR ANDROID Junos Pulse secures connectivity to your corporate web-based applications via Juniper Networks SSL VPN gateways

1.6.2.1 Features Secure access to web-based applications, enterprise networks, and bookmarks Secure access to corporate email through Outlook Web Access. Real-time antivirus protection. Background scanning of all network traffic and interfaces for malware, viruses and spyware.

1.6.2.2 PERMISSIONS: DIRECTLY CALL PHONE NUMBERS YOUR LOCATION YOUR MESSAGES NETWORK COMMUNICATION YOUR PERSONAL INFORMATION PHONE CALLS STORAGE SYSTEM TOOLS YOUR ACCOUNTS NETWORK COMMUNICATION SYSTEM TOOLS 1.6.3 PHONE SECURITY ALARM SYSTEM An alarm sound will play when a voice/noise is too loud, on movement or on touch. High quality sounds

1.6.3.1 FEATURES: Nice graphics All configurable Many different sounds

1.6.3.2 Permissions HARDWARE CONTROLS RECORD AUDIO NETWORK COMMUNICATION

FULL INTERNET ACCESS

1.7 CONCLUSIONS AND FUTURE WORK

Android smart phones are becoming very popular among the different smart phone platforms and this is expected to increase in popularity . Despite its popularity momentum, its open source software and programmable framework behavior make it vulnerable to virus attacks [19]. In this paper, we present a reputation based security model for android applications. The paper takes into consideration the fact that Smart phones are memory, battery and speed constrained and hence exploiting the cloud to do the reputation index computation of a given application. By referring to the calculated matrix of reputation built by a given application, the model will notify users on the potential risk of the application before installation. Applications can be classified as highly risky, medium risk, less risk and genuine all based on reputation they have built in the cloud. The experimental results show that some application need to be regarded as highly risky and therefore warn users not to install them until they improve their reputation by passing the threshold set by the reputation based security. model proposed in this paper

REFERENCES [1] A.Shabtai, Y. Fledel, U. Kanonov, Y. Elovici, S. Dolev, and C.Glezer. Google Android: A Comprehensive Security Assessment. InIEEE Security & Privacy, Volume 8, Issue 2, pp. 3544, MarchApril2010. [2] T. Blsing, L. Batyuk, A.-D. Schmidt, S.A. Camtepe, and S.Albayrak. An Android Application Sandbox system for suspicious software detection. In Proceedings of 5th International Conference onMalicious and Unwanted Software (MALWARE 2010), Nancy, France, Oct. 1920, 2010. [3] M. Ongtang, S. McLaughlin, W. Enck, and P. McDaniel.Semantically Rich Application-Centric Security in Android. In Proceedings of the Annual Computer Security ApplicationsConference (ACSAC '09), Austin, TX, USA, December 610, 2009. [4] W. Shin, S. Kiyomoto, K. Fukushima, and T. Tanaka. TowardsFormal Analysis of the Permission-Based Security Model for Android. In Proceedings of Fifth International Conference onWireless and Mobile Communications (ICWMC '09), Cannes/La Bocca, France, August 2329, 2009. [5] P. Teufl, C. Orthacker, S. Kraxberger, G. Lackner, M. Gissing, A.Marsalek, J. Leibetseder and O. Prevenhueber. Android Market Analysis with Activation Patterns, In Proceedings of 3rd InternationalICST Conference on Security and Privacy in Mobile Information andCommunication Systems (MOBISEC 2011), Aalborg, Denmark, May1719, 2011. [6] C. Orthacker, P. Teufl, S. Kraxberger, G. Lackner, M. Gissing, A.Marsalek, J. Leibetseder, and O. Prevenhueber. Android SecurityPermissions - Can we trust them? In Proceedings of 3rd InternationalICST Conference on Security and Privacy in Mobile Information andCommunication Systems (MOBISEC 2011), Aalborg, Denmark, May1719, 2011. [7] J. Burns. Developing Secure Mobile Applications for Android AnIntroduction to Making Secure Android Applications, http:// www.isecpartners.com/files/iSEC_Securing_Android_Apps.pdf,Accessed on May 8, 2012. [8] E. Chin, A. Porter Feltm, K. Greenwood, and D. Wagner. Analyzingthe Interapplication Communication in Android, University of California, Berkeley, Berkeley, CA, USA. [9] T. Vidas, D. Votipka, and N. Christin. All Your Droid Are Belong ToUs: A Survey of Current Android Attacks, INI/CyLab, CarnegieMellon University.900