Understanding 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.

5. AAnnddrrooiidd AArrcchhiitteeccttuurree

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 security@your-company.com 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
security@android.com.

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