腰椎间盘突出图片:Android Security Overview | Android Open Sour...

来源:百度文库 编辑:偶看新闻 时间:2024/03/29 19:03:39
Android.com

Topics

  • Dalvik
  • Debugging
  • Encryption
  • Security
  • Input
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
    • Filesystem Encryption
    • Password Protection
    • Device Administration
    • Memory Management Security Enhancements
    • Rooting of Devices
  • 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
    • Digital Rights Management
  • Android Updates
  • Other Resources

Android Security Overview

Introduction

Android is a modern mobile platform that was designed to be truly open. Androidapplications make use of advanced hardware and software, as well as local andserved data, exposed through the platform to bring innovation and value toconsumers. To protect that value, the platform must offer an applicationenvironment that ensures the security of users, data, applications, the device,and the network.

Securing an open platform requires a robust security architecture and rigoroussecurity programs. Android was designed with multi-layered security thatprovides the flexibility required for an open platform, while providingprotection for all users of the platform.

Android was designed with developers in mind. Security controls were designedto reduce the burden on developers. Security-savvy developers can easily workwith and rely on flexible security controls. Developers less familiar withsecurity will be protected by safe defaults.

Android was designed with device users in mind. Users are provided visibilityinto how applications work, and control over those applications. This designincludes the expectation that attackers would attempt to perform commonattacks, such as social engineering attacks to convince device users to installmalware, and attacks on third-party applications on Android. Android wasdesigned to both reduce the probability of these attacks and greatly limit theimpact of the attack in the event it was successful.

This document outlines the goals of the Android security program, describes thefundamentals of the Android security architecture, and answers the mostpertinent questions for system architects and security analysts. This documentfocuses on the security features of Android's core platform and does notdiscuss security issues that are unique to specific applications, such as thoserelated to the browser or SMS application. Recommended best practices forbuilding Android devices, deploying Android devices, or developing applicationsfor Android are not the goal of this document and are provided elsewhere.

Background

Android provides an open source platform and application environment for mobiledevices.

The main Android platform building blocks are:

  • Device Hardware: Android runs on a wide range of hardware configurationsincluding smart phones, tablets, and set-top-boxes. Android isprocessor-agnostic, but it does take advantage of some hardware-specificsecurity capabilities such as ARM v6 eXecute-Never.

  • Android Operating System: The core operating system is built on top ofthe Linux kernel. All device resources, like camera functions, GPS data,Bluetooth functions, telephony functions, network connections, etc. areaccessed through the operating system.

  • Android Application Runtime: Android applications are most often writtenin the Java programming language and run in the Dalvik virtual machine.However, many applications, including core Android services and applicationsare native applications or include native libraries. Both Dalvik and nativeapplications run within the same security environment, contained within theApplication Sandbox. Applications get a dedicated part of the filesystem inwhich they can write private data, including databases and raw files.

Android applications extend the core Android operating system. There are twoprimary sources for applications:

  • Pre-Installed Applications: Android includes a set of pre-installedapplications including phone, email, calendar, web browser, and contacts. Thesefunction both as user applications and to provide key device capabilities thatcan be accessed by other applications. Pre-installed applications may be partof the open source Android platform, or they may be developed by an OEM for aspecific device.

  • User-Installed Applications: Android provides an open developmentenvironment supporting any third-party application. The Android Market offersusers hundreds of thousands of applications.

Google provides a set of cloud-based services that are available to anycompatible Android device. The primary services are:

  • Android Market: The Android Market is a collection of services thatallow users to discover, install, and purchase applications from their Androiddevice or the web. The Market makes it easy for developers to reach Androidusers and potential customers. The Market also provides community review,application licenseverification,and other security services.

  • Android Updates: The Android update service delivers new capabilities andsecurity updates to Android devices, including updates through the web or overthe air (OTA).

  • Application Services: Frameworks that allow Android applications to usecloud capabilities such as (backingup) applicationdata and settings and cloud-to-device messaging(C2DM)for push messaging.

