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

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

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)

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.

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.

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.

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

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

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>

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.

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.

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.

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>

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

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

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.

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

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.

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

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

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

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

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

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

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

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

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

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

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 actionto make itself open to public • An system action string that only the system can add may be injected

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

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

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.

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.

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.

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.

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.

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.

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 over Bluetooth device. Attack would have access to all data on the Bluetooth enabled device, bluesnarfing

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 ﬁngerprints. Phone identifiers, specially the IMEI, are used to track individual users. Phone identifiers are sent to advertisement and analytics servers.

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

Android Security Architecture