1. Android Security Architecture
Security goals
Protect user data
Protect system resources (hardware, software)
Provide application isolation
Foundations  of  Android  Security    
Application  Isolation  and  Permission Requirement
Mandatory application sandbox for all applications
Secure inter-process communication
System-built and user-defined permissions
Application signing

3. Android software stack
Each component assumes that the components below are properly secured.
All code above the Linux Kernel is restricted by the Application Sandbox
Linux  kernel  is  responsible sandboxing application
“mutually distrusting principals”
Default access to only its own data
The  app Sandbox apps  can  talk  to other  apps  only via   Intents (message) , IPC, and ContentProviders
To  escape sandbox,  permissions is needed

4. 1. Security at the Linux kernel
A user-based permissions model
Process isolation: Each application has its sandbox based on separation of processes: to protect user resources from each another; each runs in its own Linux process to secure Inter-Process communication (IPC)
Ex:
Prevents user A from reading user B's files
Ensures that user A does not access user B's CPU, memory resources
Ensures that user A does not access user B's devices (e.g. telephony, GPS, Bluetooth)

5. Application Sandbox
The Android system assigns a unique user ID (UID) to each Android application and runs it as that user in a separate process.
When launching a new Activity, the new process isn’t going to run as the launcher but with its own identity with the permission specified by the developer.
The developer of that application has ensured that it will not do anything the phone’s user didn’t intend. Any program can ask Activity Manager to launch almost any other application, which runs with that application’s UID.
Ex. application A is not allowed to do something malicious like to read application B's data or dial the phone without permission.
All libraries, application runtime, and all applications run within the Application Sandbox in the kernel.

6. Permissions and Encryption
In Android, each application runs as its own user. Unless the developer explicitly exposes files to other applications, files created by one application cannot be read or altered by another application.
Password Protection
Android can require a user-supplied password prior to providing access to a device. In addition to preventing unauthorized use of the device, this password protects the cryptographic key for full file system encryption.

7. Encryption Encryption
Android 3.0+ provides full filesystem encryption, so all user data can be encrypted in the kernel
For a lost or stolen device, full filesystem encryption on Android devices uses the device password to protect the encryption key, so modifying the bootloader or operating system is not sufficient to access user data without the user’s device password.

8. 2. Android Application Security (Application framework)
Almost all Android applications are written in the Java and run in the Dalvik virtual machine. However, applications can also be written in native code.
.java -> .class -> .jar -> .dex
Android application deployed in a single .apk file.
Android middleware is based on the Linux kernel. It provides several native libraries and a Dalvik virtual machine (DVM) instead of Java virtual machine (JVM) for its applications’ runtime environment where application isolation is enforced.
The Java written Android middleware provides development APIs, the system service, all basic phone device functionalities

9. Configurations of Android applications
The AndroidManifest.xml file is the configuration file of Android application.
It specifies the components in the application and external libraries it uses.
It tells the system what to do with activities, services, broadcast receivers, and content providers in an application.
It declares permissions it requests as well as permissions that are defined to protect its own components. The client must be granted such permission in order to run the application.
Without user’s consent application will not be installed

10. Android Security Basics - Android Manifest
Applications have no permission required by default
Each application can declare the requiRED permissions
<?xml version="1.0" encoding="utf-8"?> <manifest >     <application >         <activity android:name="com.example.project.myActivity"           <intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
                                  </activity> <activity> ….. </activity>
     <uses-permission android:name="android.permission.SEND_SMS" />
<uses-permission android:name="android.permission.INTERNET" />     </application> </manifest>

11. Android Permission Model
Permissions are the core concepts in the Android security to control the access from one application component to another.
All permissions are set at installation time and can’t change until the application is reinstalled.
Android’s permission only restricts components
from accessing resources
E.g. an application needs the READ_CONTACTS permission to read the user’s address book
If a public component doesn’t explicitly declare any access permission, Android permits any application to access it.

