1

Android Declassification Infrastructure

Matan DavidYuval Evron

Project Advisor: Roei Schuster

2

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.

3

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

straight-forward:private Camera camera = Camera.open(cameraId);camera.takePicture(null, null,

PhotoHandler(getApplicationContext()));

4

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"/>

5

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!!!

6

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!

7

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.

8

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.

9

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.

10

Incremental Stages

* Our project is an iterative process.1. Research, delimitation and development of

prototypes.2. Implementation and testing.3. Security analyzation and experimentation.

11

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

12

Pertinent Technology• Launchers and Choosers for Windows Phone –

http://msdn.microsoft.com/en-us/library/ff769556%28v=vs.92%29.aspx

• Android Manifest.permission - http://developer.android.com/guide/topics/manifest/manifest-element.html

• Android Intents and Intent Filters – http://developer.android.com/guide/topics/intents/intents-filters.html

• Android Activity – http://developer.android.com/guide/topics/fundamentals/activities.html

13

Related Projects • Open Intents – http://www.openintents.org/en/

14

Requisite Tools• Android SDK• IBM Eclipse• ADT Plugin for Eclipse• Samsung Galaxy S II

15

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.

16

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.

17

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.

18