•Process isolation: Each application has its sandboxbased on separation of processes: to protect userresources from each another; each runs in its own Linuxprocess 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)

Application Sandbox

•The Android system assigns a unique user ID (UID) toeach Android application and runs it as that user in aseparate process.

•When launching a newActivity, the new process isn’tgoing to run as the launcher but with its own identity withthe permission specified by the developer.

•The developer of that application has ensured that it willnot do anything the phone’s user didn’t intend. Anyprogram can ask Activity Manager to launch almost anyother application, which runs with that application’s UID.

•Ex. application A is not allowed to do somethingmalicious like to read application B's data or dial thephone without permission.

•All libraries, application runtime, and all applications runwithin the Application Sandbox in the kernel.

Permissions and Encryption

•Permissions

In Android, each application runs as its ownuser. Unless the developer explicitly exposesfiles to other applications, files created by oneapplication cannot be read or altered by anotherapplication.

•Password Protection

Android can require a user-supplied passwordprior to providing access to a device. In additionto preventing unauthorized use of the device,this password protects the cryptographic key forfull file system encryption.

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 filesystemencryption on Android devices uses the devicepassword to protect the encryption key, somodifying the bootloader or operating system isnot sufficient to access user data without theuser’s device password.

2. Android Application Security

(Application framework)

•Almost all Android applications are written in the Javaand 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. Itprovides several native libraries and a Dalvik virtualmachine (DVM) instead of Java virtual machine (JVM)for its applications’ runtime environment whereapplication isolation is enforced.

•All sensitive APIs listed below are intended for use by trustedapplications and protected through Permissions such as functionsfor 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 theAndroid manifest file when specifying properties for an application,system then evaluates it and makes a final decision on whether togrant or deny.

•After the application has been launched, permission checks areenforced before the actual access take place.

•If the user continues the installation, the system grants all requestedpermissions. The user can not grant or deny partial permissionsafterwards.

•More than 60 system built-in permissions defined in the form ofandroid.Manifest.permission.X, where X is the name of a particularpermission.

•The system default permissions are described athttps://developer.android.com/reference/android/Manifest.permission.html.

•Create app’s own permissions (calleddynamicpermissions

in Android) through permission declarationin AndroidManifest.xml.

•permission declaration <permission>

is the place wheredevelopers are able to define their own permissions forprotecting their application-specific APIs or components.

•The name of permission needs to be globally unique anddescriptive so that other components are able to knowand request it by name.

•<use-permission>

lets the developer to request apermission so they get access to certain functionalities inthe system. It could either be a built-in permission or adynamic permission. All permissions should berequested explicitly.

•Once granted, the permissions are applied to theapplication as long as it is installed. Permissions areremoved if an application is uninstalled, so a subsequentre-installation will start over again permission request.

•Users are able to view permissions and can also turn offsome functionality globally when they choose, such asdisabling GPS, Radio, or, SMS, Wi-Fi.

Built-in Permission

•Default

Android

Permissions

Policy:

No

app

can

do

anything

toadversely

Install/uninstall/modify

other

apps,use

other

apps

private

components, access

network,users

data

(contacts,

SMS,

email),

use

costsensitive

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-permissionandroid:name="android.permission.CALL_PHONE">

</uses-permission>

The protection level From weak to strong:

Normal

•Normal permissions are the default setting If theprotection level is not specified, providing the weakestprotections.

•They are often used to protect less security-criticalfunctionalities. the permission is assumed to be normal.When a normal permission is requested, the systemgrants it without asking users.

•When an application requests a dangerous permission,the system shows the permission information in a screento users and users need to accept all permissions if theywant to install the application on their phones.

•Granted during installation, requires user approval

Signature

•Decided by the system without the users’involvement. To be granted a signaturepermission, the requesting application must besigned by the same key as the application thatthe permission protects.

•Granted only if requesting app is signed by thesame

developer that defined the permission

•Useful for restricting component access to thoseapps under the control of the same developer

SignatureOrSystem

