Professional Documents
Culture Documents
Android.com
Home
Topics Dalvik Debugging Encryption Security Input Data Usage Accessories Security Topics Security Overview Android 4.2
Source
Compatibility
Tech Info
Community
About
source.android.com/tech/security/index.html
1/18
4/4/13
In This Document
Android Security Overview Introduction Background Android Security Program Overview Android Platform Security Architecture System and Kernel Level Security Linux Security The Application Sandbox System Partition and Safe Mode Filesystem Permissions Cryptography Memory Management Security Enhancements Rooting of Devices User Security Features Filesystem Encryption Password Protection Device Administration Credential Storage Virtual Private Network Android Application Security Elements of Applications The Android Permission Model: Accessing Protected APIs How Users Understand Third-Party Applications Interprocess Communication Cost-Sensitive APIs SIM Card Access Personal Information Sensitive Data Input Devices Device Metadata Application Signing Application Verification Digital Rights Management Android Updates Other Resources
4/4/13
Android is a modern mobile platform that was designed to be truly open. Android applications make use of advanced hardware and software, as well as local and served data, exposed through the platform to bring innovation and value to consumers. To protect that value, the platform must offer an application environment that ensures the security of users, data, applications, the device, and the network. Securing an open platform requires a robust security architecture and rigorous security programs. Android was designed with multi-layered security that provides the flexibility required for an open platform, while providing protection for all users of the platform. Android was designed with developers in mind. Security controls were designed to reduce the burden on developers. Security-savvy developers can easily work with and rely on flexible security controls. Developers less familiar with security will be protected by safe defaults. Android was designed with device users in mind. Users are provided visibility into how applications work, and control over those applications. This design includes the expectation that attackers would attempt to perform common attacks, such as social engineering attacks to convince device users to install malware, and attacks on third-party applications on Android. Android was designed to both reduce the probability of these attacks and greatly limit the impact of the attack in the event it was successful. This document outlines the goals of the Android security program, describes the fundamentals of the Android security architecture, and answers the most pertinent questions for system architects and security analysts. This document focuses on the security features of Android's core platform and does not discuss security issues that are unique to specific applications, such as those related to the browser or SMS application. Recommended best practices for building Android devices, deploying Android devices, or developing applications for Android are not the goal of this document and are provided elsewhere.
Background
Android provides an open source platform and application environment for mobile devices. The main Android platform building blocks are: Device Hardware : Android runs on a wide range of hardware configurations including smart phones, tablets, and set-top-boxes. Android is processor-agnostic, but it does take advantage of some hardware-specific security capabilities such as ARM v6 eXecute-Never. Android Operating System : The core operating system is built on top of the Linux kernel. All device resources, like camera functions, GPS data, Bluetooth functions, telephony functions, network connections, etc. are accessed through the operating system. Android Application Runtime : Android applications are most often written in the Java programming language and run in the Dalvik virtual machine. However, many applications, including core Android services and applications are native applications or include native libraries. Both Dalvik and native applications run within the same security environment, contained within the Application Sandbox. Applications get a dedicated part of the filesystem in which they can write private data, including databases and raw files. Android applications extend the core Android operating system. There are two primary sources for applications: Pre-Installed Applications: Android includes a set of pre-installed applications including phone, email, calendar, web browser, and contacts. These function both as user applications and to provide key device capabilities that can be accessed by other applications. Pre-installed applications may be part of the open source Android platform, or they may be developed by an OEM for a specific device. User-Installed Applications: Android provides an open development environment supporting any third-party application. Google Play offers users
source.android.com/tech/security/index.html 3/18
4/4/13
hundreds of thousands of applications. Google provides a set of cloud-based services that are available to any compatible Android device. The primary services are: Google Play: Google Play is a collection of services that allow users to discover, install, and purchase applications from their Android device or the web. Google Play makes it easy for developers to reach Android users and potential customers. Google Play also provides community review, application license verification, application security scanning, and other security services. Android Updates: The Android update service delivers new capabilities and security updates to Android devices, including updates through the web or over the air (OTA). Application Services: Frameworks that allow Android applications to use cloud capabilities such as (backing up) application data and settings and cloud-to-device messaging (C2DM) for push messaging. These services are not part of the Android Open Source Project and are out of scope for this document. But they are relevant to the security of most Android devices, so a related security document titled Google Services for Android: Security Overview is available.
4/4/13
Android seeks to be the most secure and usable operating system for mobile platforms by re-purposing traditional operating system security controls to: Protect user data Protect system resources (including the network) Provide application isolation To achieve these objectives, Android provides these key security features: Robust security at the OS level through the Linux kernel Mandatory application sandbox for all applications Secure interprocess communication Application signing Application-defined and user-granted permissions The sections below describe these and other security features of the Android platform. Figure 1 summarizes the security components and considerations of the various levels of the Android software stack. Each component assumes that the components below are properly secured. With the exception of a small amount of Android OS code running as root, all code above the Linux Kernel is restricted by the Application Sandbox.
source.android.com/tech/security/index.html
5/18
4/4/13
Linux Security
The foundation of the Android platform is the Linux kernel. The Linux kernel itself has been in widespread use for years, and is used in millions of securitysensitive environments. Through its history of constantly being researched, attacked, and fixed by thousands of developers, Linux has become a stable and secure kernel trusted by many corporations and security professionals.
source.android.com/tech/security/index.html 6/18
4/4/13
As the base for a mobile computing environment, the Linux kernel provides Android with several key security features, including: A user-based permissions model Process isolation Extensible mechanism for secure IPC The ability to remove unnecessary and potentially insecure parts of the kernel As a multiuser operating system, a fundamental security objective of the Linux kernel is to isolate user resources from one another. The Linux security philosophy is to protect user resources from one another. Thus, Linux: Prevents user A from reading user B's files Ensures that user A does not exhaust user B's memory Ensures that user A does not exhaust user B's CPU resources Ensures that user A does not exhaust user B's devices (e.g. telephony, GPS, bluetooth)
4/4/13
Filesystem Permissions
In a UNIX-style environment, filesystem permissions ensure that one user cannot alter or read another user's files. In the case of 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.
Cryptography
Android provides a set of cryptographic APIs for use by applications. These include implementations of standard and commonly used cryptographic primitives such as AES, RSA, DSA, and SHA. Additionally, APIs are provided for higher level protocols such as SSL and HTTPS. Android 4.0 introduced the KeyChain class to allow applications to use the system credential storage for private keys and certificate chains.
4/4/13
Rooting of Devices
By default, on Android only the kernel and a small subset of the core applications run with root permissions. Android does not prevent a user or application with root permissions from modifying the operating system, kernel, and any other application. In general, root has full access to all applications and all application data. Users that change the permissions on an Android device to grant root access to applications increase the security exposure to malicious applications and potential application flaws. The ability to modify an Android device they own is important to developers working with the Android platform. On many Android devices users have the ability to unlock the bootloader in order to allow installation of an alternate operating system. These alternate operating systems may allow an owner to gain root access for purposes of debugging applications and system components or to access features not presented to applications by Android APIs. On some devices, a person with physical control of a device and a USB cable is able to install a new operating system that provides root privileges to the user. To protect any existing user data from compromise the bootloader unlock mechanism requires that the bootloader erase any existing user data as part of the unlock step. Root access gained via exploiting a kernel bug or security hole can bypass this protection. Encrypting data with a key stored on-device does not protect the application data from root users. Applications can add a layer of data protection using encryption with a key stored off-device, such as on a server or a user password. This approach can provide temporary protection while the key is not present, but at some point the key must be provided to the application and it then becomes accessible to root users. A more robust approach to protecting data from root users is through the use of hardware solutions. OEMs may choose to implement hardware solutions that limit access to specific types of content such as DRM for video playback, or the NFC-related trusted storage for Google wallet. In the case of 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 users device password.
Password Protection
source.android.com/tech/security/index.html 9/18
4/4/13
Android can be configured to verify 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 filesystem encryption. Use of a password and/or password complexity rules can be required by a device administrator.
Device Administration
Android 2.2 and later provide the Android Device Administration API, which provides device administration features at the system level. For example, the built-in Android Email application uses the APIs to improve Exchange support. Through the Email application, Exchange administrators can enforce password policies including alphanumeric passwords or numeric PINs across devices. Administrators can also remotely wipe (that is, restore factory defaults on) lost or stolen handsets. In addition to use in applications included with the Android system, these APIs are available to third-party providers of Device Management solutions. Details on the API are provided here: https://developer.android.com/guide/topics/admin/device-admin.html.
Credential Storage
By default, Android includes a set of predefined Certificate Authorities (CAs) that are trusted for operations such as establishing SSL connections within the browser. In Android 4.0 and later, users can disable preinstalled CAs within the system settings. Users can also add trusted CAs or certificates to the system by importing them from USB storage. Android 4.1 and later adds the ability for OEMs to add hardware-backed KeyChain storage which binds private keys to the device on which they are stored.
4/4/13
Services: A Service is a body of code that runs in the background. It can run in its own process, or in the context of another application's process. Other components "bind" to a Service and invoke methods on it via remote procedure calls. An example of a Service is a media player: even when the user quits the media-selection UI, the user probably still intends for music to keep playing. A Service keeps the music going even when the UI has completed. Broadcast Receiver: A BroadcastReceiver is an object that is instantiated when an IPC mechanism known as an Intent is issued by the operating system or another application. An application may register a receiver for the low battery message, for example, and change its behavior based on that information.
4/4/13
prevent circumvention. An example of the user messaging when an application is installed while requesting access to protected APIs is shown in Figure 2. The system default permissions are described at https://developer.android.com/reference/android/Manifest.permission.html. Applications may declare their own permissions for other applications to use. Such permissions are not listed in the above location. When defining a permission a protectionLevel attribute tells the system how the user is to be informed of applications requiring the permission, or who is allowed to hold a permission. Details on creating and using application specific permissions are described at https://developer.android.com/guide/topics/security/security.html. There are some device capabilities, such as the ability to send SMS broadcast intents, that are not available to third-party applications, but that may be used by applications pre-installed by the OEM. These permissions use the signatureOrSystem permission.
source.android.com/tech/security/index.html
12/18
4/4/13
Interprocess Communication
Processes can communicate using any of the traditional UNIX-type mechanisms. Examples include the filesystem, local sockets, or signals. However, the Linux permissions still apply. Android also provides new IPC mechanisms: Binder: A lightweight capability-based remote procedure call mechanism designed for high performance when performing in-process and crossprocess calls. Binder is implemented using a custom Linux driver. See https://developer.android.com/reference/android/os/Binder.html. Services: Services (discussed above) can provide interfaces directly accessible using binder. Intents: An Intent is a simple message object that represents an "intention" to do something. 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 some other
source.android.com/tech/security/index.html 13/18
4/4/13
piece of code (in this case, the Browser) that knows how to handle that Intent, and runs it. Intents can also be used to broadcast interesting events (such as a notification) system-wide. See https://developer.android.com/reference/android/content/Intent.html. ContentProviders: A ContentProvider is a data storehouse that provides access to data on the device; the classic example is the ContentProvider that is used to access the user's list of contacts. An application can access data that other applications have exposed via a ContentProvider, and an application can also define its own ContentProviders to expose data of its own. See https://developer.android.com/reference/android/content/ContentProvider.html. While it is possible to implement IPC using other mechanisms such as network sockets or world-writable files, these are the recommended Android IPC frameworks. Android developers will be encouraged to use best practices around securing users' data and avoiding the introduction of security vulnerabilities.
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. These APIs include: Telephony SMS/MMS Network/Data In-App Billing NFC Access Android 4.2 adds further control on the use of SMS. Android will provide a notification if an application attempts to send SMS to a short code that uses premium services which might cause additional charges. The user can choose whether to allow the application to send the message or block it.
Personal Information
Android has placed APIs that provide access to user data into the set of protected APIs. With normal usage, Android devices will also accumulate user data within third-party applications installed by users. Applications that choose to share this information can use Android OS permission checks to protect the data from third-party applications.
source.android.com/tech/security/index.html
14/18
4/4/13
Figure 3: Access to sensitive user data is only available through protected APIs System content providers that are likely to contain personal or personally identifiable information such as contacts and calendar have been created with clearly identified permissions. This granularity provides the user with clear indication of the types of information that may be provided to the application. During installation, a third-party application may request permission to access these resources. If permission is granted, the application can be installed and will have access to the data requested at any time when it is installed. Any applications which collect personal information will, by default, have that data restricted only to the specific application. If an application chooses to make the data available to other applications though IPC, the application granting access can apply permissions to the IPC mechanism that are enforced by the operating system.
Device Metadata
Android also strives to restrict access to data that is not intrinsically sensitive, but may indirectly reveal characteristics about the user, user preferences, and the manner in which they use a device.
source.android.com/tech/security/index.html 15/18
4/4/13
By default applications do not have access to operating system logs, browser history, phone number, or hardware / network identification information. If an application requests access to this information at install time, the installer will prompt the user asking if the application can access the information. If the user does not grant access, the application will not be installed.
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 platform 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 Google Play, application signing bridges the trust Google has with the developer and the trust the developer has with their application. Developers know their application is provided, unmodified to the Android device; and developers can be held accountable for behavior of their application. 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. Applications can be signed by a third-party (OEM, operator, alternative market) or self-signed. Android provides code signing using self-signed certificates that developers can generate without external assistance or permission. Applications do not have to be signed by a central authority. Android currently does not perform CA verification for application certificates. Applications are also able to declare security permissions at the Signature protection level, restricting access only to applications signed with the same key while maintaining distinct UIDs and Application Sandboxes. A closer relationship with a shared Application Sandbox is allowed via the shared UID feature where two or more applications signed with same developer key can declare a shared UID in their manifest.
Application Verification
Android 4.2 and later support application verification. Users can choose to enable Verify Apps" and have applications evaluated by an application verifier prior to installation. App verification can alert the user if they try to install an app that might be harmful; if an application is especially bad, it can block installation.
4/4/13
A native code DRM manager, which implements the DRM framework and exposes an interface for DRM plug-ins (agents) to handle rights management and decryption for various DRM schemes
Android Updates
Android provides system updates for both security and feature related purposes. There are two ways to update the code on most Android devices: over-the-air (OTA updates) or side-loaded updates. OTA updates can be rolled out over a defined time period or be pushed to all devices at once, depending on how the OEM and/or carrier would like to push the updates. Side-loaded updates can be provided from a central location for users to download as a zip file to their local desktop machine or directly to their handset. Once the update is copied or downloaded to the SD card on the device, Android will recognize the update, verify its integrity and authenticity, and automatically update the device. If a dangerous vulnerability is discovered internally or responsibly reported to Google or the Android Open Source Project, the Android security team will start the following process. 1. 2. 3. 4. 5. 6. The Android team will notify companies who have signed NDAs regarding the problem and begin discussing the solution. The owners of code will begin the fix. The Android team will fix Android-related security issues. When a patch is available, the fix is provided to the NDA companies. The Android team will publish the patch in the Android Open Source Project OEM/carrier will push an update to customers.
17/18
source.android.com/tech/security/index.html
4/4/13
The NDA is required to ensure that the security issue does not become public prior to availabilty of a fix and put users at risk. Many OHA members run their own code on Android devices such as the bootloader, wifi drivers, and the radio. Once the Android Security team is notified of a security issue in this partner code, they will consult with OHA partners to quickly find a fix for the problem at hand and similar problems. However, the OHA member who wrote the faulty code is ultimately responsible for fixing the problem. If a dangerous vulnerability is not responsibly disclosed (e.g., if it is posted to a public forum without warning), then Google and/or the Android Open Source Project will work as quickly as possible to create a patch. The patch will released to the public (and any partners) when the patch is tested and ready for use. At Google I/O 2011, many of the largest OHA partners committed to providing updates to devices for 18 months after initial shipment. This will provide users with access to the most recent Android features, as well as security updates. Any developer, Android user, or security researcher can notify the Android security team of potential security issues by sending email to security@android.com. If desired, communication can be encrypted using the Android security team PGP key available here: https://developer.android.com/security_at_android_dot_com.txt.
Other Resources
Information about the Android Open Source Project is available at https://source.android.com. Information for Android application developers is here: https://developer.android.com. The Android Security team can be reached at security@android.com. Security information exists throughout the Android Open Source and Developer Sites. A good place to start is here: https://developer.android.com/guide/topics/security/security.html. A Security FAQ for developers is located here: https://developer.android.com/resources/faq/security.html. Security Best Practices for developers is located here: https://developer.android.com/guide/practices/security.html. A community resource for discussion about Android security exists here: https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss.
Go to Top
source.android.com/tech/security/index.html
18/18