These services are not part of the Android Open Source Project and are outof scope for this document. But they are relevant to the security of mostAndroid devices, so a related security document titled “Google Services forAndroid: Security Overview” is available.

Android Security Program Overview

Early on in development, the core Android development team recognized that arobust security model was required to enable a vigorous ecosystem ofapplications and devices built on and around the Android platform and supportedby cloud services. As a result, through its entire development lifecycle,Android has been subjected to a professional security program. The Android teamhas had the opportunity to observe how other mobile, desktop, and server platformsprevented and reacted to security issues and built a securityprogram to address weak points observed in other offerings.

The key components of the Android Security Program include:

  • Design Review: The Android security process begins early in thedevelopment lifecycle with the creation of a rich and configurable securitymodel and design. Each major feature of the platform is reviewed by engineeringand security resources, with appropriate security controls integrated into thearchitecture of the system.
  • Penetration Testing and Code Review: During the development of theplatform, Android-created and open-source components are subject to vigoroussecurity reviews. These reviews are performed by the Android Security Team,Google’s Information Security Engineering team, and independent securityconsultants. The goal of these reviews is to identify weaknesses and possiblevulnerabilities well before the platform is open-sourced, and to simulate thetypes of analysis that will be performed by external security experts uponrelease.
  • Open Source and Community Review: The Android Open Source Project enablesbroad security review by any interested party. Android also uses open sourcetechnologies that have undergone significant external security review,such as the Linux kernel. The Android Market provides a forum for users and companiesto provide information about specific applications directly to users.
  • Incident Response: Even with all of these precautions, security issuesmay occur after shipping, which is why the Android project has created acomprehensive security response process. A full-time Android security teamconstantly monitors Android-specific and the general security community fordiscussion of potential vulnerabilities. Upon the discovery of legitimateissues, the Android team has a response process that enables the rapidmitigation of vulnerabilities to ensure that potential risk to all Androidusers is minimized. These cloud-supported responses can include updating theAndroid platform (over-the-air updates), removing applications from the AndroidMarket, and removing applications from devices in the field.

Android Platform Security Architecture

Android seeks to be the most secure and usable operating system for mobileplatforms 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 Androidplatform. Figure 1 summarizes the security components and considerations ofthe various levels of the Android software stack. Each component assumes thatthe components below are properly secured. With the exception of a small amountof Android OS code running as root, all code above the Linux Kernel isrestricted by the Application Sandbox.

Figure 1: Android software stack.

System and Kernel Level Security

At the operating system level, the Android platform provides the security ofthe Linux kernel, as well as a secure inter-process communication (IPC)facility to enable secure communication between applications running indifferent processes. These security features at the OS level ensure that evennative code is constrained by the Application Sandbox. Whether that code isthe result of included application behavior or a exploitation of an applicationvulnerability, the system would prevent the rogue application from harmingother applications, the Android system, or the device itself.

Linux Security

The foundation of the Android platform is the Linux kernel. The Linux kernelitself has been in widespread use for years, and is used in millions ofsecurity-sensitive environments. Through its history of constantly beingresearched, attacked, and fixed by thousands of developers, Linux has become astable and secure kernel trusted by many corporations and securityprofessionals.

As the base for a mobile computing environment, the Linux kernel providesAndroid 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 Linuxkernel is to isolate user resources from one another. The Linux securityphilosophy is to protect user resources from one another. Thus, Linux:

  • Pevents 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)

The Application Sandbox

The Android platform takes advantage of the Linux user-based protection as ameans of identifying and isolating application resources. The Android systemassigns a unique user ID (UID) to each Android application and runs it as that userin a separate process. This approach is different from other operating systems(including the traditional Linux configuration), where multiple applicationsrun with the same user permissions.

