Android Security
Download as PPT, PDF10 likes1,735 views
This document provides an overview of Android security. It discusses Android's architecture including activities, services, content providers and broadcast receivers. It then covers Android security features like application sandboxing, application signing, and Android's permission model. It provides examples of how these components and security features work together in a sample Android application for tracking friends' locations. It also discusses how applications can programmatically enforce permissions and how application components interact through intents.
Android Security
- 1. UUnnddeerrssttaannddiinngg AAnnddrrooiidd SSeeccuurriittyy Suminda Gunawardhana
- 2. OOuuttlliinnee I. Introduction II. Android Architecture III. Android Security IV. Android Applications V. Security Enforcement VI. Security Refinements VII. Lessons in Defining Policy VIII. Google Newly release Security Feature IX. Development process Best practices X. Hybrid Mobile App’ Data store security
- 3. IInnttrroodduuccttiioonn • Android is a Linux-based open-source operating system by Google for mobile devices such as smart phones and tablets. • Android owns 84.6% share of global smart phone market by Q2, 2014 after being launched in 2007. • Developers can develop free or paid apps for Android using Android SDK. • Developers can use public APIs, without having any knowledge of Android internals, to make use of device features and services provided by Android.
- 4. IInnttrroodduuccttiioonn • Android has employed various mechanisms like application sandboxing, application signing, permission model, etc. to enhance the security in Android. • Android protects system features (accessed using APIs) by assigning them permissions.
- 6. AAnnddrrooiidd AArrcchhiitteeccttuurree Activity Activity is a screen or window (UI) which is displayed to the user for interaction purpose. Only one activity has a focus at a time. An application can have many activities used to implement different functionalities (UIs). One activity may start another activity and wait for that activity to finish to get back the result.
- 7. AAnnddrrooiidd AArrcchhiitteeccttuurree Service • Service is equivalent to background process which is invisible to the user. • Other components can bind to the service and get the result back using remote procedure call (RPC) mechanism.
- 8. AAnnddrrooiidd AArrcchhiitteeccttuurree Content Provider • Content Providers can perform sql-like operations, e.g. SELECT, UPDATE, DELETE, INSERT on the underlying sqlite databases. • Content Provider can define two permissions labels to protect read and write access separately.
- 9. AAnnddrrooiidd AArrcchhiitteeccttuurree Broadcast Receiver • A Broadcast Receiver component is an asynchronous event mailbox for Intent messages ‘broadcasted’ to an action string . • Application developers can add broadcast receiver in their applications to receive events occurring at system-level. • Applications can also create broadcast receivers at runtime (that do not appear in manifest file), called as dynamic Broadcast Receiver.
- 10. AAnnddrrooiidd SSeeccuurriittyy Application Sandboxing • Every application gets a unique user identifier (UID) at the time of installation. • Linux kernel is responsible for enforcing access control on the resources of the system. • Hence, one application cannot access other application’s files unless they are marked as world-wide readable. • Also, every application is run into separate VMs. It implies that the vulnerability found in one application will not affect remaining applications.
- 11. AAnnddrrooiidd SSeeccuurriittyy Application Signing • Android requires every application to be signed, not necessarily from third party certificate authority. • Application developers can sign their own applications. ◦ This allows Android to build trust relationships among applications from same developer.
- 12. AAnnddrrooiidd SSeeccuurriittyy Application Signing • If two applications are signed using same certificate and they ask for same shared UID, then either of the application can use permissions granted to other application.
- 13. AAnnddrrooiidd SSeeccuurriittyy Permission Model • The permissions model is based on permissions, which are constructs that various APIs require calling apps to have before they will provide certain services. • Applications must declare (in their manifest) which permissions they request/require. When an application is installed, the Android system will present this list to the user and the user must decide to allow the installation or not.
- 14. AAnnddrrooiidd SSeeccuurriittyy Permission Model • This is an all-or-nothing decision; the user can install the app or not, but cannot choose to install it with reduced permissions. • This imparts a significant responsibility to both the developer (to accurately specify required permissions) and the user (to understand the risk involved and make an informed decision).
- 15. AAnnddrrooiidd SSeeccuurriittyy Permission Model • The Android permissions model was designed with two fundamental goals. • 1.Inform the User – By listing all “sensitive” operations that an application could perform, the user is more aware of the risks involved in installing the application. This assumes that the user will actually read the permission dialog and make a rationale yes/no install decision based on that information, which may or may not be true.
- 16. AAnnddrrooiidd SSeeccuurriittyy Permission Model 2.Mitigate Exploits – By limiting application access to sensitive APIs, the ability of an attacker to cause damage if an application is successfully exploited is somewhat mitigated. • Most system permissions are all-or-nothing, by design. For example, an app gets unlimited Internet access or none at all.
- 17. AAnnddrrooiidd SSeeccuurriittyy Specifying Required Permissions. • Making use of a system API that requires a permission simply requires you to specify that permission in your application’s manifest (AndroidManifest.xml). • For example, if you application needs access to the Internet, specify the INTERNET permission.
- 18. AAnnddrrooiidd SSeeccuurriittyy Specifying Required Permissions. <manifest xmlns:android=“http://schemas.android.com/apk/res/and roid” package=“com.example.testapps.test1”> … <uses-permission android:name=“android.permission.INTERNET” /> … </manifest>
- 19. AAnnddrrooiidd SSeeccuurriittyy Permission Levels • Normal – These permissions cannot impart real harm to the user (e.g. change the wallpaper) and, while apps need to request them, they are automatically granted. • Dangerous – These can impart real harm (e.g. call numbers, open Internet connections, etc) and apps need to request them with user confirmation. • Signature – These are automatically granted to a requesting app if that app is signed by the same certificate (so, developed by the same entity) as that which declared/created the permission. This level is designed to allow apps that are part of a suite, or otherwise related, to share data.
- 20. AAnnddrrooiidd SSeeccuurriittyy Permission Levels Signature/System – Same as Signature, except that the system image gets the permissions automatically as well. This is designed for use by device manufacturers only.
- 21. AAnnddrrooiidd SSeeccuurriittyy Custom Permissions • Custom permissions can be used by developers to restrict access to various services/components. • Any application that interacts with another application’s component would need to possess the required permission for the call to succeed. • First, a permission must be declared/created in an application’s manifest.
- 22. AAnnddrrooiidd SSeeccuurriittyy Custom Permissions <permission android:name=“com.example.perm.READ_INCOMING_MSG” android:label=“Read incoming messages from the EX service.” android:description=“Allows the app to access any messages received by the EX service. Any app granted this permission will be able to read all messages processed by the ex1 application.” android.protectionLevel=“dangerous” android:permissionGroup=“android.permission-group. PERSONAL_INFO” />
- 23. AAnnddrrooiidd SSeeccuurriittyy Enforcing Permissions Programmatically • Applications can check to see if calling apps have permissions programmatically. int canProcess = checkCallingPermission( “com.example.perm.READ_INCOMING_MSG”); If(canProcess != PERMISSION_GRANTED) throw new SecurityException(); • This will ensure that the calling process (via IPC) has the necessary permission. There are other forms of this call that can check to see if a specific PID/UID combination has a certain permission or if a specific package has that permission.
- 24. Android AApppplliiccaattiioonnss ------ EExxaammppllee Example of location-sensitive social networking application for mobile phones in which users can discover their friends’ locations. Activities provide a user interface, Services execute background processing, Content providers are data storage facilities, and Broadcast receivers act as mailboxes for messages from other applications.
- 25. Android AApppplliiccaattiioonnss ------ EExxaammppllee AApppplliiccaattiioonn((ccoonntt..)) Take FriendTracker application for example, FriendTracker (Service) polls an external service to discover friends’ locations FriendProvider (Content provider) maintains the most recent geographic coordinates for friends FriendTrackerControl (Activity) defines a user interface for starting and stopping the tracking functionality BootReceiver (Broadcast receiver) gets a notification from the system once it boots (the application uses this to automatically start the FriendTracker service).
- 26. Android AApppplliiccaattiioonnss------ CCoommppoonneenntt IInntteerraaccttiioonn • Intent - is the primary mechanism for component interaction, which is simply a message object containing a destination component address and data • Action - the process of inter-components communication
- 27. Android AApppplliiccaattiioonnss------ CCoommppoonneenntt IInntteerraaccttiioonn ((ccoonntt..)) Example: Interaction between components in applications and with components in system applications. Interactions occur primarily at the component level.
- 28. Android AApppplliiccaattiioonnss------ CCoommppoonneenntt IInntteerraaccttiioonn ((ccoonntt..)) Each component type supports interaction specific to its type. For example, Service components support start , stop, and bind actions, so the FriendTrackerControl (Activity) can start and stop the FriendTracker (Service) that runs in the background.
- 29. SSeeccuurriittyy EEnnffoorrcceemmeenntt Android protect application at system level and at the Inter-component communication (ICC) level. Each application runs as a unique user identity, which lets Android limit the potential damage of programming flaws.
- 30. SSeeccuurriittyy EEnnffoorrcceemmeenntt ((ccoonntt..)) Example: Protection. Security enforcement in Android occurs in two places: each application executes as its own user identity, allowing the underlying Linux system to provide system-level isolation; and the Android middleware contains a reference monitor that mediates the establishment of inter-component communication (ICC).
- 31. SSeeccuurriittyy EEnnffoorrcceemmeenntt ((ccoonntt..)) • Core idea of Android security enforcement - labels assignment to applications and components • A reference monitor provides mandatory access control (MAC) enforcement of how applications access components. • Access to each component is restricted by assigning it an access permission label; applications are assigned collections of permission labels. • When a component initiates ICC, the reference monitor looks at the permission labels assigned to its containing application and— if the target component’s access permission label is in that collection— allows ICC establishment to proceed.
- 32. SSeeccuurriittyy EEnnffoorrcceemmeenntt ((ccoonntt..)) Example: Access permission logic. The Android middleware implements a reference monitor providing mandatory access control (MAC) enforcement about how applications access components. The basic enforcement model is the same for all component types. Component A’s ability to access components B and C is determined by comparing the access permission labels on B and C to the collection of labels assigned to application 1.
- 33. Security EEnnffoorrcceemmeenntt -- CCoonncclluussiioonn Assigning permission labels to an application specifies its protection domain. Assigning permissions to the components in an application specifies an access policy to protect its resources. Android’s policy enforcement is mandatory, all permission labels are set at install time and can’t change until the application is reinstalled. Android’s permission label model only restricts access to components and doesn’t currently provide information flow guarantees.
- 34. R Security Reeffiinneemmeennttss ------ PPuubblliicc vvss.. PPrriivvaattee CCoommppoonneennttss Applications often contain components that another application should never access. For example, component related to password storing. The solution is to define private component. This significantly reduces the attack surface for many applications.
- 35. SSeeccuurriittyy RReeffiinneemmeennttss ------ IImmpplliicciittllyy OOppeenn CCoommppoonneennttss At development time, if the decision of access permission is unclear, The developer can permit the functionality by not assigning an access permission to it. If a public component doesn’t explicitly have an access permission listed in its manifest definition, Android permits any application to access it.
- 36. R Security Reeffiinneemmeennttss ------ BBrrooaaddccaasstt IInntteenntt PPeerrmmiissssiioonnss Sending the unprotected intent is a privacy risk. Android API for broadcasting intents optionally allows the developer to specify a permission label to restrict access to the intent object.
- 37. R Security Reeffiinneemmeennttss ------ CCoonntteenntt PPrroovviiddeerr PPeerrmmiissssiioonnss If the developer want his application to be the only one to update the contents but for other applications to be able to read them. Android allows such a security policy assigning read or write permissions.
- 38. R Security Reeffiinneemmeennttss ------ PPrrootteecctteedd AAPPIIss Not all system resources(for example, network) are accessed through components— instead, Android provides direct API access. Android protects these sensitive APIs with additional permission label checks: an application must declare a corresponding permission label in its manifest file to use them.
- 39. R Security Reeffiinneemmeennttss ------ PPeerrmmiissssiioonn PPrrootteeccttiioonn LLeevveellss The permission protection levels provide a means of controlling how developers assign permission labels. Signature permissions ensure that only the framework developer can use the specific functionality (only Google applications can directly interface the telephony API, for example).
- 40. R Security Reeffiinneemmeennttss ------ PPeennddiinngg IInntteennttss Pending intent - a developer defines an intent object to perform an action. However, instead of performing the action, the developer passes the intent to a special method that creates a PendingIntent object corresponding to the desired action. The PendingIntent object is simply a reference pointer that can pass to another application. Pending intents allow applications included with the framework to integrate better with third-party applications.
- 41. Lessons iinn DDeeffiinniinngg PPoolliiccyy Android security policy begins with a relatively easy-to-understand MAC enforcement model, but the number and subtlety of refinements make it difficult to discover an application’s policy. The label itself is merely a text string, but its assignment to an application provides access to potentially limitless resources.
- 42. GGooooggllee NNeewwllyy rreelleeaassee SSeeccuurriittyy FFeeaattuurree Android sandbox reinforced with SELinux ◦ Android 4.3 now includes SELinux, a mandatory access control (MAC) system in the Linux kernel to augment the Unique Identification Number (UID) based application sandbox. ◦ This makes almost all apps with the Android sandbox much more secure
- 43. GGooooggllee NNeewwllyy rreelleeaassee SSeeccuurriittyy FFeeaattuurree ◦ Some users are wary of SELinux, since the NSA had a large hand in creating it . Since SELinux, just like all of Linux, is open source. After all, the code is right in plain sight for anyone to look for security holes.
- 44. GGooooggllee NNeewwllyy rreelleeaassee SSeeccuurriittyy FFeeaattuurree KeyChain enhancements ◦ If you're still worried about the NSA snooping on your messages you'll be happy to see Google's new KeyChain API provides a method that enables applications to confirm that system-wide keys are bound to a hardware root of trust. ◦ This means that carrier and OEM developers can add private keys that cannot be copied off the device, even if it's otherwise completely compromised.
- 45. GGooooggllee NNeewwllyy rreelleeaassee SSeeccuurriittyy FFeeaattuurree ◦ This won't stop the NSA -- or most major Internet companies -- from using big data, metadata, and traffic analysis to keep an eye on you, but it will eventually help to keep the contents of your messages and apps secure.
- 46. GGooooggllee NNeewwllyy rreelleeaassee SSeeccuurriittyy FFeeaattuurree Android Keystore Provider ◦ At the same time, Android 4.3 also introduces a key store provider and APIs that allow applications to create exclusive-use keys. ◦ What that means is that apps can create or store private keys that no other app can see or use.
- 47. GGooooggllee NNeewwllyy rreelleeaassee SSeeccuurriittyy FFeeaattuurree Restrict Setuid from Android Apps ◦ Your device's /system partition is now mounted "nosuid" for Zygote-spawned processes. ◦ This helps prevent Android applications from executing setuid programs. ◦ In turn, this reduces root attack surface and likelihood of potential security vulnerabilities. ◦ In English, this means malicious apps will have a much harder time trying to take over your device's super user/root privileges.
- 48. GGooooggllee NNeewwllyy rreelleeaassee SSeeccuurriittyy FFeeaattuurree ◦ Restricted Profile Play video
- 49. GGooooggllee NNeewwllyy rreelleeaassee SSeeccuurriittyy FFeeaattuurree Wi-Fi support for WPA2-Enterprise networks ◦ New application programming interfaces (API)s can now be used configure the Wi-Fi credentials needed for connections to access points using WPA2 enterprise with Extensible Authentication Protocol (EAP) and Encapsulated EAP (Phase 2). ◦ With this, developers will be able to create apps that can join business Access Points (APs) that use EAP and Phase 2 authentication methods.
- 50. DDeevveellooppmmeenntt pprroocceessss BBeesstt pprraaccttiicceess Source code security review Source code review can detect a broad range of security issues, including those identified in this document. Android strongly encourages both manual and automated source code review. • Android Lint should be run on all application code using the Android SDK.
- 51. DDeevveellooppmmeenntt pprroocceessss BBeesstt pprraaccttiicceess Automated testing Automated testing can detect a broad range of security issues, including many of those identified in this document. 1) CTS is regularly updated with security tests; the most recent version of CTS must be run to verify compatibility. 2) CTS should be run regularly throughout the development process to detect problems early and reduce time to correction. 3) OEMs should automate security testing of any interfaces including testing with malformed inputs (fuzz testing).
- 52. DDeevveellooppmmeenntt pprroocceessss BBeesstt pprraaccttiicceess Signing system images The signature of the system image is critical for determining the integrity of the device. Specifically 1) Devices must not be signed with a key that is publicly known.. 2) Keys used to sign devices should be managed in a manner consistent with industry standard practices for handling sensitive keys, including a hardware security module (HSM) that provides limited, auditable access.
- 53. DDeevveellooppmmeenntt pprroocceessss BBeesstt pprraaccttiicceess Signing applications (APKs) Application signatures play an important role in device security. They are used for permissions checks as well as software updates. When selecting a key to use for signing applications, it is important to consider whether an application will be available only on a single device or common across multiple devices. 1) Applications must not be signed with a key that is publicly known. 2) Applications should not be signed with the platform key.
- 54. DDeevveellooppmmeenntt pprroocceessss BBeesstt pprraaccttiicceess Signing applications (APKs) 3). Keys used to sign applications should be managed in a manner consistent with industry standard practices for handling sensitive keys, including an HSM that provides limited, auditable access 4). Applications with the same package name should not be signed with different keys.
- 55. DDeevveellooppmmeenntt pprroocceessss BBeesstt pprraaccttiicceess Apps publishing Google Play provides OEMs with the ability to update applications without performing a complete system update. This can expedite response to security issues and delivery of new features. This also provides a way to make sure that your application has a unique package name.
- 56. DDeevveellooppmmeenntt pprroocceessss BBeesstt pprraaccttiicceess Incident response External parties must have the ability to contact OEMs about device-specific security issues. We strongly recommend the creation of a publicly accessible email address for managing security incidents. 1) Create a [email protected] or similar address and publicize it. 2) If you become aware of a security issue affecting Android OS or Android devices from multiple OEMs, you should contact the Android Security Team at [email protected].
- 57. a Hybrid apppplliiccaattiioonn HHTTMMLL55 LLooccaall ssttoorree//iinnddeexx DDBB SSeeccuurriittyy..
- 58. AAnnddrrooiidd DDeevveellooppeerr PPrreevviieeww.. Play video
- 59. PPoolliiccyy EEnnffoorrcceemmeenntt FFrraammeewwoorrkk ffoorr ccoolllleeggee ssttuuddeennttss If the tablet is being used for conducting quizzes or exams in schools, only the quiz or exam related apps should get open. Any request to start any of the remaining apps should be blocked. During school-time, students can open a limited set of apps. List of allowed apps would be defined by schools (teachers). For example, students should not be able to open social networking apps (like Facebook, Twitter) or gaming apps (like Angry Birds, Temple Run) during school-time (say, 9:00am to 3:30pm).
- 60. QQuueessttiioonn The Android permissions model was designed with two fundamental goals What are the those Two Fundamental goals ?
- 61. MMyy WWoorrddss The next generation of open operating systems won’t be on desktops or mainframes but on the small mobile devices we carry every day. The openness of these new environments will lead to new applications and markets and will enable greater integration
- 62. Thank You