 Hello everyone, my name is Kaustubh Kishkar and I am doing MTech from CAC department and in this presentation I will be talking about a policy enforcement framework for Android. This is my, this is project topic, so let's start. In the outline I will first talk about the introduction about Android that you may have listened in other sessions. Then I will cover one of the research papers that I have read for this project and then what I will be implementing in this project and at the end I will conclude the session. So first talk about the Android application architecture. So you may know that the Android application can have any of the following components. The first is activity which is the interface between user and the application. So user can interact with the application using activity, then the service, next is a service. So if you have any high duty task, heavy duty task, then you can implement it as a service instead of implementing the logic in the Android activity. The third part is content provider in which it's a interface between your application and database and the last one is broadcast receiver. So Android sends out many events to the whole system. So say you get a call from someone or the Wi-Fi state is changed or something like that. So all these broadcast receivers can be captured or can be received to your application using broadcast receiver. For that you will have to implement a broadcast receiver. After that you will be able to capture all those events. So next is Android security. So Android provides some basic mechanism for the security purpose. First of which is application sandboxing. So as you may know that the Android is based on the Linux kernel. So in Android there is a concept of users. So for every application that you install, a new user is created and a new user ID is assigned to that application. So whenever you run the application, it's run as that user and it gets its own separate Dalvik VM. So even if the VM crashes, then at that time it won't affect the other executing applications. The next is application signing. So if you are an application developer, so before releasing your application to the any Google Play Store or any other store, you will have to sign the application using a digital certificate. Next part is Android permission model. So the Android as OS and many of its stock applications, they provide many features. So you get a calling features. Then you can have access to the GPS or you can also use internet. But for all these features, the Android system has given the permissions level. So if you want to use any of these features in your application, then you will have to assign the permissions level to that application. Then only then you can use those APIs. Otherwise the Android system will throw error or it will throw security exceptions. So the next part is all or nothing approach. So this approach is basically, so if you are installing an application, so at that time say there are 10 permissions which are mentioned in that application. So at that time you cannot say that I just want to assign or I just want to grant 5 permissions and other 5 permissions shouldn't be granted, that's not possible. So while installing, you will have to accept all the permissions, then only then the application can be installed. Plus once the applications are granted to the application, so once the permissions are granted to the application, then you cannot revoke the permissions. So if you want to revoke the permissions, then you have to uninstall the applications which basically obviously means that you won't be able to access the installed application anymore. And the last part is once you give the permissions to that application, you do not have any control on the resources. So say your application is using send SMS permission. So you don't have any control over how many SMS that application sends or if your application is using internet permission, then you cannot say that restrict this app by say if the application is using 100 MB of data for downloading and uploading, after that that application shouldn't get internet access. That's not possible in default android security mechanism. So that's why we need a policy framework. So one of the main goals of the policy enforcement framework is to restrict the usage of resources. So the policy framework will be able to give such kind of control to the user. So you can define policies saying that let this application send just 25 SMS per day or if the application is using internet access, then you will be able to define a policy saying that the weekly download and upload of that particular application should be limited to 100 MB. So if that application exceeds that said limit, then after that it won't have that particular permission. The next is to prevent the privilege escalation attack. So basically let me first give a brief idea about privilege escalation attack. So say you have two application, one is yours and the other one is attackers. So your application has the internet permission and you have implemented a service, but that's not a well protected service. So any other application can access your service and pass on the URL to the service and the service will basically download the data using that URL. So what attacker will do, it will create his own application and that application will use and that application won't have internet permission, but it will use your service to download the data. So basically for that attackers application it's a privilege escalation. So the policy enforcement framework will be able to detect and stop such kinds of attack. So in general the policy enforcement framework will deal with users security and policy concerns to provide users with fine grained access control. And then next is users of the system. So who can use this system? So the first one is end users, that's the users who have physical access to the device. So they can define the policies for their own or the next is trusted third parties. So let's assume that the employer has distributed tablets to his employees and employee, employer wants to not leak the data beyond company premises. So at that point the trusted third party as a, the employer as a trusted third party comes into picture and he should be able to define policies using this framework or even both end users and trusted third parties, both of them can define the policies. Now we have seen what kind of policies we can define and we can enforce, but when to enforce such policies. So the first or obvious mechanism is on different events that are generated by the system. So say if particular application is getting launched. So at that time we can say that particular policy should be enforced or we can also consider the environmental or system attributes which are part of context-aware policies. So time, location, CPU speed or battery. These all attributes come under the context-aware policies. So say if you are in a company from 10 p.m. to 4 p.m. So at that time context-aware policies will consider a time as a system attribute and it will enforce the policies. However you can use GPS also in which case if you are within the company premises then at that time it will execute the appropriate policies and so on. So this was the very brief idea, very general idea about the policy enforcement framework but then why I chose this as my thesis project. So the first is for the AKASH tablet. AKASH tablet is getting distributed to many school and college students. So let's say that teacher wants to conduct the quiz on AKASH tablet. So at that time no other applications should get launched. So during a quiz time or exam time applications which are not relevant to the quiz or exam say browser or any messaging applications, those applications shouldn't get launched. So the framework will be able to define and execute such policies. The next is limited sets of apps during school time. So during school time or college time applications such as gaming or messaging those shouldn't be allowed. So those policies will also be considered. The next is different set of apps for different courses or subjects. So say for history class a teacher may want Google earth or Google map application. So and this set might be irrelevant if the mathematics subject is going on. So for mathematics it will have different sets of application and during the history class it will have different sets of application and obviously at the end parental control. So parents may also want to have some kind of control over the tablet. The next is context attribute which is battery virtualization. So we have already seen that context attributes like time location. So all the research papers that I have read they have covered this time and location attribute but no one has ever considered the battery virtualization. So what it will basically do is it will get the battery consumption information for each and every application. So say you have 10 applications and you want to define a policy saying that if particular application consumes 30% of the overall battery then after that that particular application shouldn't get launched then this kind of policy will be enforced or other example that I can give is say you are running low on the battery and you have just 20 or 25% of the battery remaining. So at that time giving applications shouldn't get launched. So these kind of policy you can enforce and the last part is remote access mechanisms. So now consider that the Akash tablet is distributed to many students and there is some kind of change or update in the policies. So what admin will have to do it just collect all the tablets back and he will have to connect all the tablets one by one to the machine and enforce the policies or update the policies. So instead of that we can use this remote access mechanism to remotely enforce or update the policies. So existing mechanisms have suggested use of SMS, Bluetooth or Wi-Fi but this is not enough. So I will tell why in couple of slides. So just note that we will need something more than this. So this was the motivation behind my this topic. So I will first now explain one of the papers that I have read. So send is a research paper which basically is a short form for semantically rich application centric Android security. So basically this is framework which protects application from another application. So then the policy enforcement is done at the install time also and at the runtime also. So when you are installing the application at that time you can limit the installation or you can deny the installation based on the policies and also when you are launching another applications the framework will check the policies if there are any policies which violate the communication access between two different applications and it will restrict that communication part. So as I said the security policies are divided into two parts. The first one is install time policy and the second one is runtime policies. So the install time policies are nothing but permission granting policies. So the first this rectangle which you see here is what Android provides by default. So as we have learned that the permission it also it has the permission model by default. So the sent model they have suggested this 1.2 which is signature based policies. So what basically it means is once you are installing the application it will check the signature of that particular application. As I have already told you the application developer needs to sign the application before releasing it. So that digital signature will be considered in this policy. So if that particular application has the given signature then and only then allow this app to get installed on the device and if that particular application does not have this signature then we can assume that the application has been modified. The next part is application configuration based policy. It considers the requested permissions. So whatever permissions that that particular application has requested based on that application will be allowed to install or just to deny the installation. So and it will it may also cover the application version. So particular version has some kind of bug and that bug has been rectified in the next version. Then you can define the policy saying that the application version which is lower than this should not be allowed to install. So these two are the parts of run install time policies. Next we will focus on the run time policies which is nothing but the interaction between two application. So the first one is signature based policies which again considers the digital signature of the two communicating apps. So say one application is communicating to the another and you want to restrict the access. So you can define a policy saying that the other application which wants to communicate with the first application should have this signature. Again in this case also we can consider that if signature does not match then the application has been modified. The next is application configuration policy. So in this policy the particular permissions which are held by the communicating applications are considered. So in using this policy classification we can stop privilege escalation attack. So say that you had two application one with the internet access and one without internet access the example just I gave you. So in that case you can define a policy that the communicating app should also have the internet access. So if your application has an internet access then the other application which wants to communicate with you it should also have the internet access. So defining by defining such policy you will be able to stop the privilege escalation attack and the last part is context based policies. So next is proposal. So what I will be implementing in this project. So the first point that I told you was about the Akash tablet getting distributed to the school and college students. So the proposed architecture will be the end users will be school or college admins then the teachers parents and then the students itself. So in this case the school or college admins and teachers and parents we can consider them as trusted third parties and parents and parents and students we can consider them as end users. But now say in this the limited set of apps during school time. So the school admin has given the policy saying that these particular application shouldn't be launched for particular time when the students are in college or school and during the lecture time teacher wants to access wants to give access to say Google or Google map application and that app has been restricted by the school admin. So at that at this point there will be a conflict between the policies. So we will have to consider the priority handling also saying that the teachers have more access than the schools. So if the policies defined by teachers are more they get more priority than the policies defined by the school admins and then at the end say parents have also enforce the policies. So these policies shouldn't be removed by the children or the students. So for that we will need to provide some sort of access mechanism authentication mechanism and then I will also consider time location. Time location these two attributes they have already covered. But the battery form that I will also try to include in my final implementation. The next I talked about context attribute which was battery virtualization which considers the total battery consumption by particular applications. So if you have seen the settings in any AKASH tablet or any other Android device in the battery part it shows the top 10 usage of the batteries which applications have considered or they have consumed more batteries. So these so they already maintain this kind of battery information battery consumption information but that's not available to the final the end user or the application developer that's a part of the settings application. So I will try to read that or I will go through that power usage summary.yava I have given the reference here. So I will go through this code and I will try to implement same for my project. And the last part was access remote access mechanism in which the offered access communication mechanisms where SMS Bluetooth and Wi-Fi but SMS is a paid service. So not many may opt for this service then Bluetooth has very limited range and it cannot handle more users and at the end the Wi-Fi. So if you implement this remote mechanism so it will require polling. So if you have a framework on your tablet and say you have defined policies somewhere on the server. So the framework will have to poll again and again if there are any updates available. So instead of that we can use Google cloud messaging service. So this is the free messaging service which is provided by the Google and it has the client server architecture. So basically a framework will implement the client part and there will be a server part installed centrally in the college or school. So basically teachers or school admin they can log in to the server and they can just update the policies and after that those updates will be sent to the GSM servers. So what GSM servers will do is if the tablets are connected to the Wi-Fi and if they are connected to the Google Play Store then those policy updates will be sent back to the device and those will be updated and enforced eventually and if the tablets are not connected to the Wi-Fi then Google GSM servers, GSM servers they stores those messages on their servers itself and once the device is up then those updates are sent to the device. And at the end conclusion so for my thesis project I have compared many existing policy frameworks and have proposed a solution for these use cases and then this implementation hopefully will be completed before end, May end. Thank you and these are the references that I have given for you if you want to read those papers.