This sets up a kernel-level Application Sandbox. The kernel enforces securitybetween applications and the system at the process level through standard Linuxfacilities, such as user and group IDs that are assigned to applications. Bydefault, applications cannot interact with each other and applications havelimited access to the operating system. If application A tries to do somethingmalicious like read application B's data or dial the phone without permission(which is a separate application), then the operating system protects againstthis because application A does not have the appropriate user privileges. Thesandbox is simple, auditable, and based on decades-old UNIX-style userseparation of processes and file permissions.

Since the Application Sandbox is in the kernel, this security model extends tonative code and to operating system applications. All of the software above thekernel in Figure 1, including operating system libraries, applicationframework, application runtime, and all applications run within the ApplicationSandbox. On some platforms, developers are constrained to a specificdevelopment framework, set of APIs, or language in order to enforce security.On Android, there are no restrictions on how an application can be written thatare required to enforce security; in this respect, native code is just assecure as interpreted code.

In some operating systems, memory corruption errors generally lead tocompletely compromising the security of the device. This is not the case inAndroid due to all applications and their resources being sandboxed at the OSlevel. A memory corruption error will only allow arbitrary code execution inthe context of that particular application, with the permissions established bythe operating system.

Like all security features, the Application Sandbox is not unbreakable.However, to break out of the Application Sandbox in a properly configureddevice, one must compromise the security of the the Linux kernel.

System Partition and Safe Mode

The system partition contains Android's kernel as well as the operating systemlibraries, application runtime, application framework, and applications. Thispartition is set to read-only. When a user boots the device into Safe Mode,only core Android applications are available. This ensures that the user canboot their phone into an environment that is free of third-party software.

Filesystem Permissions

In a UNIX-style environment, filesystem permissions ensure that one user cannotalter or read another user's files. In the case of Android, each applicationruns as its own user. Unless the developer explicitly exposes files to otherapplications, files created by one application cannot be read or altered byanother application.

Filesystem Encryption

Android 3.0 and later provides full filesystem encryption, so all user data canbe encrypted in the kernel using the dmcrypt implementation of AES128 with CBCand ESSIV:SHA256. The encryption key is protected by AES128 using a keyderived from the user password, preventing unauthorized access to stored datawithout the user device password. To provide resistance against systematicpassword guessing attacks (e.g. “rainbow tables” or brute force), thepassword is combined with a random salt and hashed repeatedly with SHA1 usingthe standard PBKDF2 algorithm prior to being used to decrypt the filesystemkey. To provide resistance against dictionary password guessing attacks,Android provides password complexity rules that can be set by the deviceadministrator and enforced by the operating system. Filesystem encryptionrequires the use of a user password, pattern-based screen lock is not supported.

More details on implementation of filesystem encryption are available athttp://source.android.com/tech/encryption/android_crypto_implementation.html

Password Protection

Android can be configured to verify a user-supplied password prior to providingaccess 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 deviceadministrator.

Device Administration

Android 2.2 and later provide the Android Device Administration API, whichprovides device administration features at the system level. For example, thebuilt-in Android Email application uses the APIs to improve Exchange support.Through the Email application, Exchange administrators can enforce passwordpolicies — including alphanumeric passwords or numeric PINs — acrossdevices. Administrators can also remotely wipe (that is, restore factorydefaults on) lost or stolen handsets.

In addition to use in applications included with the Android system, these APIsare available to third-party providers of Device Management solutions. Detailson the API are provided here:http://developer.android.com/guide/topics/admin/device-admin.html.

Memory Management Security Enhancements

Android includes many features that make common security issues harder toexploit. The Android SDK, compilers, and OS use tools to make common memorycorruption issues significantly harder to exploit, including:

  • Address Space Layout Randomization (ASLR) to randomize key locations in memory
  • Hardware-based No eXecute (NX) to prevent code execution on the stack and heap
  • ProPolice to prevent stack buffer overruns
  • safe_iop to reduce integer overflows
  • Extensions to OpenBSD dlmalloc to prevent double free() vulnerabilities andto prevent chunk consolidation attacks. Chunk consolidation attacks are acommon way to exploit heap corruption.
  • OpenBSD calloc to prevent integer overflows during memory allocation
  • Linux mmap_min_addr() to mitigate null pointer dereference privilegeescalation