Granted if requesting app meets the Signaturerequirement OR if app is installed in the systemapplication folder

3. Security for Inter-ProcessCommunication

In addition to any Linux-type process communicationmechanisms such as file system, local sockets, signalsAndroid provides new IPC mechanisms:

•Ex. an Activity needs to call methods on anobject in another process (for example, aservice), you would use AIDL to generate codeto marshall the parameters.

•The AIDL IPC mechanism is interface-based,similar to COM or CORBA, but lighter weight. Ituses a proxy class to pass values between thecomponents

3.2. Intents

•An Intent is a simple notification message object thatrepresents an "intention" to do something.

•It is serialized when it is sent. The message consists ofthe data together with the action operation that will beperformed.

•Intent filters are used to filter out unwanted intents sothat users are informed by interested ones only.

•For example, if your application wants to display a webpage, it expresses its "Intent" to view the URL bycreating an Intent instance and handing it off to thesystem. The system locates the Browser that knows howto handle that Intent, and runs it; or to broadcastinteresting events (such as a notification) system-wide.

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:123456789”);

startActivity(myCallIntent);

Cont.

•“Three of the core components of an application—

activities, services, and broadcast receivers—

areactivated through messages, calledintents. Intentmessaging is a facility for late run-time binding betweencomponents in the same or different applications.”

•“The Android system finds the appropriate activity,service, or set of broadcast receivers to respond to theintent, instantiating them if necessary”.

Cont.

•Broadcast intents are delivered only to broadcastreceivers, never to activities or services. An intentpassed to startActivity() is delivered only to an activitynever to a service or broadcast receiver,

•Intent messages contain a recipient and data (optional)which Link applications and form the foundation of themessage passing system

•A cost sensitive API is any function that might generate acost for the user or the network. The Android platformhas placed cost sensitive APIs in the list of protectedAPIs controlled by the OS. The user will have to grantexplicit permission to third-party applications requestinguse of cost sensitive APIs for SIM Card Access, DeviceMetadata, Sensitive Data via Input Devices or PersonalInformation

These APIs include:

•Telephony

•SMS/MMS

•Network/Data

•In-App Billing

4. Application Signing

•Code signing allows developers to identify the author ofthe application and to update their application withoutcreating complicated interfaces and permissions.

•Every application that is run on the Android must besigned by the developer.

•Applications that attempt to install without being signedwill rejected by either Google Play or the packageinstaller on the Android device.

•On Android, application signing is the first step to placingan application in its Application Sandbox. The signedapplication certificate defines which user id is associatedwith which application; different applications run underdifferent user IDs.

•Application signing ensures that one application cannotaccess any other application except through well-definedIPC.

•When an application (APK file) is installed onto anAndroid device, the Package Manager verifies that theAPK has been properly signed with the certificateincluded in that APK.

•If the certificate (or, more accurately, the public key inthe certificate) matches the key used to sign any otherAPK on the device, the new APK has the option tospecify in the manifest that it will share a UID with theother similarly-signed APKs.

•Android requires every application to be signed. Themain purpose of application signing is to distinguishapplications from one to another.

•Developers sign apps with their own private keys. Theprivate keys are supposed to stay secret and known onlyto their owners.

•After a signed application is installed on the phone, thesystem is able to use its signature information todistinguish it from other application.

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 areself-signed

•Why self signing? Market ties identity to developeraccount

–No applications are trusted.

Android App Signature

•What does signing determine?

–Shared UID for shared keys

–Self-updates

Google doest not have central control over the app’ssignature certificates

–creates chain of trust between updates and amongapplications

–In signature schemes, the private key is used to signa app or message; anyone can check the signatureusing the public key.

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

•If the public key matches the key used to sign anyother APK, the new APK may request to share aUID with the other APK.

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.

Bluetooth Vulnerabilities

–Bluetooth

•Short range wireless communication protocol

•Used in many personal electronic devices

•Requires no authentication

–An attack, if close enough, could take overBluetooth device.

–Attack would have access to all data on theBluetooth enabled device, bluesnarfing