12. All sensitive APIs listed below are intended for use by trusted applications and protected through Permissions such as functions for camera, bluetooth, telephony, SMS/MMS, network connections
All permissions are granted at install-time.
In order to be granted a permission, it should be requested in the Android manifest file when specifying properties for an application, system then evaluates it and makes a final decision on whether to grant or deny.
After the application has been launched, permission checks are enforced before the actual access take place.
If the user continues the installation, the system grants all requested permissions. The user can not grant or deny partial permissions afterwards.
More than 60 system built-in permissions defined in the form of android.Manifest.permission.X, where X is the name of a particular permission.
The system default permissions are described at

13. Create app’s own permissions (called dynamic permissions in Android) through permission declaration in AndroidManifest.xml.
permission declaration <permission> is the place where developers are able to define their own permissions for protecting their application-specific APIs or components.
The name of permission needs to be globally unique and descriptive so that other components are able to know and request it by name.
<use-permission> lets the developer to request a permission so they get access to certain functionalities in the system. It could either be a built-in permission or a dynamic permission. All permissions should be requested explicitly.
Once granted, the permissions are applied to the application as long as it is installed. Permissions are removed if an application is uninstalled, so a subsequent re-installation will start over again permission request.
Users are able to view permissions and can also turn off some functionality globally when they choose, such as disabling GPS, Radio, or, SMS, Wi-Fi.

14. Built-in Permission
Default  Android  Permissions  Policy:  No  app  can  do  anything  to adversely  Install/uninstall/modify  other  apps, use  other  apps  private  components, access  network, users  data  (contacts,  SMS,   ),  
use  cost sensitive  APIs  (phone  calls,  send  SMS, …)  
Built-in  Android  Permissions  
CALL_PHONE,  CAMERA,   INTERNET,   READ_CONTACTS,  
READ_LOGS,  READ_SMS,  RECEIVE_SMS,  R SEND_SMS, WRITE_SMS 
Caller must have a certain permission
e.g., <uses-permission android:name="android.permission.CALL_PHONE">
</uses-permission>

15. The protection level From weak to strong:
Normal
Normal permissions are the default setting If the protection level is not specified, providing the weakest protections.
They are often used to protect less security-critical functionalities. the permission is assumed to be normal. When a normal permission is requested, the system grants it without asking users.
Dangerous
Permissions at this level might ask for accessing the user privacy or certain hardware service. An example for dangerous permissions is asking for accessing some functionalities cost money.
When an application requests a dangerous permission, the system shows the permission information in a screen to users and users need to accept all permissions if they want to install the application on their phones.
Granted during installation, requires user approval

16. Signature
Decided by the system without the users’ involvement. To be granted a signature permission, the requesting application must be signed by the same key as the application that the permission protects.
Granted only if requesting app is signed by the same developer that defined the permission
Useful for restricting component access to those apps under the control of the same developer
SignatureOrSystem
Granted if requesting app meets the Signature requirement OR if app is installed in the system application folder

17. 3. Security for Inter-Process Communication
In addition to any Linux-type process communication mechanisms such as file system, local sockets, signals Android provides new IPC mechanisms:
3.1 Binder
Remote procedure call( RPC) mechanism (Remote method invocation) designed for in-process and cross-process calls.
Secured by caller permission or identity check.

18. Cont.
AIDL (Android Interface Definition Language) is an IDL language used to generate code that enables two processes on an
Android-powered device to talk using inter-process communication (IPC).
Ex. an Activity needs to call methods on an object in another process (for example, a service), you would use AIDL to generate code to marshall the parameters.
The AIDL IPC mechanism is interface-based, similar to COM or CORBA, but lighter weight. It uses a proxy class to pass values between the components

19. 3.2. Intents
An Intent is a simple notification message object that represents an "intention" to do something.
It is serialized when it is sent. The message consists of the data together with the action operation that will be performed.
Intent filters are used to filter out unwanted intents so that users are informed by interested ones only.
For example, if your application wants to display a web page, it expresses its "Intent" to view the URL by creating an Intent instance and handing it off to the system. The system locates the Browser that knows how to handle that Intent, and runs it; or to broadcast interesting events (such as a notification) system-wide.

