Android Declassification Infrastructure: Final Report
Download 33.36 Kb.
|
- Navigate this page:
- PART B: Background Motivation
- Part C: Our Project
- Lets take a closer look at our declassifiers implementation details. It is divided to 7 Java packages
- Content Provider
- PARTS D E: Now and Then
- PART F: Appendix A – Implementing Internet Service in our Declassifier
- PART F: Appendix B - Resources and Knowledge
Android Declassification Infrastructure: Final ReportPART A: An abstract descriptionIn today's world, smart phones are getting richer in capabilities and sensors every month. We trust our phones with storing our most private information in them. We use it for work and for connecting with our family and friends and carry them with us everywhere we go. One of the most popular operating systems for mobile phones today is Google's Android. It has become the world’s leading smartphone platform since the end of 2010. At the half point mark of 2012, there were 400 million devices activated and 1 million activations per day. In June 2012, there were more than 600,000 apps available for Android, and the estimated number of applications downloaded from 'Google Play' (Google's online store) was over 20 billion. Android allows applications to communicate with the hardware's devices (e.g. camera, SD card, etc.) using its permission mechanism. From the moment an app is granted a specific permission, it can access and use the appropriate hardware device any time it wants to. The problem with these permissions is their coarse granularity level. This presents a high security and privacy threat for users who are unaware of what the app they just downloaded does. We built an application level infrastructure which intermediates between the various apps using it and the OS. Our infrastructure asks for high permissions while exposing a finer grained permission "interface" to 3rd party applications that use it. This process of asking for high permission while exporting low permissions is called declassification. Upon installation, these applications can request only what they truly require. In this manner, applications run the same way as before while keeping the user a lot calmer. We identified the most commonly used Android permissions given to applications. Based on our findings, we designed our declassifier to enable access to 6 different phone “services” (substituting the coarse grained native OS permissions). These permissions are: READ_CONTACTS WRITE_EXTERNAL_STORAGE READ_PHONE_STATE READ_CALENDAR RECORD_AUDIO CHANGE_WIFI_STATE For each of these OS permissions, our declassifier defines a set of custom, finer-grained permissions which subdivide it. We tested our code by successfully porting open source applications to use our declassifier.
One of the most popular operating systems for mobile phones today is Google's Android. Android is Linux-based and open source. It has become the world’s leading smartphone platform since the end of 2010. For the first quarter of 2012, Android had a 59% smartphone market share worldwide. At the half point mark of 2012, there were 400 million devices activated and 1 million activations per day. Android has a large community of developers which write primarily in Java. Writing Android apps is simple and very straight forward. In June 2012, there were more than 600,000 apps available for Android, and the estimated number of applications downloaded from 'Google Play' (Google's online store) was over 20 billion. Android allows applications to communicate with the hardware's devices (e.g. camera, SD card, etc.) using its permission mechanism. In order for an app to address a hardware device it needs the appropriate permission. The app declares in its manifest file the permissions which it intends to use. Upon installation, the user is required to actively confirm the app's use of the requested permission. From that moment on, the app can access and use the hardware device any time it wants to. The problem with these permissions is their coarse granularity level. For example, a malicious app can request access to use the phone's audio recorder, pretending to be a voice related app (i.e. Viber, Skype). After the user's confirmation, such an app can potentially record the user at any time without his knowledge. This presents a high security and privacy threat for users who are unaware of what the app they just downloaded does. There are many more examples of such coarse granularity in Android's permissions. As was shown to us in class, Microsoft also realized this issue and solved it by adding an abstraction layer integrated within windows Phone OS, namely – its "Launchers" and "Choosers" API. Android, however, does not yet offer such an integral solution. That means there are hundreds of millions of costumers walking around with a potentially harmful device in their pocket without even knowing it. Part C: Our ProjectEven though Android is open source, our project does not involve changing the OS itself. Instead, we built an application level infrastructure which intermediates between the various apps using it and the OS. What our code basically does is ask for high permissions while exposing a finer grained permission "interface" to applications that use it. Upon installation, the applications using our infrastructure can request only what they truly require. In this manner, applications run the same way as before while keeping the user a lot calmer. For example, an application asking for write access to the phone's external storage will now be granted access to a small, confined part of the SD card, preventing it from manipulating data that does not belong to it. This process of asking for high permission while exporting low permissions is called declassification. Our infrastructure is a declassifier. First, we had to identify the most commonly used Android permissions given to real life applications. In order to decide which are most commonly used we took a survey in Google Play. Our findings can be found in the attached Excel document: “Android Permissions Usage Statistics.xlsx”. Based on our findings, we designed our declassifier so that it enables access to 6 different phone “services” (and potentially a lot more). It grants the apps everything they most probably need, while keeping the user as safe as possible. Thus, applications utilizing it are easier to develop, less buggy and most importantly – less privileged and more secure. These are the 6 coarse-grained Android permissions we chose to focus on: 1. android.permission.READ_CONTACTS – Allows an application to read the user's contacts data. 2. android.permission.WRITE_EXTERNAL_STORAGE – Allows an application to write to external storage (i.e. the phone's SD card). 3. android.permission.READ_PHONE_STATE – Allows read only access to phone state. 4. android.permission.READ_CALENDAR – Allows an application to read the user's calendar data. 5. android.permission.RECORD_AUDIO – Allows an application to record audio. 6. android.permission.CHANGE_WIFI_STATE – Allows applications to change Wi-Fi connectivity state. For each of these OS permissions, our declassifier defines a set of custom, finer-grained permissions which subdivide it. For example, instead of requesting the READ_PHONE_STATE permission, an application can now request only access to reading the phone's sim card serial number, the IMEI (given the network is GSM), etc. This way, the application has only access to what it needs (instead of access to all of the phone state properties) without interfering with its normal flow. A detailed description of each OS permission, potential harmful usage scenarios and a description of the custom permissions can be found in the attached document: “Declassifier Documentation.docx”. Let's take a closer look at our declassifier's implementation details. It is divided to 7 Java packages:
The top-most package contains the code which is common to all other packages, including the application's main GUI Activity and the implementation of the content provider (described below). Each package afterwards includes code which is specific to the service it implements.Content ProviderWith 3rd party application developers in mind, we decided to implement content providing services as easy to use as possible. In Android, a content providing service is usually implemented using a ContentProvider. A ContentProvider encapsulates data and provides it to applications through the single ContentResolver interface.When looking at the list of services we wanted to export, we decided that the Contacts, Calendar and PhoneState are all content providing services. Each of these services holds data that the 3rd party application can query on a “need to know” basis. And so, the declassifier implements a ContentProvider class. This way, each service holds an interface to a SQLite database which, depending on the requesting application's permission, can be queried for data. Each service exports an interface which matches the custom permission allowing it to be used. This interface is actually a URI for each sub-service provided by the main service. For example, in order to query the Calendar service for an event description by its title, the application has to query the ContentResolver using the following URI: content://my.declassifier/calendar/description_by_title -'my.declassifier' is the ContentProvider's base path. - 'calendar' is the service path. - 'description_by_title' is the wanted sub-service. The parameters for the query (e.g. what is the event's title) are passed via the "selection" parameter of the query method. The full list of services & sub-services URIs can be found in the attached file: “Declassifier Documentation.docx”. The syntax of the "selection" query parameters for each service can be found in the code documentation. BroadcastReceiver Unlike other popular Oses, in Android each app runs as a separate process under a distinct UID. This means that in order for a 3rd party app to communicate with our declassifier, some kind of IPC is required. Android offers several ways for IPC. Using Intents is unsecure as anyone listening in can recognize them and use them. After thoroughly reading the iSEC article (https://isecpartners.com/files/isec_securing_android_apps.pdf) and looking for a solution online, we concluded that the most secure way of IPC is achieved using a BroadcastReceiver. It filters incoming intents by caller permissions and enables a callback mechanism which allows sending back an answer privately. We implemented our ExternalStorage service as a BroadcastReceiver. An app that wants to use this service (provided that it has the permission to do so) has to send an ordered broadcast to our BroadcastReceiver, including the appropriate intent and parameters. The app also has to implement its own BroadcastReceiver which will be responsible for handling the callback result. This BroadcastReceiver will also be sent via the ordered broadcast. The ExternalStorage service basically allocates a folder for each application that uses it. The folder is named using the app's UID (provided by the app upon different requests). This folder is the only path in the external storage that the app can utilize and manipulate. This is done using the service's interface which allows writing files, deleting files, etc. The ExternalStorage service interface and custom permissions can be found in the attached file: “Declassifier Documentation.docx”.
We decided to implement several services as a proxy from the app to the requested service. In this design we require the user to actively grant access to a certain service for every request made by the application. Please note that the user's confirmation can theoretically be replaced by a smarter, automatic mechanism, which will be based on a set of rules including location, time, count, etc. In order for the user to be able to confirm the action, we needed a GUI. The BroadcastReceiver is not capable of creating a GUI or showing one (bringing it to the main screen). This led us to resort to the natural GUI container in Android - Activity. We implemented both the Wifi and AudioRecord as Activities. In order to use these services the application has to send an Intent containing both the appropriate Action and parameters. The application should also provide an implementation of a callback method which is run once the result of the action is ready (i.e. after the declassifier finished its job). Both the RecordAudio and the Wifi services' interfaces and custom permissions can be found in the attached file: “Declassifier Documentation.docx”.
Firstly, we needed to recall the scope and objectives of our project: To Enable safer application development. 3rd party applications using our infrastructure will be granted lower permissions, but should sustain their original functionality. Make the permission mechanism finer grained. Porting of applications should be simple and intuitive. Our success criteria were based on the quantity of applications we are able to port. For that matter, we took the survey described in part C of this document. Our findings can be found in the attached Excel document: “Android Permissions Usage Statistics.xlsx”. In addition, we judged our success based on our ability to sustain the ported apps’ original functionality, while granting them lower permissions. When first presented with this project we were unfamiliar with the Android environment and framework. This led us to design a solution based on Intents and activities. The solution required each application to send Intents to our declassifier. The declassifier, in return, supplied the service to the calling application and returned the results using the “OnActivityResult” method. Presenting our progress in the first class milestone brought forth an important issue which we did not pay enough attention to, and that is the security issue (See section 1 of project scope). Although very easy to use and intuitive, Intents are also unsecure. We realized that there are many inconsistencies in such a design. For example, who guarantees that the applications that are sending the Intents are authorized to do so? Since Intents are unsecure, any application can intercept it and use it as its own, allowing it to “disguise” itself as another application. The above drawback forced us to re-plan our design. We understood that further knowledge of the Android framework is needed. Thus, we started reading material relevant to the Android environment in general and to security in Android in part. In addition, we used web forums and online examples to get a deeper understanding of how to program correctly and securely in Android. As a result, and with more emphasis on security, we entered our second planning stage. At the end of this period, the conclusion was that we needed to use a BroadcastReceiver that will export custom permissions (for further details on the BroadcastReceiver see section C above). At that point we had a secure channel for applications to communicate with our declassifier. Soon afterwards, we entered our second implementation phase, re-implementing the declassifier in accordance to our new design. All through the 2nd milestone and towards our 3rd, we designed our declassifier as described above, assured that this was the most secure design. We still believe it is. However, when we entered our testing stage, we ran into another obstacle. As secure as our design was, we lost sight of who we are developing this declassifier for. We tried porting applications to use our declassifier, but that required many changes in the application’s code, making the whole nature of porting applications unintuitive and sometimes quite complex. This did not stand in unison with our success criteria and was therefore problematic. The cause of this complexity lied in the BroadcastReceiver’s asynchronous working model. That means that an app could ask for a declassifier service by using the SendOrderedBroadcast method which returned immediately. The result of the operation was read using a callback method which the caller supplied upon initiation. As a result, in order to port a real life application we sometimes had to interfere with its natural flow. Things tend to get tougher in case the application is already written in an asynchronous design (i.e. the app queries the calendar content provider from inside the OnActivityResult callback method). As one of our main goals was to make porting easy, we realized that we missed something along the way. This meant that we had to, once again, go back to the planning phase, establishing where security was critical, and where security failed in comparison to ease of use. After much planning, we came to the conclusion that on several occasions, ContentProviders are the more natural choice of implementation. This setback forced us to re-implement the relevant services using our new design. After re-planning our design we saw that the testing phase (porting apps) progressed more smoothly, better suiting our success criteria, and giving us confidence in the implementation we decided on. In other occasions, we decided to keep the services as BroadcastReceivers. Several services, however, were not fit to be implemented as ContentProviders, as they were not providing content. In addition, they required a GUI and therefore could not be implemented as BroadcastReceivers. Therefore, these services were implemented as Activities. This implementation was not the most ideal of solutions, since it still used an asynchronous model, making it more difficult to port applications (once again undermining our success criteria). We believe that, given more time, we could have found a more fitting design. During the entire process described above, we had to choose which services we wanted to implement. Such a decision demanded thorough research on the different permissions Android OS offers, their danger levels, granularity and possible malicious scenarios. These permissions also had to correspond to our statistics (i.e. we preferred permissions that were widely used on real life applications). The detailed analysis of these permissions and their implementation as services is described in the attached file “Declassifier Documentation.docx”. With the final design of our solution, we continued to the final testing phase. That entailed porting open source applications to use our declassifier and its services. Below is the list of ported applications: SMS Popup – For use with the Phone State declassifier http://code.google.com/p/android-smspopup/ Auto Answer – For use with the Contacts declassifier. http://code.google.com/p/auto-answer/ My Simple Notepad – For use with the External Storage declassifier. http://code.google.com/p/my-simple-notepad/feeds Wifi Compass – For use with the Wifi declassifier. http://code.google.com/p/wificompass/ GVoiceMail – For use with the Voice Record declassifier. http://code.google.com/p/gvoicemail/ This sits well with our success criteria, as we managed to port an application for almost all of our declassifier services. By using our declassifier, the above applications are now more secure and use a finer grained permission mechanism. We managed to sustain their original functionality. Moreover, most of the applications we found suitable were, after the design changes stated above, rather easy to port. The only service we had trouble porting an application for is the Calendar. Please see the attached “Progress Report.docx” for a detailed explanation why. For a detailed guide on how to install and port the above applications, see the attached “Ported Application Guides” files.
In Android, 2 permissions are relevant to connecting to the internet:
For our project purposes, the first permission is less of an issue since it does not present a high risk factor. Therefore, we leave this permission as is. The second permission is of much importance and has critical security implications. When an application receives this permission, it can connect and disconnect from the internet whenever it chooses to. In addition, there is no limitation to which domains it may connect to. Our idea of a declassifier for this service is to limit the application’s internet access to specific domains. There are two ways of achieving this:
Our declassifier permission will be defined as my.declassifier.INTERNET and it will work as follows:
Possible Issues: We assume in this design that we can transfer an InputStream from one process to another. There is a possibility that in Android you are not allowed to do so. PART F: Appendix B - Resources and Knowledge
Download 33.36 Kb. Share with your friends:
|