Rooting of Devices

By default, on Android only the kernel and a small subset of the coreapplications run with root permissions. Android does not prevent a user orapplication with root permissions from modifying the operating system, kernel,and any other application. In general, root has full access to allapplications and all application data. Users that change the permissions on anAndroid device to grant root access to applications increase the securityexposure to malicious applications and potential application flaws.

The ability to modify an Android device they own is important to developersworking with the Android platform. On many Android devices users have theability to unlock the bootloader in order to allow installation of an alternateoperating system. These alternate operating systems may allow an owner to gainroot access for purposes of debugging applications and system components or toaccess features not presented to applications by Android APIs.

On some devices, a person with physical control of a device and a USB cable isable to install a new operating system that provides root privileges to theuser. To protect any existing user data from compromise the bootloader unlockmechanism requires that the bootloader erase any existing user data as part ofthe unlock step. Root access gained via exploiting a kernel bug or securityhole can bypass this protection.

Encrypting data with a key stored on-device does not protect the applicationdata from root users. Applications can add a layer of data protection usingencryption with a key stored off-device, such as on a server or a userpassword. This approach can provide temporary protection while the key is notpresent, but at some point the key must be provided to the application and itthen becomes accessible to root users.

A more robust approach to protecting data from root users is through the use ofhardware solutions. OEMs may choose to implement hardware solutions that limitaccess to specific types of content such as DRM for video playback, or theNFC-related trusted storage for Google wallet.

In the case of a lost or stolen device, full filesystem encryption on Androiddevices uses the device password to protect the encryption key, so modifyingthe bootloader or operating system is not sufficient to access user datawithout the user’s device password.

Android Application Security

Elements of Applications

Android provides an open source platform and application environment for mobiledevices. The core operating system is based on the Linux kernel. Androidapplications are most often written in the Java programming language and run inthe Dalvik virtual machine. However, applications can also be written in nativecode. Applications are installed from a single file with the .apk fileextension.

The main Android application building blocks are:

  • AndroidManifest.xml: TheAndroidManifest.xml file is the control file that tells the system what to do withall the top-level components (specifically activities, services, broadcastreceivers, and content providers described below) in an application. This alsospecifies which permissions are required.

  • Activities: AnActivity is, generally, the code for a single, user-focused task. It usuallyincludes displaying a UI to the user, but it does not have to -- someActivities never display UIs. Typically, one of the application's Activitiesis the entry point to an application.

  • Services: AServiceis 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" toa Service and invoke methods on it via remote procedure calls. An example of aService is a media player: even when the user quits the media-selection UI, theuser probably still intends for music to keep playing. A Service keeps themusic going even when the UI has completed.

  • Broadcast Receiver: ABroadcastReceiver is an object that is instantiated when an IPC mechanismknown as anIntentis issued by the operating system or another application. An application mayregister a receiver for the low battery message, for example, and change itsbehavior based on that information.

The Android Permission Model: Accessing Protected APIs

By default, an Android application can only access a limited range of systemresources. The system manages Android application access to resources that, ifused incorrectly or maliciously, could adversely impact the user experience,the network, or data on the device.

These restrictions are implemented in a variety of different forms. Somecapabilities are restricted by an intentional lack of APIs to the sensitivefunctionality (e.g. there is no Android API for directly manipulating the SIMcard). In some instances, separation of roles provides a security measure, aswith the per-application isolation of storage. In other instances, thesensitive APIs are intended for use by trusted applications and protectedthrough a security mechanism known as Permissions.

These protected APIs include:

  • Camera functions
  • Location data (GPS)
  • Bluetooth functions
  • Telephony functions
  • SMS/MMS functions
  • Network/data connections