20. Cont. Intent: notification from one process to another
directed intent: has one specific recipient
broadcast intent: can be received by anyone
intent filter: a list of intents an activity/service is
interested in
for example, a application wants to make a phone call:
Intent myCallIntent = new
Intent(Intent.Action_CALL);
myCallIntent.setData(Uri.parse(“tel: ”);
startActivity(myCallIntent);

21. Cont.
“Three of the core components of an application — activities, services, and broadcast receivers — are activated through messages, called intents. Intent messaging is a facility for late run-time binding between components in the same or different applications.”
“The Android system finds the appropriate activity, service, or set of broadcast receivers to respond to the intent, instantiating them if necessary”.

22. Cont.
Broadcast intents are delivered only to broadcast receivers, never to activities or services. An intent passed to startActivity() is delivered only to an activity never to a service or broadcast receiver,
Intent messages contain a recipient and data (optional) which Link applications and form the foundation of the message passing system
Used for intra- and inter-app communication and system-wide notifications (system broadcast Intents)
Are divided to explicit and implicit components
Explicit: specifies a definite application
Implicit: specifies a kind or categories

23. Intent action constant
ACTION_CALL to Activity: Initiate a phone call
ACTION_EDIT to Activity: Display data for the user to edit
ACTION_MAIN to Activity: Start of a task
ACTION_BATTE RY_LOW to Broadcast receiver: A warning on low battery

24. Intent in IPC
Activities, Services, and Broadcast Receivers can send/receive Intents
Intents (explicit & implicit) can
Start Activities
Start, stop, and bind Services
Broadcast information to Broadcast Receivers
To receive Intents, component must be declared in the manifest
By default, components can only receive internal Intents
Asynchronous comm.
Not secured on the carried data

25. Intent Filters
To inform the system which implicit intents they can handle, activities, services, and broadcast receivers can have one or more intent filters.
Each filter describes a capability of the component, a set of intents that the component is willing to receive.
It filters intents of a desired type, while filtering out unwanted intents
Activity with intent filter enabled is “exported” out

26. 3.3 Security Risks in Android’s Inter-Application
Attacker can intercept the message If sender does not correctly specify recipient,
can hijack activity, service, broadcast via intent to lead to a malicious target
Attacker can inject code If Component does not restrict from whom it can receive messages

27. Attacks Only consider attacks on exported components
Consider non-exported components and exported components with a Signature (or higher) permission level to be private and not susceptible to the below attacks
Type 1 - Intents sent to the wrong application
Can leak data
Broadcast theft, activity and service hijacking
Type 2 – Receiving external Intents
Data corruption, code injection
Malicious broadcast injection, malicious activity launch, malicious service launch 27

28. Type 1 – Broadcast Theft
Broadcasts (via implicit Intent) vulnerable to eavesdropping and denial of service attacks
Eavesdropping
A public broadcast can be intercepted by attacker because a loose intent filter leaves a hole and no confirmation checking

29. Ordered broadcast vulnerable
Denial of Service
Ordered broadcast vulnerable
Attacker resets its priority to highest level to alter the broadcast receiving order which can cancer or inject malicious code or data

30. Type 1 – Activity and Service Highjacking
Malicious a/service is activated instead of desired components such as by Phishing
Android will select a best matched one If multiple activities have the same Intent filter spec so that The attacker may return malicious code or data to the user

31. Type 2 – Malicious Injection
Activity
A malicious activities can be activated by Intents (explicit or implicit) as results of injection
tamper data or Leak sensitive information
Broadcast
Broadcast receivers registers with a malicious broadcast provider and take system action to make itself open to public
An system action string that only the system can add may be injected

32. Some Recommendations
Use caution with implicit Intents and exporting Components
Use explicit Intents to send private data
Use explicit Intents for internal communication
Returned results should be checked for authenticity
Avoid exporting Components
The same Component should not handle both internal and external Intents
Section 3.3 32

33. Android developers should securing user data and avoiding the introduction of security vulnerabilities. Always assign a least permission to a application
Cost-Sensitive APIs
A cost sensitive API is any function that might generate a cost for the user or the network. The Android platform has placed cost sensitive APIs in the list of protected APIs controlled by the OS. The user will have to grant explicit permission to third-party applications requesting use of cost sensitive APIs for SIM Card Access, Device Metadata, Sensitive Data via Input Devices or Personal Information
These APIs include:
Telephony
SMS/MMS
Network/Data
In-App Billing

34. 4. Application Signing
Code signing allows developers to identify the author of the application and to update their application without creating complicated interfaces and permissions.
Every application that is run on the Android must be signed by the developer.
Applications that attempt to install without being signed will rejected by either Google Play or the package installer on the Android device.

35. On Android, application signing is the first step to placing an application in its Application Sandbox. The signed application certificate defines which user id is associated with which application; different applications run under different user IDs.
Application signing ensures that one application cannot access any other application except through well-defined IPC.
When an application (APK file) is installed onto an Android device, the Package Manager verifies that the APK has been properly signed with the certificate included in that APK.
If the certificate (or, more accurately, the public key in the certificate) matches the key used to sign any other APK on the device, the new APK has the option to specify in the manifest that it will share a UID with the other similarly-signed APKs.

36. Android requires every application to be signed
Android requires every application to be signed. The main purpose of application signing is to distinguish applications from one to another.
Developers sign apps with their own private keys. The private keys are supposed to stay secret and known only to their owners.
After a signed application is installed on the phone, the system is able to use its signature information to distinguish it from other application.

37. Signature protection level
Signature shows app persistence:
Check: app is changed or updated with diff sig.
Signature shows the authorship and trust for application
All Android applications must be signed, but are self-signed
Why self signing? Market ties identity to developer account
No applications are trusted.

38. Android App Signature What does signing determine?
Shared UID for shared keys
Self-updates
Google doest not have central control over the app’s signature certificates
creates chain of trust between updates and among applications
In signature schemes, the private key is used to sign a app or message; anyone can check the signature using the public key.

39. Cont. All .apk files must be signed with a certificate
identifies the author of the application.
does not need to be signed by a certificate authority
allows the system to grant or deny applications
access to signature-level permissions
request to be given the same Linux identity as another application.
If the public key matches the key used to sign any other APK, the new APK may request to share a UID with the other APK.

40. SMS Vulnerabilities SMS Short Messaging System
Very commonly used protocol
Used to send "Text Messages"
GSM uses 2 signal bands, 1 for "control", the other for "data".
SMS operates entirely on the "control" band.
High volume text messaging can disable the "control" band, which also disables voice calls.
Can render entire city 911 services unresponsive.

41. Bluetooth Vulnerabilities
Short range wireless communication protocol
Used in many personal electronic devices
Requires no authentication
An attack, if close enough, could take over Bluetooth device.
Attack would have access to all data on the Bluetooth enabled device, bluesnarfing

42. Information Misuse by Apps
Phone identifiers: phone number, IMEI (device identifier), IMSI (subscriber identifier), and ICC-ID (SIM card serial number).
Phone identifiers are frequently leaked through plaintext requests.
Phone identifiers are used as device fingerprints.
Phone identifiers, specially the IMEI, are used to track individual users.
Phone identifiers are sent to advertisement and analytics servers.

43. Reference Android Security, CEG436: Mobile Computing Prabhaker Mateti
Android Security Overview, source.android. com/tech/security/
Nils, “Building Android Sandcastles in Android’s Sandbox,” Oct 2010, BlackHat
William Enck, Damien Octeau, Patrick McDaniel, and Swarat Chaudhuri, “A Study of Android Application Security”, 20th USENIX Security, Aug 2011
Android Security Overview
“Analyzing Inter-Application Communication in Android” by Chin, Felt, Greenwood, and Wagner (UC Berkeley)
Donald E Frederick, Android’s Inter-Application Model and Security Risks, 8/20/2012