 Okay, so thank you for waiting. So I am Arun Joseph. I am from Texas Instruments. So I am one of the main trainer for AeroBoot.org project. So this is an open source project where we are porting Android to some of the open source hardware. Hope you heard about BeagleBot, BeagleBond and BeagleBond Black, such kind of open source hardware. So we port Android for these devices and we host these sources on AeroBoot.org. So I mainly work on porting Android. So but in this presentation I will be giving an overview of Android security, various attacks on Android and what are the security blocks in Android. Then some work, some guidelines for the people who work on Android. So I expect many of you are from Android development and somebody who would like to extend Android framework for the different needs. So let us get started. So I will start, I will be starting with some background on attacks on Android, Android devices and I will be like telling what are the security building blocks of Android. So there are different layers and the lower level Android offers some features in the system and kernel level and then in application security level Android will be of Android is offering different, there are different security aspects and on top of above there are some Android cloud services which prevents Android malware and some other attacks. So this is a graph which I took from Trend Micro website. So they are leading anti-virus company and they have some data till 2013 September. So they are showing that around 1 million Android malware and high-risk apps exist today targeting Android. So do you know how many apps exist in Google Play? So there are around 500 different app stores in internet other than Google Play. Some of them are dedicatedly hosted for Android malware. So that is what these statistics indicate. So mainly Android malware, you can classify the Android security threats into different categories. So one of the categories is Android malware. In that we have some of the malware will be like stealing data from your phone, accessing your SMS contacts, email, etc. And then some of them will be doing online banking theft like fraud and other things. And normally now corporate big companies provide VPN access through your Android phone. So some of the malware will be targeting that. So that will be from Android malware's perspective. So in general when we talk about Android threats, there are other things. So there are something like insecure Wi-Fi networks that can act as a middle-in-the-man kind of attack. So somebody sitting near you may not be accessing their mails, might be intercepting the whole Wi-Fi traffic and will be trying to get from the internet application layer. So that kind of attacks are there, that are network related attacks. So theft and the lossing of smartphones is also a security concern. So all your passwords, all your data stored in your smartphone, and if a user loses this phone, there should be some way to lock that phone, or there should be some way to remotely locate that phone or wipe the data on that phone. So that is also an aspect of Android security. So then another thing will be routing. So normally as an Android developer or an Android user, you would consider routing as a very good thing to have. But most of the device manufacturers would not consider routing as a good practice. Then that will be a security aspect from the device manufacturer point of view, like a Samsung or a TA or Amazon point of view, that they would not recommend. Then network providers like AT&T, V-Design, such network providers would want their phone not to be unlocked so that they would lose the contract. So these are all security concerns from different people, different stakeholders of Android. And 2013, the major highlight was that master keys vulnerability. And this was discovered by one of the company called Bluebox. And they proved that 99% of the Android phones existing today can be attacked with this vulnerability. And even almost all apps, what this exactly is, you can update or install an updated version of the legitimate application with malicious content inside that. So I'm not going inside that into the details. So I'll just quickly give an overview of what are the tactics used by these malware. So mainly, like I described, the Android Master Key Vulnerability, it was using like repackaging of the application and inserting some malicious content and would like fool the user to install or to give his access. So that is one of the tactic. And the next thing is negative code execution. So this is where most of the Android malware are actually trying to get a root access in your phone so that they can access any area of memory. And then once they get the root access, they can do anything with the phone, data or the network. Then Android 2.2 onwards, Android provides device administration APIs. They are just like you can control your complete data, like wipe your data, lock your phone with a password. So these device administration APIs are provided from Android 2.2 onwards and the users can be fooled by the malware to install as a device administration applications and they can get a device administration privileges to wipe or lock the data. Then over the air attacks in that, like Android would allow a network provider to push some settings on your phone, like your APN settings. So there are many, many settings can be like pushed onto your phone and fooled the user that it is received from your network provider, but it will be doing something else on your phone. So the main goal of Android security is to limit all these attacks and if the Android phone is affected, how to limit the impact. So this is the goal of Android security and there are like a lot of expectations from different people. Like you can consider Android users, Android application developers, Android device manufacturers and the network provider. So and some people would be like generating content for smartphones, like video or music. So all these stakeholders have different expectations from the Android security layers. So the challenge would be like you have your complete, like almost 100% source open and you have plenty of reference designs to play with. So there are like for a like like attacker, there are a lot of like resources available, like the complete open source and there are reference designs like Nexus 7, Nexus class of devices. And so these are the actual like challenges to provide the security while being open source and like with a lot of reference designs, how to like satisfy all the security needs from different stakeholders. So I'll quickly go through these slides because you know all these like on the left side you can see Android platform building blocks and the right side you can see the Android security building blocks. So I have just taken the differentiating factors of Android security. So if you can see from low level to high level, top level, you can see Android is actually like enhanced, has enhanced the Linux security and then it is providing a concept called Android application sandbox and there are for Android framework and Android applications, it gives a concept of permissions. Then at a Google Play level or cloud level, it offers different things called Android Bouncer which is to scan like periodically like the Google Play content and if any malware is detected, remove them. So that constitutes the complete Android security. So this is like the platform stack, the Android security stack. I'll just like Android security broadly like it is multi-layered and this can be divided into three different layers. One is kernel system security at the low level and in the middle level you can say application security and top level Android cloud services. I'll go detail into different layers in the coming slides. So a quick overview of system and Linux security. So the main concept here we have is application sandbox. So we'll tell what is application sandbox. Then Android, if you like inspect a Android device, you'd find different partitions like boot, system, data, cache. So many partitions are there and the system partition is the one which contains almost all operating system libraries and some core libraries. So this partition Android has made read-only. So then there is something called safe mode. If you enter into safe mode, only core applications of Android will be accessible. So then there are file system regarding file system permissions. So each of the applications, whenever they create new files, okay, that files are applicable only to that particular application. Other applications cannot read the different applications file. Then Android complete Linux is enhanced with the security enhanced Linux project. So security enhanced Linux is something like, you can designate resources, system resources. So even if you get a root access, you may not be able to access all the raw block devices. Let's say, you can actually label the raw block devices of your flash and you can enforce some security so that the root, even getting root access, cannot destroy any data in some of the raw block devices. So I'll just talk about the main difference between the traditional Linux and Android. So in traditional Linux, we have different users, Guest, some, your name, so root, so many different users are there. So these are like Android, sorry, Linux kernel will give like complete security between the users of Linux operating system. But in Android, when it comes to Android, Android would be giving security between applications. When an application is executing, it is like protected from different applications. So this is achieved through Android, like Android thinks that each application is a user. So then and Linux kernel will enforce the security between users. So the resources are protected from each application. So this forms a basis for the application sandbox. So application sandbox is nothing but what I said. There is no permission for an application to access the system data, the user's data, or any other application's data. And if you want to access any other application's data, you have to declare permissions and you have to explicitly request through your Android manifest file. So one of the other aspects of your system and kernel security is memory protection. So most of the malware would, like all these options, Android enabled one by one because many of the malware like in the past tried to attack these vulnerabilities. So maybe I can give you like example of each memory protection where it was vulnerable at an earlier point of time. So mainly in memory attacks, the malware would target the buffer overflows, mainly heap and stack overflows. And then integer and string overflows, then like leaked kernel addresses. And the malware assumes that the code will in a executable image, the code area will be this, the data area will be this, the stack area will be this. So Android malware would assume that. So to protect that, so there are features like address space randomization where you cannot predict where the code area of an executable, where the data area of the executable. So all these options are enabled in the compiler level. Yeah, you can find these options in the build directory or in the pre-built tool chain directory. You can find patches for this. So Android tool chain, the tool chain is different from the normal ARM GCC tool chain. So from a user's perspective, you can actually encrypt your file system data. That is your data partition, which contains all your application data. And there is external storage that also you can encrypt. Then device password, it can be like a, you can enforce the security complex rules for the device password. Then from Android 2.2 onwards, Android provides the device administration APIs. And to enhance the VPN and the certificate storage, Android provides some more APIs in the later versions. So now we have covered the system and kernel level security. So now we are moving to the middle level, where middle level, where we are classifying the system resources. In the Android app framework, you're classifying some APIs which are cost sensitive and some APIs which are protected APIs. So you can find these APIs as examples. So from applications, there is a permission check level. Under that, all the personal information and the sensitive input devices and the user data would come. So all these constitute the sensitive user data and the protected APIs. And from applications, there is an intermediate level where Android enforce the permissions. And the SIM card access APIs are a different thing. So for that, only you cannot access the SIM card by getting any of the permissions. You have to call it through the real layer. That is the radio interface layer. So there is like as an app developer, you will be aware of application signing process. Before installing to any device, any device, you have to sign your application with a public key, private key pair. That is called certificate. And so Android uses this certificate. So I told that certificate is a pair of private key and public key. And Android uses this method to identify the author of the application, to identify the authenticity of your application updates. And if two applications have to communicate to each other, Android uses this certificate as an authenticity for communication between different applications from the same order. So there are something called debug keys and the normal keys. So you cannot sign an application with the debug key. Then it cannot be uploaded to Google Play. So you have to create a private key, public key pair. So you can use the key tool binary. It can be allocated in your SDK or in the Android sources in the host part tools. You can locate the key tool. That can be used to create the key. And if this certificate is compromised, the other malware can use it to update or give a repackaged version of your application with the malicious content. So also you can use the Eclipse tool, where you can use the Eclipse tool to sign your application. So now we covered the one part of application security. So one of the other building block is permission model. So as I told, due to application sandbox means each application is running as a different user in Android compared to Linux. So one application can access only its data. It cannot access the operating system data, the users data, or other applications data. So if you want to access that data, so normally the application cannot read, write other applications, like keep the system awake or get the user data, et cetera. So if you want to do that, you have to explicitly mention it in your Android manifest file. And at the time of installation, the package manager of Android would ask the user to grant these permissions and only at install time. And any other point of time, these permissions are granted only at install time. And it is granted forever. And you cannot request additional permission at runtime. And there is something called shared user IDs. So if you are another of two applications, your two applications want to communicate each other without the need of permissions. You can declare a attribute called a shared user ID by which you can access each other's file, each other's application's file. And from your application, if you create a file with these flags, then it can become accessible by all the other applications. So in permissions, there are three concepts. Like one is using the permissions. Second thing is declaring the permissions, new permission, and enforcing the permission. So these are the main things in the permissions model. So as a normal application developer, you will be using the permissions. So to use the permissions, you have to use the attribute using permissions. And all the available permissions, you can find it in this link. Or if you are in your Android device, if you execute command PM list permissions, then it will list all the permissions. And if you go to your settings and you go to an application and at the bottom, you can see what role permission one application would be granted. And this is regarding declaring new permissions in your Android false code or in your Android application so that the other applications can use it. And this is how to use the permission attribute to actually declare a permission. So now comes the permission enforcement. What do we have covered is using the permission and how to declare a new permission and how to enforce a new permission. Sorry, I enforce a particular permission. So as an application, as a phone application or an SMS application, I can enforce the permissions on to my activities, on to my services, on to my content providers. If you are a mail application, you can enforce permission on to your content. So that is called permission enforcement. And that you have to do in your Android manifest file, plus you can do at runtime also. At runtime, you can say that if somebody is calling your service, if somebody is calling your content provider APIs, read content, write content, if somebody is calling an activity of your application, then you can check at runtime whether the calling process or the calling application or the calling processor process have that particular permission. Then there is something called URI permissions. So in URI permissions, the main thing is like considering a mail application where mail application doesn't have image viewer. So if the mail application has an attachment, so it would hand over that URI. URI is nothing but the path to a file to the image viewer application. The image viewer application should not access all mail content. So to prevent that, Android introduced permission called URI permission, where which you can, like when a mail application gives pass an indent to the image viewer application, it can specify these flags so that it has the ax. It is giving that content provider URI path to the image viewer only to that particular content. So and also content providers also should support this. So these are the 10 bad permissions like described in Google I.O. So if your application has all these permissions, then it is likely to be rejected in Google Play. So if your application is unnecessary asking these permissions, there is a good chance that the Google Play can reject your applications. So these are some guidelines. So instead of using the send SMS permission, you can ask the combustor to be like, you can use the SMS combustor, or instead of accessing the camera directly, you can use the image capture permission. So instead of reading the read font state, you can request for a random ID if a random ID only required for your application. So you don't need to access the font state or font identity. So there are four platform keys. So I told each application or each package has to be signed with a key. So there are four platform keys. So this is more of interest of a device manufacturer or an Android package, complete package provider, where you have to sign all of your platform and the shared and the media all if you are content with some keys. So there are keys provided in ASOP. But you have to generate your own platform keys so that it will pass the Android CTS. So Android CTA compatibility test is something a suit which would validate your Android distribution. So starting from 4.2 onwards, Android gives support for multi-users. In multi-user scenario, we will just investigate what is the permissions and the applications. So I talked about user IDs. Each application is given a separate user ID. So in multi-user scenario, each of these applications will run with a different user ID for a different user. So application code, so application package and the Dalvik cache and the applications native libraries all are shared. But the application's data and the application's runtime process is different for a different user. So Android would do it with pre-pending the user ID with the application's original user ID. So Android updates, like if a security problem is reported to Google or Android, then they would intimate the OEMs. And they will internally work on a patch and they will deliver to the ASOP. Plus they will deliver to the OEMs so that OEMs can give updates to the user ID. So there are some cloud services available. And the main one of them is Android Bouncer, which periodically checks all your Google Play content and removes the malware. And there is something new called remote application removal. So remotely, Android can remove malware from your device. So this is a very recent concept, which I just read in one month back. So I do not know the exact details of this. And Android provides the application verifying. So you can select the verify apps so that your application can be verified while installing. And there is something new called Android Device Manager. So if you have latest version of Android, so if your device is registered for Android Device Manager from anywhere in the world, you can locate your device, you can ring your device, you can lock your device, or you can wipe the data of the Android device. So Android also provides the backup and restore. So this backup and restoring will be a major security consent for the Android users. So this concludes my presentation. So the main thing, which are being debated, the thing is a lot of Android devices are with the older versions of the software, from Eclire onwards. So if a master key vulnerability is discovered and a patch is available from Google, the OEMs will not update the older devices, isn't it? So that is a discussion point. And regarding permissions, the users will be granting the permissions at the install time only. You cannot modify the permissions. So that is also a discussion point. So anybody of you have any questions on these topics? Hi. Can you give an example of a simple attack? Yeah. Stack over apps. OK. So I'll just give an example from my perspective. So earlier at Texas Instruments, you would make Android like SOCs, SOCs which can run Android. In that, we have a graphics driver called the, our graphics driver was from Imagination. So that graphics driver exposed a device node, which is called devPvrSvrkm, dev node. So the problem was like any user application was able to like open that device node and do some IOCTLs on that particular device node. OK. So that device node, so internally, the IOCTL was able to write to the kernel memory areas and which would give the root access. From root access, the malware can do like a profit from there. So that was one of the attack and the full description of the attack and how to use that attack is described in one of the reference here. I have it in the reference page. And another good example is like in earlier versions of Android, like there was one file called data. So this is one of the method I used to route my phone. So this attack is like you have a data local prop file here in Android system, which was read-writeable for the user, normal user, where you can specify the read-only property RO.secure equal to or false. So you specify it as like a false. Then on the next reboot, you would get the instead of user prompt, you will get the root prompt. So most of the category of attacks called Android boot kits were using this method, modifying the system property and reboot. And when you get the boot completed message, you start your malware action. So there are like a lot of resources available, which I have described in my references. And go through that, you can find out the different malwares, how they were able to get access to the Android root access. So mainly, all these malwares were using the root access to the phone, mainly to their malware operations. So I have a question. You have pointed out different security areas. But my question is nowadays we bring our own devices to our offices. So we have on the same device, we have organizations or corporate data as well as our personal data. So like the email system, we have the personal email as well as the corporate email. So how to segregate or is there any web services available for this particular area to secure the corporate data? Like we have encryption, we have multi-users nowadays. But anything else in this corporate and bring your own devices? Yes. Actually, from that aspect, Android provides the VPN APIs and the credentials APIs where you can securely store your company's certificates. So that is one area. And another thing regarding encryption and decryption, so Android provides the OpenSSL and the Bouncy Castle APIs for encryption and decryption and for the network security and the other Java security. So in OpenSSL, even you can accelerate your software implementation of cryptography. You can use the hardware implementation also. And in some cases, Android provides this layered approach and anywhere you can tweak your security. So for that, some examples you can say Samsung Knox where they have expanded this security with the ARM trust zone features. ARM trust zone is a security feature. So thereby, you cannot run custom images onto your phone. So Android provides the device management APIs and the security framework consisting of the Bouncy Castle and the OpenSSL. And there are APIs to credentials and the VPN. And apart from that, Android provides the extensions also, extensible framework so that the other vendors can extend the framework to suit their needs. Hi, I'm Satish. You told us about the application security. It provides the permissions while installing the app. What if we have to update the app and it requires different permissions, which are not malicious? Sorry, when you update your? The update needs different permissions. And the different permissions has to be granted. Will the security allow that? Yeah, actually, Android, if you check the Android guidelines, if it is a new permission being introduced by Android. So you have to specify the target of your application in when you are building your applications. So Android would check that when a new, what do you mean? You mean the updating of the device or updating of your applications? Applications. So when you update your applications, Android would check what is the targeted SDK for that. And if you are telling your target SDK is Android 4.4, Android would check the requesting permissions with the available permissions. And if the available permissions, if your requesting permissions is correspond to the ones in the targeted device or the available in the targeted device, it would grant it. And normally, your application, if your targeted SDK is Android 4.4, it would build with Android 4.4. But it cannot run on a lower SDK device. So the main distinction will come in your targeted SDK. So if your application is targeted for Android 4.0, and if you are installing it on 4.4, where accessing some data was good enough in 4.0 and would require a new permission in the 4.4 case, in that case, Android would think that your targeted SDK is 4.0. And this permission is only available in 4.4. So Android would think, OK, let's grant it automatically. So that is being mentioned in Android Security Gates. So I think that would answer your question. I'll be here afterwards also. Only one last question, please. I am trying to get a permission by installing it. And it won't have any permissions after the runtime. So in this scenario, if app A is defining a permission and app B is using a permission, if I install app B first, and then app A, then how it will be? Yeah, definitely Android would not indicate the user that the application has requested this API, but it didn't mention it in permission list. What would happen is a security exception will happen. Android will tell you that the application has been force closed. And if you look at the Android logs, you can see a security exception. So that is the way it would work. It would not indicate to the user that this application requires an additional permission which was not listed when it was installing. So was that your question? So there are a lot of security experts are questioning the way Android is assigning the permissions. But Android gives very good explanation in their security gates to have the permission seen this way. Like when you install your application, you request all the permissions forever. So that is mainly for the simplicity for the user. OK, thank you.