These resources are only accessible through the operating system. To make useof the protected APIs on the device, an application must define thecapabilities it needs in its manifest. When preparing to install anapplication, the system displays a dialog to the user that indicates thepermissions requested and asks whether to continue the installation. If theuser continues with the installation, the system accepts that the user hasgranted all of the requested permissions. The user can not grant or denyindividual permissions -- the user must grant or deny all of the requestedpermissions as a block.

Once granted, the permissions are applied to the application as long as it isinstalled. To avoid user confusion, the system does not notify the user againof the permissions granted to the application, and applications that areincluded in the core operating system or bundled by an OEM do not requestpermissions from the user. Permissions are removed if an application isuninstalled, so a subsequent re-installation will again result in display ofpermissions.

Within the device settings, users are able to view permissions for applicationsthey have previously installed. Users can also turn off some functionalityglobally when they choose, such as disabling GPS, radio, or wi-fi.

In the event that an application attempts to use a protected feature which hasnot been declared in the application's manifest, the permission failure willtypically result in a security exception being thrown back to the application.Protected API permission checks are enforced at the lowest possible level toprevent circumvention. An example of the user messaging when an application isinstalled while requesting access to protected APIs is shown in Figure 2.

The system default permissions are described athttp://code.google.com/android/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 theuser is to be informed of applications requiring the permission, or who isallowed to hold a permission. Details on creating and using applicationspecific permissions are described athttp://developer.android.com/guide/topics/security/security.html.

There are some device capabilities, such as the ability to send SMS broadcastintents, that are not available to third-party applications, but that may beused by applications pre-installed by the OEM. These permissions use thesignatureOrSystem permission.

How Users Understand Third-Party Applications

Android strives to make it clear to users when they are interacting withthird-party applications and inform the user of the capabilities thoseapplications have. Prior to installation of any application, the user is showna clear message about the different permissions the application is requesting.After install, the user is not prompted again to confirm any permissions.

There are many reasons to show permissions immediately prior to installationtime. This is when user is actively reviewing information about theapplication, developer, and functionality to determine whether it matches theirneeds and expectations. It is also important that they have not yetestablished a mental or financial commitment to the app, and can easily comparethe application to other alternative applications.

Some other platforms use a different approach to user notification, requestingpermission at the start of each session or while applications are in use. Thevision of Android is to have users switching seamlessly between applications atwill. Providing confirmations each time would slow down the user and preventAndroid from delivering a great user experience. Having the user reviewpermissions at install time gives the user the option to not install theapplication if they feel uncomfortable.

Also, many user interface studies have shown that over-prompting the usercauses the user to start saying "OK" to any dialog that is shown. One ofAndroid's security goals is to effectively convey important securityinformation to the user, which cannot be done using dialogs that the user willbe trained to ignore. By presenting the important information once, and onlywhen it is important, the user is more likely to think about what they areagreeing to.

Some platforms choose not to show any information at all about applicationfunctionality. That approach prevents users from easily understanding anddiscussing application capabilities. While it is not possible for all users toalways make fully informed decisions, the Android permissions model makesinformation about applications easily accessible to a wide range of users. Forexample, unexpected permissions requests can prompt more sophisticated users toask critical questions about application functionality and share their concernsin places such as the Android Market where theyare visible to all users.

Permissions at Application Install -- Google MapsPermissions of an Installed Application -- gMail

Figure 2: Display of permissions for applications

Interprocess Communication

Processes can communicate using any of the traditional UNIX-type mechanisms.Examples include the filesystem, local sockets, or signals. However, the Linuxpermissions still apply.

