android security architecture

43
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

Upload: tulia

Post on 01-Feb-2016

41 views

Category:

Documents


0 download

DESCRIPTION

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 - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Android Security Architecture

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

Page 2: Android Security Architecture
Page 3: Android Security Architecture

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

Page 4: Android Security Architecture

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)

Page 5: Android Security Architecture

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.

Page 6: Android Security Architecture

Permissions and Encryption

• Permissions 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.

Page 7: Android Security Architecture

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.

Page 8: Android Security Architecture

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

Page 9: Android Security Architecture

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

Page 10: Android Security Architecture

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>

Page 11: Android Security Architecture

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.

Page 12: Android Security Architecture

• 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 https://developer.android.com/reference/android/Manifest.permission.html.

Page 13: Android Security Architecture

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

Page 14: Android Security Architecture

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,  email),  

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>

Page 15: Android Security Architecture

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

Page 16: Android Security Architecture

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

Page 17: Android Security Architecture

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. https://developer.android.com/reference/android/os/Binder.html.

Secured by caller permission or identity check.

Page 18: Android Security Architecture

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

Page 19: Android Security Architecture

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.

Page 20: Android Security Architecture

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);

Page 21: Android Security Architecture

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

Page 22: Android Security Architecture

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

Page 23: Android Security Architecture

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

Page 24: Android Security Architecture

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

Page 25: Android Security Architecture

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

Page 26: Android Security Architecture

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

Page 27: Android Security Architecture

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

Page 28: Android Security Architecture

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

Page 29: Android Security Architecture

• 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

Page 30: Android Security Architecture

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

Page 31: Android Security Architecture

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

Page 32: Android Security Architecture

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

Page 33: Android Security Architecture

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

Page 34: Android Security Architecture

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.

Page 35: Android Security Architecture

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

Page 36: Android Security Architecture

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

Page 37: Android Security Architecture

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.

Page 38: Android Security Architecture

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.

Page 39: Android Security Architecture

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.

Page 40: Android Security Architecture

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.

Page 41: Android Security Architecture

Bluetooth Vulnerabilities

– Bluetooth• 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

Page 42: Android Security Architecture

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.

Page 43: Android Security Architecture

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 http://source.android.com/tech/security/index.html• “Analyzing Inter-Application Communication in Android” by Chin,

Felt, Greenwood, and Wagner (UC Berkeley)• http://www.comdroid.org/• Donald E Frederick, Android’s Inter-Application Model and Security

Risks, 8/20/2012