Android Security
AndroidSecurity Overview
Introduction
Androidis 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.
Securingan open platform requires a robust security architecture and rigorous securityprograms. Android was designed with multi-layered security that provides theflexibility required for an open platform, while providing protection for allusers of the platform.
Androidwas designed with developers in mind. Security controls were designed to reducethe burden on developers. Security-savvy developers can easily work with andrely on flexible security controls. Developers less familiar with security willbe protected
by safe defaults.
Androidwas designed with device users in mind. Users are provided visibility into howapplications work, and control over those applications. This design includesthe expectation that attackers would attempt to perform common attacks, such associal engineering
attacks to convince device users to install malware, andattacks on third-party applications on Android. Android was designed to bothreduce the probability of these attacks and greatly limit the impact of theattack in the event it was successful.
Thisdocument 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
Androidprovides an open source platform and application environment for mobiledevices.
Themain 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 of the Linuxkernel. All device resources, like camera functions, GPS data, Bluetoothfunctions, telephony functions, network connections, etc. are accessed throughthe operating
system.
· Android Application Runtime: Android applications are most often written in the Javaprogramming language and run in the Dalvik virtual machine. However, manyapplications, including core Android services and applications are nativeapplications
or include native libraries. Both Dalvik and native applicationsrun within the same security environment, contained within the ApplicationSandbox. Applications get a dedicated part of the filesystem in which they canwrite private data, including databases
and raw files.
Androidapplications extend the core Android operating system. There are two primarysources for applications:
· Pre-Installed Applications: Android includes a set of pre-installed applicationsincluding phone, email, calendar, web browser, and contacts. These functionboth as user applications and to provide key device capabilities that can beaccessed
by other applications. Pre-installed applications may be part of theopen source Android platform, or they may be developed by an OEM for a specificdevice.
· User-Installed Applications: Android provides an open development environmentsupporting any third-party application. The Android Market offers usershundreds of thousands of applications.
Googleprovides a set of cloud-based services that are available to any compatibleAndroid device. The primary services are:
· Android Market: The Android Market is a collection of services that allowusers to discover, install, and purchase applications from their Android deviceor the web. The Market makes it easy for developers to reach Android users andpotential
customers. The Market also provides community review, application
license verification, 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 use cloudcapabilities such as (backing up) application data and settings and cloud-to-devicemessaging
(C2DM) for push messaging.
Theseservices are not part of the Android Open Source Project and are out of scopefor this document. But they are relevant to the security of most Androiddevices, so a related security document titled “Google Services for Android:Security Overview” is available.
Android SecurityProgram Overview
Earlyon in development, the core Android development team recognized that a robustsecurity model was required to enable a vigorous ecosystem of applications anddevices built on and around the Android platform and supported by cloudservices. As a result,
through its entire development lifecycle, Android has beensubjected to a professional security program. The Android team has had theopportunity to observe how other mobile, desktop, and server platformsprevented and reacted to security issues and built a security
program toaddress weak points observed in other offerings.
Thekey 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 the platform, Android-createdand open-source components are subject to vigorous security reviews. Thesereviews are performed by the Android Security Team, Google’s InformationSecurity
Engineering team, and independent security consultants. The goal ofthese reviews is to identify weaknesses and possible vulnerabilities wellbefore the platform is open-sourced, and to simulate the types of analysis thatwill be performed by external security
experts upon release.
· Open Source and Community Review: The Android Open Source Project enables broad securityreview by any interested party. Android also uses open source technologies thathave undergone significant external security review, such as the Linux
kernel.The Android Market provides a forum for users and companies to provideinformation about specific applications directly to users.
· Incident Response: Even with all of these precautions, security issues mayoccur after shipping, which is why the Android project has created acomprehensive security response process. A full-time Android security team constantlymonitors
Android-specific and the general security community for discussion ofpotential vulnerabilities. Upon the discovery of legitimate issues, the Androidteam has a response process that enables the rapid mitigation ofvulnerabilities to ensure that potential risk
to all Android users isminimized. These cloud-supported responses can include updating the Androidplatform (over-the-air updates), removing applications from the Android Market,and removing applications from devices in the field.
Android PlatformSecurity Architecture
Androidseeks to be the most secure and usable operating system for mobile platforms byre-purposing traditional operating system security controls to:
· Protect user data
· Protect system resources (including the network)
· Provide application isolation
Toachieve 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
Thesections below describe these and other security features of the Androidplatform.
Figure1 summarizes the security componentsand considerations of the various levels of the Android software stack. Eachcomponent assumes that the components below are properly secured. With theexception of a small amount of Android OS code running as
root, all code abovethe Linux Kernel is restricted by the Application Sandbox.
Figure 1: Android software stack.
Systemand Kernel Level Security
Atthe operating system level, the Android platform provides the security of theLinux kernel, as well as a secure inter-process communication (IPC) facility toenable secure communication between applications running in differentprocesses. These security features
at the OS level ensure that even native codeis constrained by the Application Sandbox. Whether that code is the result ofincluded 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
Thefoundation of the Android platform is the Linux kernel. The Linux kernel itselfhas 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.
Asthe base for a mobile computing environment, the Linux kernel provides Androidwith several key security features, including:
· A user-based permissions model
· Process isolation
· Extensible mechanism for secure IPC
· The ability to remove unnecessary and potentially insecureparts of the kernel
Asa 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 ApplicationSandbox
TheAndroid platform takes advantage of the Linux user-based protection as a meansof identifying and isolating application resources. The Android system assignsa unique user ID (UID) to each Android application and runs it as that user ina separate process.
This approach is different from other operating systems(including the traditional Linux configuration), where multiple applicationsrun with the same user permissions.
Thissets 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.
Sincethe Application Sandbox is in the kernel, this security model extends to nativecode and to operating system applications. All of the software above the kernelin
Figure1, including operating systemlibraries, application framework, application runtime, and all applications runwithin the Application Sandbox. On some platforms, developers are constrainedto a specific development framework, set of APIs, or language
in order toenforce security. On Android, there are no restrictions on how an applicationcan be written that are required to enforce security; in this respect, nativecode is just as secure as interpreted code.
Insome operating systems, memory corruption errors generally lead to completelycompromising the security of the device. This is not the case in Android due toall applications and their resources being sandboxed at the OS level. A memorycorruption error will
only allow arbitrary code execution in the context ofthat particular application, with the permissions established by the operatingsystem.
Likeall security features, the Application Sandbox is not unbreakable. However, tobreak out of the Application Sandbox in a properly configured device, one mustcompromise the security of the the Linux kernel.
System Partition andSafe Mode
Thesystem 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
Ina 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
Android3.0 and later provides full filesystem encryption, so all user data can beencrypted in the kernel using the dmcrypt implementation of AES128 with CBC andESSIV:SHA256. The encryption key is protected by AES128 using a key derivedfrom the user password,
preventing unauthorized access to stored data withoutthe user device password. To provide resistance against systematic passwordguessing attacks (e.g. “rainbow tables” or brute force), the password iscombined with a random salt and hashed repeatedly with SHA1
using the standardPBKDF2 algorithm prior to being used to decrypt the filesystem key. To provideresistance against dictionary password guessing attacks, Android providespassword complexity rules that can be set by the device administrator andenforced by the
operating system. Filesystem encryption requires the use of auser password, pattern-based screen lock is not supported.
Moredetails on implementation of filesystem encryption are available at
http://source.android.com/tech/encryption/android_crypto_implementation.html
Password Protection
Androidcan be configured to verify a user-supplied password prior to providing accessto a device. In addition to preventing unauthorized use of the device, thispassword protects the cryptographic key for full filesystem encryption.
Useof a password and/or password complexity rules can be required by a deviceadministrator.
Device Administration
Android2.2 and later provide the Android Device Administration API, which providesdevice administration features at the system level. For example, the built-inAndroid Email application uses the APIs to improve Exchange support. Throughthe 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.
Inaddition 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 ManagementSecurity Enhancements
Androidincludes many features that make common security issues harder to exploit. TheAndroid SDK, compilers, and OS use tools to make common memory corruptionissues significantly harder to exploit, including:
· Hardware-based No eXecute (NX) to prevent code execution onthe stack and heap
· ProPolice to prevent stack buffer overruns
· safe_iop to reduce integer overflows
· Extensions to OpenBSD dlmalloc to prevent double free()vulnerabilities and to prevent chunk consolidation attacks. Chunk consolidationattacks are a common way to exploit heap corruption.
· OpenBSD calloc to prevent integer overflows during memoryallocation
· Linux mmap_min_addr() to mitigate null pointer dereferenceprivilege escalation
Rooting of Devices
Bydefault, on Android only the kernel and a small subset of the core applicationsrun with root permissions. Android does not prevent a user or application withroot permissions from modifying the operating system, kernel, and any otherapplication. In general,
root has full access to all applications and allapplication data. Users that change the permissions on an Android device togrant root access to applications increase the security exposure to maliciousapplications and potential application flaws.
Theability to modify an Android device they own is important to developers workingwith the Android platform. On many Android devices users have the ability tounlock the bootloader in order to allow installation of an alternate operatingsystem. These alternate
operating systems may allow an owner to gain rootaccess for purposes of debugging applications and system components or toaccess features not presented to applications by Android APIs.
Onsome 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.
Encryptingdata with a key stored on-device does not protect the application data fromroot users. Applications can add a layer of data protection using encryptionwith a key stored off-device, such as on a server or a user password. Thisapproach can provide
temporary protection while the key is not present, but atsome point the key must be provided to the application and it then becomesaccessible to root users.
Amore 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.
Inthe 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.
AndroidApplication Security
Elements ofApplications
Androidprovides 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.
Themain Android application building blocks are:
· AndroidManifest.xml: The
AndroidManifest.xml file is the control file that tells the system what to dowith all the top-level components (specifically activities, services, broadcastreceivers, and content providers described below) in an application. This alsospecifies which permissions
are required.
· Activities: An
Activity is, generally, the code for a single, user-focused task. Itusually includes displaying a UI to the user, but it does not have to -- someActivities never display UIs. Typically, one of the application's Activities isthe entry point to an application.
· Services: A
Service is a body of code that runs in the background. It can runin its own process, or in the context of another application's process. Othercomponents "bind" to a Service and invoke methods on it via remoteprocedure calls. An example of a Service is a
media player: even when the userquits the media-selection UI, the user probably still intends for music to keepplaying. 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 mechanismknown as an
Intent is issued by the operating system or another application.An application may register a receiver for the low battery message, forexample, and change its behavior based
on that information.
The Android PermissionModel: Accessing Protected APIs
Bydefault, 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.
Theserestrictions are implemented in a variety of different forms. Some capabilitiesare restricted by an intentional lack of APIs to the sensitive functionality(e.g. there is no Android API for directly manipulating the SIM card). In someinstances, separation
of roles provides a security measure, as with theper-application isolation of storage. In other instances, the sensitive APIsare intended for use by trusted applications and protected through a securitymechanism known as Permissions.
Theseprotected APIs include:
· Camera functions
· Location data (GPS)
· Bluetooth functions
· Telephony functions
· SMS/MMS functions
· Network/data connections
Theseresources are only accessible through the operating system. To make use of theprotected APIs on the device, an application must define the capabilities itneeds in its manifest. When preparing to install an application, the systemdisplays a dialog to
the user that indicates the permissions requested and askswhether to continue the installation. If the user continues with theinstallation, the system accepts that the user has granted all of the requestedpermissions. The user can not grant or deny individual
permissions -- the usermust grant or deny all of the requested permissions as a block.
Oncegranted, 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 request permissionsfrom the user. Permissions are removed if an application is uninstalled, so asubsequent re-installation will again result in display of permissions.
Withinthe device settings, users are able to view permissions for applications theyhave previously installed. Users can also turn off some functionality globallywhen they choose, such as disabling GPS, radio, or wi-fi.
Inthe event that an application attempts to use a protected feature which has notbeen 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.
Thesystem default permissions are described at
http://code.google.com/android/reference/android/Manifest.permission.html. Applications may declare their own permissions for otherapplications to use. Such permissions are not listed in the above location.
Whendefining a permission a protectionLevel attribute tells the system how the useris to be informed of applications requiring the permission, or who is allowedto hold a permission. Details on creating and using application specificpermissions are described
at http://developer.android.com/guide/topics/security/security.html.
Thereare 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 UnderstandThird-Party Applications
Androidstrives to make it clear to users when they are interacting with third-partyapplications and inform the user of the capabilities those applications have.Prior to installation of any application, the user is shown a clear messageabout the different
permissions the application is requesting. After install,the user is not prompted again to confirm any permissions.
Thereare many reasons to show permissions immediately prior to installation time.This is when user is actively reviewing information about the application,developer, and functionality to determine whether it matches their needs andexpectations. It is also
important that they have not yet established a mentalor financial commitment to the app, and can easily compare the application to otheralternative applications.
Someother 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 user causes theuser 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 allabout application functionality. That approach prevents users from easilyunderstanding and discussing application capabilities. While it is not possiblefor all users to always make fully informed decisions,
the Android permissionsmodel makes information about applications easily accessible to a wide range ofusers. For example, unexpected permissions requests can prompt moresophisticated users to ask critical questions about application functionalityand share
their concerns in places such as the Android Marketwhere they are visible to all users.
|
|
|
Permissions at Application Install -- Google Maps
Permissions of an Installed Application -- gMail
Figure 2: Display of permissions for applications
InterprocessCommunication
Processescan communicate using any of the traditional UNIX-type mechanisms. Examplesinclude the filesystem, local sockets, or signals. However, the Linuxpermissions still apply.
Androidalso provides new IPC mechanisms:
· Binder: A lightweight capability-based remote procedure callmechanism designed for high performance when performing in-process andcross-process calls. Binder is implemented using a custom Linux driver. See
http://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 wantsto display a web page, it expresses its "Intent" to view the URL bycreating an Intent instance and handing
it off to the system. The system locatessome other piece of code (in this case, the Browser) that knows how to handlethat Intent, and runs it. Intents can also be used to broadcast interestingevents (such as a notification) system-wide. See
http://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. See
http://code.google.com/android/reference/android/content/ContentProvider.html.
Whileit is possible to implement IPC using other mechanisms such as network socketsor world-writable files, these are the recommended Android IPC frameworks.Android developers will be encouraged to use best practices around securingusers' data and avoiding
the introduction of security vulnerabilities.
Cost-Sensitive APIs
Acost 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
Lowlevel 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
Androidhas placed APIs that provide access to user data into the set of protectedAPIs. With normal usage, Android devices will also accumulate user data withinthird-party applications installed by users. Applications that choose to sharethis information
can use Android OS permission checks to protect the data fromthird-party applications.
Figure 3: Access to sensitive user data is only availablethrough protected APIs
Systemcontent 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 to accessthese resources. If permission is granted, the application can be installed andwill have access to the data requested at any
time when it is installed.
Anyapplications 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 InputDevices
Androiddevices frequently provide sensitive data input devices that allow applicationsto interact with the surrounding environment, such as camera, microphone orGPS. For a third-party application to access these devices, it must first beexplicitly provided
access by the user through the use of Android OSPermissions. Upon installation, the installer will prompt the user requestingpermission to the sensor by name.
Ifan 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 wirelessnetworks" and "Enable GPS satellites". This will disablelocation based services for all applications
on the user's device.
Device Metadata
Androidalso strives to restrict access to data that is not intrinsically sensitive,but may indirectly reveal characteristics about the user, user preferences, andthe manner in which they use a device.
Bydefault applications do not have access to operating system logs, browserhistory, phone number, or hardware / network identification information. If anapplication requests access to this information at install time, the installerwill prompt the user asking
if the application can access the information. Ifthe user does not grant access, the application will not be installed.
Application Signing
Codesigning 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.
OnAndroid 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.
OnAndroid, application signing is the first step to placing an application in itsApplication Sandbox. The signed application certificate defines which user idis 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.
Whenan 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.
Applicationscan be signed by a third-party (OEM, operator, alternative market) orself-signed. Android provides code signing using self-signed certificates thatdevelopers can generate without external assistance or permission. Applicationsdo not have to be
signed by a central authority. Android currently does notperform CA verification for application certificates.
Applicationsare also able to declare security permissions at the Signature protectionlevel, restricting access only to applications signed with the same key whilemaintaining distinct UIDs and Application Sandboxes. A closer relationship witha shared Application
Sandbox is allowed via the
shared UID feature where two or more applications signed with same developerkey can declare a shared UID in their manifest.
Digital RightsManagement
TheAndroid platform provides an extensible DRM framework that lets applicationsmanage rights-protected content according to the license constraints that areassociated with the content. The DRM framework supports many DRM schemes; whichDRM schemes a device
supports is left to the device manufacturer.
TheAndroid DRM framework is implemented in two architectural layers (see figurebelow):
· A DRM framework API, which is exposed to applicationsthrough the Android application framework and runs through the Dalvik VM forstandard applications.
· A native code DRM manager, which implements the DRMframework and exposes an interface for DRM plug-ins (agents) to handle rightsmanagement and decryption for various DRM schemes
Figure 4: Architecture of Digital Rights Management onAndroid platform
AndroidUpdates
Androidprovides system updates for both security and feature related purposes.
Thereare two ways to update the code on most Android devices: over-the-air (OTAupdates) or side-loaded updates. OTA updates can be rolled out over a definedtime period or be pushed to all devices at once, depending on how the OEMand/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.
Ifa dangerous vulnerability is discovered internally or responsibly reported toGoogle or the Android Open Source Project, the Android security team will startthe following process.
1. The Android team will notifycompanies who have signed NDAs regarding the problem and begin discussing thesolution.
2. The owners of code will begin thefix.
3. The Android team will fixAndroid-related security issues.
4. When a patch is available, the fixis provided to the NDA companies.
5. The Android team will publish thepatch in the Android Open Source Project
6. OEM/carrier will push an update tocustomers.
TheNDA is required to ensure that the security issue does not become public priorto availabilty of a fix and put users at risk. Many OHA members run their owncode 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 athand and similar problems. However, the OHA member who wrote the faulty code isultimately responsible for fixing the problem.
Ifa dangerous vulnerability is not responsibly disclosed (e.g., if it is postedto a public forum without warning), then Google and/or the Android Open SourceProject will work as quickly as possible to create a patch. The patch willreleased to the public
(and any partners) when the patch is tested and readyfor use.
AtGoogle 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.
Anydeveloper, Android user, or security researcher can notify the Android securityteam of potential security issues by sending email to security@android.com. Ifdesired, communication can be encrypted using the Android security team PGP keyavailable here:
https://developer.android.com/security_at_android_dot_com.txt.
OtherResources
Informationabout the Android Open Source Project is available at
http://source.android.com.
Informationfor Android application developers is here:
http://developer.android.com.
TheAndroid Security team can be reached at
security@android.com.
Securityinformation exists throughout the Android Open Source and Developer Sites. Agood place to start is here:
http://developer.android.com/guide/topics/security/security.html.
ASecurity FAQ for developers is located here:
http://developer.android.com/resources/faq/security.html.
A community resource for discussion about Android securityexists here:
http://groups.google.com/group/android-security-discuss.