270 likes | 407 Views
A multi- Criteria - based Evaluation of Android Application . Andrea Saracino , G . Dini, F. Martinelli, I. Matteucci, M.Petrocchi , D . Sgandurra. InTrust 2012. Android. Largest Market Share. Plethora of applications. Several marketplace. Official. Unofficial. 61%.
E N D
A multi-Criteria-basedEvaluation of Android Application Andrea Saracino, G. Dini, F. Martinelli, I. Matteucci, M.Petrocchi, D. Sgandurra InTrust 2012
Android • Largest Market Share. • Plethora of applications. • Several marketplace. • Official. • Unofficial. 61%
Can we trust them?? • Android is the platform with the largest increase of malware attacks. • More than 37 malware families specific for Android. • Malware found even in official markets.
Android Security Native security mechanisms? • Sandboxing • Permissions
The Permission System • Access Controlmechanism. • Declaredbyappdeveloperin Manifest file.
The Permission System (1) • Who takes the decision on Application Security? • THE USER!!
The Permission System (2) • Several users do not understand or care about permissions. • The user can only accept all the permissions or abort the installation. • Too rough grained permissions. • Permission overdeclaration.
What we propose • A threat based classification of Android Permissions. • A threat index to assess the hazardousness of an application. • A multi-criteria decision system to help the user in understanding whether an application is secure or not.
Type of threats • Each permission receives a threat score on three parameters. • ACCESS_COARSE_LOCATION • Privacy: 0.6 • System: 0 • Money: 0 • These parameters simply describe which security aspect is threatened by the application’s permissions.
Privacy Threat • Permissions that allow an application to: • Read Contacts • Read text messages • Access user’s accounts and passwords • Read IMEI and location
Money Threat • Permissions that allow an application to: • Perform phone calls. • Send SMS messages. • Use the internet connection. • Modify connection settings.
System Threat • Permissions that allow an application to: • Install/Uninstall applications on the phone. • Enable/Disable connection interfaces (Wi-Fi, Bluetooth, … ). • Switch on/off the smartphone screen.
ThreatLevels High Threat Moderate to High Threat Moderate Threat Low – To –Moderate Threat LowThreat No Threat
Threat Score • Extraction of permissions from the manifest for each application. • Computation of a global threat score. • Ranges from 1 - no permissions required - to 15 - all permissions required. • An application with a score higher than 7 is considered a very dangerous application. • Developer should declare only the necessaries permissions. (Contrast Overdeclaration).
Assessment of App Security • Permissions may not be sufficient to decide whether an application is secure or not. • Applications that really needs several permissions. • Malware that does not require dangerous permissions. • Add more criteria to assess the app quality. • Use of a Multi-Criteria decision System.
Multi-Criteria Decision (1) • Analytic Hierarchic Process (AHP) • Gives an objective decision using subjective criteria. • Highly flexible and customizable.
Multi Criteria Decision (2) • Criteria • Global threat score • Developer Reputation • Marketplace • Number of downloads • User Rating
Final Decision • An application can be considered by AHP as: • Trusted: Secure and Reliable. • Deceptive: Bogus or generally low quality application. • Untrusted: Shows several security issues.
ComparisonMatrices • Tellhowmuch a decision (alternative) isrelevant with respect to a criterion. • Example: Top Developer
Example: Baseball Superstar • Two versions of the same game, Vers. A, Vers. B. • Threat score: • Vers. A: 1 • Vers. B: 7,3 • AHP decide that Vers. A is trusted, Vers. B is untrusted. • Vers. B is trojanized by the Geinimi malware.
Example: Skype • Skype requires several permissions to work properly. (Threat Score: 6,8). • Market: Official • Downloads: More than 10 millions. • Rating: 4 / 5 • AHP decision: Trusted!
Results • 180 Android applications coming from different marketplaces.
Conclusions • We have defined a simple but effective permission classification system. • We provide the user with an app analysis tool: • Static (computation can be performed offline). • Easily understandable. • Force developers to carefully choose the required permissions.
Future Works • Inclusion of a reputation parameters based on user feedbacks. • Test the system on a larger application set, with different settings for AHP. • Inclusion of sub-criteria in the AHP decision system.
Thanks! andrea.saracino@iit.cnr.it