Transcript Android Declassification Infrastructure

Android Declassification
Infrastructure
Matan David
Yuval Evron
Project Advisor: Roei Schuster
1
Introduction and Project Presentation
• Unveiled by Google at 2007.
• Based on the Linux OS.
• Used by 50% of smartphone
owners in the U.S.
• Over 300 million Android devices in use by
February 2012.
• Over 850,000 Android devices activated every
day.
2
Introduction and Project Presentation
• Android is an open source platform for designing
and developing a wide variety of applications.
• Android has a large community of developers.
• Applications are written in Java.
• Writing apps for Android is easy and very straightforward:
private Camera camera = Camera.open(cameraId);
camera.takePicture(null, null,
PhotoHandler(getApplicationContext()));
3
Introduction and Project Presentation
• How can an application
“communicate” with different
hardware components
(Camera, SD Card, etc..)?
• Introducing: Android’s
“PERMISSION" mechanism.
• <uses-permission
android:name="android.permission.CAMERA"/>
4
Introduction and Project Presentation
• Perfect, right? Not really!!
• Android permissions are not very fine grained.
A permission can either be given or not, with
nothing in between.
• This presents a problem!!!
5
Introduction and Project Presentation
• Microsoft deals with this problem
by providing an abstraction layer
integrated within Windows Phone OS.
• Microsoft’s “Launchers” and “Choosers” API.
• As of today, Android does not provide an
integral solution.
• This is where our project comes in!
6
Our Project
• Does not involve changing
the OS infrastructure itself.
• Identify the most commonly
used resources and subdivide
the permissions given to apps
requesting them.
• Introduce a new permission
mechanism – “A Declassifier”.
• All this is done in the application layer.
• This only one (of many) ways we can resolve
this issue.
7
Project Goals
• To enable the development
of safer Android programs.
• Applications utilizing our
infrastructure will be less
privileged and more secure.
• No compromise on application functionality.
• No more “All or Nothing” approach.
8
Success Criteria
• Achieving the highest number of consumer
applications using our infrastructure. We will
statistically analyze applications in the Android
Market (Google Play) and determine which
permission requests, among those relevant,
are the most common.
• Success will be measured by revising consumer
applications, limiting their privileges, while
preserving their original capabilities.
9
Incremental Stages
* Our project is an iterative process.
1. Research, delimitation and development of
prototypes.
2. Implementation and testing.
3. Security analyzation and experimentation.
10
Pertinent Literature
• The Effectiveness of Application Permissions –
Adrienne Porter Felt, Kate Greenwood,
David Wagner
University of California, Berkeley.
• Understanding Android Security –
William Enck, Machigar Ongtang, and
Patrick McDaniel
Pennsylvania State University.
• Developing Secure Mobile Applications for Android –
Jesse Burns,
iSEC Partners
11
Pertinent Technology
• Launchers and Choosers for Windows Phone –
http://msdn.microsoft.com/enus/library/ff769556%28v=vs.92%29.aspx
• Android Manifest.permission http://developer.android.com/guide/topics/manifest/manifestelement.html
• Android Intents and Intent Filters –
http://developer.android.com/guide/topics/intents/intentsfilters.html
• Android Activity –
http://developer.android.com/guide/topics/fundamentals/activit
ies.html
12
Related Projects
• Open Intents – http://www.openintents.org/en/
13
Requisite Tools
•
•
•
•
14
Android SDK
IBM Eclipse
ADT Plugin for Eclipse
Samsung Galaxy S II
Resources and Knowledge
• Android Dev Guide–
http://developer.android.com/guide/index.html
• Java JDK Documentation http://docs.oracle.com/javase/6/docs/api/
• Android Application Development Tutorial http://thenewboston.org/list.php?cat=6
• Having no previous experience with programming for
mobile devices, this project requires a “crash course” or OJT
in Android development.
• Several tutorials and a hands on approach will allow us to
acquire the necessary knowledge for this project.
15
Risk Factors
• Despite having previous experience in writing software,
this is our first encounter with the Android framework.
• Competing projects may produce a more secure and
more efficient code.
• 3rd party application vendors may not be aware of our
newly developed infrastructure, thus not developing
their applications in accordance with it.
• Vendors may not want to invest time and money,
converting their already written applications to use
with our infrastructure.
16
Contingency Plan
• Being new to Android development, we are
unable to correctly identify the complexity
level of each declassifier. One may be more
demanding than another. Encountering
several complex declassifiers may mean we
produce less declassifiers than previously
anticipated.
17
18