Android also provides new IPC mechanisms:

  • Binder: A lightweight capability-based remote procedure call mechanismdesigned for high performance when performing in-process and cross-processcalls. Binder is implemented using a custom Linux driver. Seehttp://developer.android.com/reference/android/os/Binder.html.

  • Services: Services (discussed above) can provide interfaces directlyaccessible using binder.

  • Intents: An Intent is a simple message object that represents an"intention" to do something. For example, if your application wants to displaya web page, it expresses its "Intent" to view the URL by creating an Intentinstance and handing it off to the system. The system locates some other pieceof code (in this case, the Browser) that knows how to handle that Intent, andruns it. Intents can also be used to broadcast interesting events (such as anotification) system-wide. Seehttp://code.google.com/android/reference/android/content/Intent.html.

  • ContentProviders: A ContentProvider is a data storehouse that providesaccess to data on the device; the classic example is the ContentProvider thatis used to access the user's list of contacts. An application can access datathat other applications have exposed via a ContentProvider, and an applicationcan also define its own ContentProviders to expose data of its own. Seehttp://code.google.com/android/reference/android/content/ContentProvider.html.

While it is possible to implement IPC using other mechanisms such as networksockets or world-writable files, these are the recommended Android IPCframeworks. Android developers will be encouraged to use best practices aroundsecuring 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 orthe network. The Android platform has placed cost sensitive APIs in the list ofprotected APIs controlled by the OS. The user will have to grant explicitpermission to third-party applications requesting use of cost sensitive APIs.These APIs include:

  • Telephony
  • SMS/MMS
  • Network/Data
  • In-App Billing
  • NFC Access

SIM Card Access

Low level access to the SIM card is not available to third-party apps. The OShandles all communications with the SIM card including access to personalinformation (contacts) on the SIM card memory. Applications also cannot accessAT commands, as these are managed exclusively by the Radio Interface Layer(RIL). The RIL provides no high level APIs for these commands.

Personal Information

Android has placed APIs that provide access to user data into the set ofprotected APIs. With normal usage, Android devices will also accumulate userdata within third-party applications installed by users. Applications thatchoose to share this information can use Android OS permission checks toprotect the data from third-party applications.

Figure 3: Access to sensitive user data is only available through protectedAPIs

System content providers that are likely to contain personal or personallyidentifiable information such as contacts and calendar have been created withclearly identified permissions. This granularity provides the user with clearindication of the types of information that may be provided to the application. During installation, a third-party application may request permission toaccess these resources. If permission is granted, the application can beinstalled and will have access to the data requested at any time when it isinstalled.

Any applications which collect personal information will, by default, have thatdata restricted only to the specific application. If an application chooses tomake the data available to other applications though IPC, the applicationgranting access can apply permissions to the IPC mechanism that are enforced bythe operating system.

Sensitive Data Input Devices

Android devices frequently provide sensitive data input devices that allowapplications to interact with the surrounding environment, such as camera,microphone or GPS. For a third-party application to access these devices, itmust first be explicitly provided access by the user through the use of AndroidOS Permissions. Upon installation, the installer will prompt the userrequesting permission to the sensor by name.

If an application wants to know the user's location, the application requires apermission to access the user's location. Upon installation, the installer willprompt the user asking if the application can access the user's location. Atany time, if the user does not want any application to access their location,then the user can run the "Settings" application, go to "Location & Security",and uncheck the "Use wireless networks" and "Enable GPS satellites". This willdisable location based services for all applications on the user's device.

Device Metadata

Android also strives to restrict access to data that is not intrinsicallysensitive, but may indirectly reveal characteristics about the user, userpreferences, and the manner in which they use a device.

By default applications do not have access to operating system logs,browser history, phone number, or hardware / network identificationinformation. If an application requests access to this information at installtime, the installer will prompt the user asking if the application can accessthe information. If the user does not grant access, the application will not beinstalled.

Application Signing

Code signing allows developers to identify the author of the application and toupdate their application without creating complicated interfaces andpermissions. Every application that is run on the Android platform must besigned by the developer. Applications that attempt to install without beingsigned will rejected by either the Android Market or the package installer onthe Android device.

On Android Market, application signing bridges the trust Google has with thedeveloper and the trust the developer has with their application. Developersknow their application is provided, unmodified to the Android device; anddevelopers can be held accountable for behavior of their application.

On Android, application signing is the first step to placing an application inits Application Sandbox. The signed application certificate defines which userid is associated with which application; different applications run underdifferent user IDs. Application signing ensures that one application cannotaccess any other application except through well-defined IPC.

When an application (APK file) is installed onto an Android device, the PackageManager verifies that the APK has been properly signed with the certificateincluded in that APK. If the certificate (or, more accurately, the public keyin 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 UIDwith 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 certificatesthat developers can generate without external assistance or permission.Applications do not have to be signed by a central authority. Android currentlydoes not perform CA verification for application certificates.

Applications are also able to declare security permissions at the Signatureprotection level, restricting access only to applications signed with the samekey while maintaining distinct UIDs and Application Sandboxes. A closerrelationship with a shared Application Sandbox is allowed via the shared UIDfeature where two or more applications signed with same developer key candeclare a shared UID in their manifest.

Digital Rights Management

The Android platform provides an extensible DRM framework that letsapplications manage rights-protected content according to the licenseconstraints that are associated with the content. The DRM framework supportsmany DRM schemes; which DRM schemes a device supports is left to the devicemanufacturer.

The Android DRMframework is implemented in two architectural layers (see figure below):

  • A DRM framework API, which is exposed to applications through the Androidapplication framework and runs through the Dalvik VM for standard applications.

  • A native code DRM manager, which implements the DRM framework and exposes aninterface for DRM plug-ins (agents) to handle rights management and decryptionfor various DRM schemes

Figure 4: Architecture of Digital Rights Management on Android platform

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 adefined time period or be pushed to all devices at once, depending on how theOEM and/or carrier would like to push the updates. Side-loaded updates can beprovided from a central location for users to download as a zip file to theirlocal desktop machine or directly to their handset. Once the update is copiedor 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 reportedto Google or the Android Open Source Project, the Android security team willstart the following process.

  1. The Android team will notify companies who have signed NDAs regarding theproblem and begin discussing the solution.
  2. The owners of code will begin the fix.
  3. The Android team will fix Android-related security issues.
  4. When a patch is available, the fix is provided to the NDA companies.
  5. The Android team will publish the patch in the Android Open Source Project
  6. OEM/carrier will push an update to customers.

The NDA is required to ensure that the security issue does not become publicprior to availabilty of a fix and put users at risk. Many OHA members run theirown code on Android devices such as the bootloader, wifi drivers, and theradio. Once the Android Security team is notified of a security issue in thispartner code, they will consult with OHA partners to quickly find a fix for theproblem at hand and similar problems. However, the OHA member who wrote thefaulty code is ultimately responsible for fixing the problem.

If a dangerous vulnerability is not responsibly disclosed (e.g., if it isposted to a public forum without warning), then Google and/or the Android OpenSource Project will work as quickly as possible to create a patch. The patchwill released to the public (and any partners) when the patch is tested andready for use.

At Google I/O 2011, many of the largest OHA partners committed to providingupdates to devices for 18 months after initial shipment. This will provideusers with access to the most recent Android features, as well as securityupdates.

Any developer, Android user, or security researcher can notify the Androidsecurity team of potential security issues by sending email tosecurity@android.com. If desired, communication can be encrypted using theAndroid 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 athttp://source.android.com.

Information for Android application developers is here:http://developer.android.com.

The Android Security team can be reached atsecurity@android.com.

Security information exists throughout the Android Open Source and DeveloperSites. A good place to start is here:http://developer.android.com/guide/topics/security/security.html.

A Security FAQ for developers is located here:http://developer.android.com/resources/faq/security.html.

A community resource for discussion about Android security exists here:http://groups.google.com/group/android-security-discuss.

Privacy & Terms

Go to Top