blob: 4c598a9d6fbecfa222df6acce89f0ba8bb46a1bf [file] [log] [blame] [view]
Adrian Ludwigbb084c52011-09-14 12:46:21 -07001[TOC]
2#Android Security Overview
3
4##Introduction
5
6Android is a modern mobile platform that was designed to be truly open. Android
7applications make use of advanced hardware and software, as well as local and
8served data, exposed through the platform to bring innovation and value to
9consumers. To protect that value, the platform must offer an application
10environment that ensures the security of users, data, applications, the device,
11and the network.
12
13Securing an open platform requires a robust security architecture and rigorous
14security programs. Android was designed with multi-layered security that
15provides the flexibility required for an open platform, while providing
16protection for all users of the platform.
17
18Android was designed with developers in mind. Security controls were designed
19to reduce the burden on developers. Security-savvy developers can easily work
20with and rely on flexible security controls. Developers less familiar with
21security will be protected by safe defaults.
22
23Android was designed with device users in mind. Users are provided visibility
24into how applications work, and control over those applications. This design
25includes the expectation that attackers would attempt to perform common
26attacks, such as social engineering attacks to convince device users to install
27malware, and attacks on third-party applications on Android. Android was
28designed to both reduce the probability of these attacks and greatly limit the
29impact of the attack in the event it was successful.
30
31This document outlines the goals of the Android security program, describes the
32fundamentals of the Android security architecture, and answers the most
33pertinent questions for system architects and security analysts. This document
34focuses on the security features of Android's core platform and does not
35discuss security issues that are unique to specific applications, such as those
36related to the browser or SMS application. Recommended best practices for
37building Android devices, deploying Android devices, or developing applications
38for Android are not the goal of this document and are provided elsewhere.
39
40# Background
41
42Android provides an open source platform and application environment for mobile
43devices.
44
45The main Android platform building blocks are:
46
47+ **Device Hardware**: Android runs on a wide range of hardware configurations
48including smart phones, tablets, and set-top-boxes. Android is
49processor-agnostic, but it does take advantage of some hardware-specific
50security capabilities such as ARM v6 eXecute-Never.
51
52+ **Android Operating System**: The core operating system is built on top of
53the Linux kernel. All device resources, like camera functions, GPS data,
54Bluetooth functions, telephony functions, network connections, etc. are
55accessed through the operating system.
56
57+ **Android Application Runtime**: Android applications are most often written
58in the Java programming language and run in the Dalvik virtual machine.
59However, many applications, including core Android services and applications
60are native applications or include native libraries. Both Dalvik and native
61applications run within the same security environment, contained within the
62Application Sandbox. Applications get a dedicated part of the filesystem in
63which they can write private data, including databases and raw files.
64
65Android applications extend the core Android operating system. There are two
66primary sources for applications:
67
68+ **Pre-Installed Applications**: Android includes a set of pre-installed
69applications including phone, email, calendar, web browser, and contacts. These
70function both as user applications and to provide key device capabilities that
71can be accessed by other applications. Pre-installed applications may be part
72of the open source Android platform, or they may be developed by an OEM for a
73specific device.
74
75+ **User-Installed Applications**: Android provides an open development
Jean-Baptiste Queru822f5292012-04-16 12:50:06 -070076environment supporting any third-party application. Google Play offers
Adrian Ludwigbb084c52011-09-14 12:46:21 -070077users hundreds of thousands of applications.
78
79Google provides a set of cloud-based services that are available to any
80compatible Android device. The primary services are:
81
Jean-Baptiste Queru822f5292012-04-16 12:50:06 -070082+ **Google Play**: Google Play is a collection of services that
Adrian Ludwigbb084c52011-09-14 12:46:21 -070083allow users to discover, install, and purchase applications from their Android
Jean-Baptiste Queru822f5292012-04-16 12:50:06 -070084device or the web. Google Play makes it easy for developers to reach Android
85users and potential customers. Google Play also provides community review,
Adrian Ludwigbb084c52011-09-14 12:46:21 -070086application [license
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -070087verification](https://developer.android.com/guide/publishing/licensing.html),
Adrian Ludwigbb084c52011-09-14 12:46:21 -070088and other security services.
89
90+ **Android Updates**: The Android update service delivers new capabilities and
91security updates to Android devices, including updates through the web or over
92the air (OTA).
93
94+ **Application Services**: Frameworks that allow Android applications to use
95cloud capabilities such as ([backing
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -070096up](https://developer.android.com/guide/topics/data/backup.html)) application
Adrian Ludwigbb084c52011-09-14 12:46:21 -070097data and settings and cloud-to-device messaging
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -070098([C2DM](https://code.google.com/android/c2dm/index.html))
Adrian Ludwigbb084c52011-09-14 12:46:21 -070099for push messaging.
100
101These services are not part of the Android Open Source Project and are out
102of scope for this document. But they are relevant to the security of most
103Android devices, so a related security document titled “Google Services for
104Android: Security Overview” is available.
105
106##Android Security Program Overview
107
108Early on in development, the core Android development team recognized that a
109robust security model was required to enable a vigorous ecosystem of
110applications and devices built on and around the Android platform and supported
111by cloud services. As a result, through its entire development lifecycle,
112Android has been subjected to a professional security program. The Android team
113has had the opportunity to observe how other mobile, desktop, and server platforms
114prevented and reacted to security issues and built a security
115program to address weak points observed in other offerings.
116
117The key components of the Android Security Program include:
118
119+ **Design Review**: The Android security process begins early in the
120development lifecycle with the creation of a rich and configurable security
121model and design. Each major feature of the platform is reviewed by engineering
122and security resources, with appropriate security controls integrated into the
123architecture of the system.
124+ **Penetration Testing and Code Review**: During the development of the
125platform, Android-created and open-source components are subject to vigorous
126security reviews. These reviews are performed by the Android Security Team,
127Google’s Information Security Engineering team, and independent security
128consultants. The goal of these reviews is to identify weaknesses and possible
129vulnerabilities well before the platform is open-sourced, and to simulate the
130types of analysis that will be performed by external security experts upon
131release.
132+ **Open Source and Community Review**: The Android Open Source Project enables
133broad security review by any interested party. Android also uses open source
134technologies that have undergone significant external security review,
Jean-Baptiste Queru822f5292012-04-16 12:50:06 -0700135such as the Linux kernel. Google Play provides a forum for users and companies
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700136to provide information about specific applications directly to users.
137+ **Incident Response**: Even with all of these precautions, security issues
138may occur after shipping, which is why the Android project has created a
139comprehensive security response process. A full-time Android security team
140constantly monitors Android-specific and the general security community for
141discussion of potential vulnerabilities. Upon the discovery of legitimate
142issues, the Android team has a response process that enables the rapid
143mitigation of vulnerabilities to ensure that potential risk to all Android
144users is minimized. These cloud-supported responses can include updating the
Jean-Baptiste Queru822f5292012-04-16 12:50:06 -0700145Android platform (over-the-air updates), removing applications from Google
146Play, and removing applications from devices in the field.
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700147
148##Android Platform Security Architecture
149
150Android seeks to be the most secure and usable operating system for mobile
151platforms by re-purposing traditional operating system security controls to:
152
153+ Protect user data
154+ Protect system resources (including the network)
155+ Provide application isolation
156
157To achieve these objectives, Android provides these key security features:
158
159+ Robust security at the OS level through the Linux kernel
160+ Mandatory application sandbox for all applications
161+ Secure interprocess communication
162+ Application signing
163+ Application-defined and user-granted permissions
164
165The sections below describe these and other security features of the Android
166platform. *Figure 1* summarizes the security components and considerations of
167the various levels of the Android software stack. Each component assumes that
168the components below are properly secured. With the exception of a small amount
169of Android OS code running as root, all code above the Linux Kernel is
170restricted by the Application Sandbox.
171
172![Figure 1: Android software stack](images/image00.png)
173
174*Figure 1: Android software stack.*
175
176#System and Kernel Level Security
177
178At the operating system level, the Android platform provides the security of
179the Linux kernel, as well as a secure inter-process communication (IPC)
180facility to enable secure communication between applications running in
181different processes. These security features at the OS level ensure that even
182native code is constrained by the Application Sandbox. Whether that code is
183the result of included application behavior or a exploitation of an application
184vulnerability, the system would prevent the rogue application from harming
185other applications, the Android system, or the device itself.
186
187##Linux Security
188
189The foundation of the Android platform is the Linux kernel. The Linux kernel
190itself has been in widespread use for years, and is used in millions of
191security-sensitive environments. Through its history of constantly being
192researched, attacked, and fixed by thousands of developers, Linux has become a
193stable and secure kernel trusted by many corporations and security
194professionals.
195
196As the base for a mobile computing environment, the Linux kernel provides
197Android with several key security features, including:
198
199+ A user-based permissions model
200+ Process isolation
201+ Extensible mechanism for secure IPC
202+ The ability to remove unnecessary and potentially insecure parts of the kernel
203
204As a multiuser operating system, a fundamental security objective of the Linux
205kernel is to isolate user resources from one another. The Linux security
206philosophy is to protect user resources from one another. Thus, Linux:
207
208+ Pevents user A from reading user B's files
209+ Ensures that user A does not exhaust user B's memory
210+ Ensures that user A does not exhaust user B's CPU resources
211+ Ensures that user A does not exhaust user B's devices (e.g. telephony, GPS,
212bluetooth)
213
214##The Application Sandbox
215
216The Android platform takes advantage of the Linux user-based protection as a
217means of identifying and isolating application resources. The Android system
218assigns a unique user ID (UID) to each Android application and runs it as that user
219in a separate process. This approach is different from other operating systems
220(including the traditional Linux configuration), where multiple applications
221run with the same user permissions.
222
223This sets up a kernel-level Application Sandbox. The kernel enforces security
224between applications and the system at the process level through standard Linux
225facilities, such as user and group IDs that are assigned to applications. By
226default, applications cannot interact with each other and applications have
227limited access to the operating system. If application A tries to do something
228malicious like read application B's data or dial the phone without permission
229(which is a separate application), then the operating system protects against
230this because application A does not have the appropriate user privileges. The
231sandbox is simple, auditable, and based on decades-old UNIX-style user
232separation of processes and file permissions.
233
234Since the Application Sandbox is in the kernel, this security model extends to
235native code and to operating system applications. All of the software above the
236kernel in *Figure 1*, including operating system libraries, application
237framework, application runtime, and all applications run within the Application
238Sandbox. On some platforms, developers are constrained to a specific
239development framework, set of APIs, or language in order to enforce security.
240On Android, there are no restrictions on how an application can be written that
241are required to enforce security; in this respect, native code is just as
242secure as interpreted code.
243
244In some operating systems, memory corruption errors generally lead to
245completely compromising the security of the device. This is not the case in
246Android due to all applications and their resources being sandboxed at the OS
247level. A memory corruption error will only allow arbitrary code execution in
248the context of that particular application, with the permissions established by
249the operating system.
250
251Like all security features, the Application Sandbox is not unbreakable.
252However, to break out of the Application Sandbox in a properly configured
253device, one must compromise the security of the the Linux kernel.
254
255##System Partition and Safe Mode
256
257The system partition contains Android's kernel as well as the operating system
258libraries, application runtime, application framework, and applications. This
259partition is set to read-only. When a user boots the device into Safe Mode,
260only core Android applications are available. This ensures that the user can
261boot their phone into an environment that is free of third-party software.
262
263##Filesystem Permissions
264
265In a UNIX-style environment, filesystem permissions ensure that one user cannot
266alter or read another user's files. In the case of Android, each application
267runs as its own user. Unless the developer explicitly exposes files to other
268applications, files created by one application cannot be read or altered by
269another application.
270
271##Filesystem Encryption
272
273Android 3.0 and later provides full filesystem encryption, so all user data can
274be encrypted in the kernel using the dmcrypt implementation of AES128 with CBC
275and ESSIV:SHA256. The encryption key is protected by AES128 using a key
276derived from the user password, preventing unauthorized access to stored data
277without the user device password. To provide resistance against systematic
278password guessing attacks (e.g. “rainbow tables” or brute force), the
279password is combined with a random salt and hashed repeatedly with SHA1 using
280the standard PBKDF2 algorithm prior to being used to decrypt the filesystem
281key. To provide resistance against dictionary password guessing attacks,
282Android provides password complexity rules that can be set by the device
283administrator and enforced by the operating system. Filesystem encryption
284requires the use of a user password, pattern-based screen lock is not supported.
285
286More details on implementation of filesystem encryption are available at
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -0700287[https://source.android.com/tech/encryption/android_crypto_implementation.html](/
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700288tech/encryption/android_crypto_implementation.html)
289
290##Password Protection
291
292Android can be configured to verify a user-supplied password prior to providing
293access to a device. In addition to preventing unauthorized use of the device,
294this password protects the cryptographic key for full filesystem encryption.
295
296Use of a password and/or password complexity rules can be required by a device
297administrator.
298
299##Device Administration
300
301Android 2.2 and later provide the Android Device Administration API, which
302provides device administration features at the system level. For example, the
303built-in Android Email application uses the APIs to improve Exchange support.
304Through the Email application, Exchange administrators can enforce password
305policies — including alphanumeric passwords or numeric PINs — across
306devices. Administrators can also remotely wipe (that is, restore factory
307defaults on) lost or stolen handsets.
308
309In addition to use in applications included with the Android system, these APIs
310are available to third-party providers of Device Management solutions. Details
311on the API are provided here:
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -0700312[https://developer.android.com/guide/topics/admin/device-admin.html](https://devel
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700313oper.android.com/guide/topics/admin/device-admin.html).
314
315
316##Memory Management Security Enhancements
317
318Android includes many features that make common security issues harder to
319exploit. The Android SDK, compilers, and OS use tools to make common memory
320corruption issues significantly harder to exploit, including:
321
Nick Kralevich56c7e222011-12-02 10:05:13 -0800322+ Address Space Layout Randomization (ASLR) to randomize key locations in memory
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700323+ Hardware-based No eXecute (NX) to prevent code execution on the stack and heap
324+ ProPolice to prevent stack buffer overruns
325+ safe_iop to reduce integer overflows
326+ Extensions to OpenBSD dlmalloc to prevent double free() vulnerabilities and
327to prevent chunk consolidation attacks. Chunk consolidation attacks are a
328common way to exploit heap corruption.
329+ OpenBSD calloc to prevent integer overflows during memory allocation
330+ Linux mmap_min_addr() to mitigate null pointer dereference privilege
331escalation
332
333##Rooting of Devices
334
335By default, on Android only the kernel and a small subset of the core
336applications run with root permissions. Android does not prevent a user or
337application with root permissions from modifying the operating system, kernel,
338and any other application. In general, root has full access to all
339applications and all application data. Users that change the permissions on an
340Android device to grant root access to applications increase the security
341exposure to malicious applications and potential application flaws.
342
343The ability to modify an Android device they own is important to developers
344working with the Android platform. On many Android devices users have the
345ability to unlock the bootloader in order to allow installation of an alternate
346operating system. These alternate operating systems may allow an owner to gain
347root access for purposes of debugging applications and system components or to
348access features not presented to applications by Android APIs.
349
350On some devices, a person with physical control of a device and a USB cable is
351able to install a new operating system that provides root privileges to the
352user. To protect any existing user data from compromise the bootloader unlock
353mechanism requires that the bootloader erase any existing user data as part of
354the unlock step. Root access gained via exploiting a kernel bug or security
355hole can bypass this protection.
356
357Encrypting data with a key stored on-device does not protect the application
358data from root users. Applications can add a layer of data protection using
359encryption with a key stored off-device, such as on a server or a user
360password. This approach can provide temporary protection while the key is not
361present, but at some point the key must be provided to the application and it
362then becomes accessible to root users.
363
364A more robust approach to protecting data from root users is through the use of
365hardware solutions. OEMs may choose to implement hardware solutions that limit
366access to specific types of content such as DRM for video playback, or the
367NFC-related trusted storage for Google wallet.
368
369In the case of a lost or stolen device, full filesystem encryption on Android
370devices uses the device password to protect the encryption key, so modifying
371the bootloader or operating system is not sufficient to access user data
372without the user’s device password.
373
374#Android Application Security
375
376##Elements of Applications
377
378Android provides an open source platform and application environment for mobile
379devices. The core operating system is based on the Linux kernel. Android
380applications are most often written in the Java programming language and run in
381the Dalvik virtual machine. However, applications can also be written in native
382code. Applications are installed from a single file with the .apk file
383extension.
384
385The main Android application building blocks are:
386
387+ **AndroidManifest.xml**: The
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -0700388[AndroidManifest.xml](https://developer.android.com/guide/topics/manifest/manifes
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700389t-intro.html) file is the control file that tells the system what to do with
390all the top-level components (specifically activities, services, broadcast
391receivers, and content providers described below) in an application. This also
392specifies which permissions are required.
393
394+ **Activities**: An
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -0700395[Activity](https://developer.android.com/guide/topics/fundamentals/activities.htm
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700396l) is, generally, the code for a single, user-focused task. It usually
397includes displaying a UI to the user, but it does not have to -- some
398Activities never display UIs. Typically, one of the application's Activities
399is the entry point to an application.
400
401+ **Services**: A
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -0700402[Service](https://developer.android.com/guide/topics/fundamentals/services.html)
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700403is a body of code that runs in the background. It can run in its own process,
404or in the context of another application's process. Other components "bind" to
405a Service and invoke methods on it via remote procedure calls. An example of a
406Service is a media player: even when the user quits the media-selection UI, the
407user probably still intends for music to keep playing. A Service keeps the
408music going even when the UI has completed.
409
410+ **Broadcast Receiver**: A
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -0700411[BroadcastReceiver](https://developer.android.com/reference/android/content/Broad
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700412castReceiver.html) is an object that is instantiated when an IPC mechanism
413known as an
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -0700414[Intent](https://developer.android.com/reference/android/content/Intent.html)
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700415is issued by the operating system or another application. An application may
416register a receiver for the low battery message, for example, and change its
417behavior based on that information.
418
419
420##The Android Permission Model: Accessing Protected APIs
421
422By default, an Android application can only access a limited range of system
423resources. The system manages Android application access to resources that, if
424used incorrectly or maliciously, could adversely impact the user experience,
425the network, or data on the device.
426
427These restrictions are implemented in a variety of different forms. Some
428capabilities are restricted by an intentional lack of APIs to the sensitive
429functionality (e.g. there is no Android API for directly manipulating the SIM
430card). In some instances, separation of roles provides a security measure, as
431with the per-application isolation of storage. In other instances, the
432sensitive APIs are intended for use by trusted applications and protected
433through a security mechanism known as Permissions.
434
435These protected APIs include:
436
437+ Camera functions
438+ Location data (GPS)
439+ Bluetooth functions
440+ Telephony functions
441+ SMS/MMS functions
442+ Network/data connections
443
444These resources are only accessible through the operating system. To make use
445of the protected APIs on the device, an application must define the
446capabilities it needs in its manifest. When preparing to install an
447application, the system displays a dialog to the user that indicates the
448permissions requested and asks whether to continue the installation. If the
449user continues with the installation, the system accepts that the user has
450granted all of the requested permissions. The user can not grant or deny
451individual permissions -- the user must grant or deny all of the requested
452permissions as a block.
453
454Once granted, the permissions are applied to the application as long as it is
455installed. To avoid user confusion, the system does not notify the user again
456of the permissions granted to the application, and applications that are
457included in the core operating system or bundled by an OEM do not request
458permissions from the user. Permissions are removed if an application is
459uninstalled, so a subsequent re-installation will again result in display of
460permissions.
461
462Within the device settings, users are able to view permissions for applications
463they have previously installed. Users can also turn off some functionality
464globally when they choose, such as disabling GPS, radio, or wi-fi.
465
466In the event that an application attempts to use a protected feature which has
467not been declared in the application's manifest, the permission failure will
468typically result in a security exception being thrown back to the application.
469Protected API permission checks are enforced at the lowest possible level to
470prevent circumvention. An example of the user messaging when an application is
471installed while requesting access to protected APIs is shown in *Figure 2*.
472
473The system default permissions are described at
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -0700474[https://developer.android.com/reference/android/Manifest.permission.html](https://developer.android.com/reference/android/Manifest.permission.html).
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700475Applications may declare their own permissions for other applications to use.
476Such permissions are not listed in the above location.
477
478When defining a permission a protectionLevel attribute tells the system how the
479user is to be informed of applications requiring the permission, or who is
480allowed to hold a permission. Details on creating and using application
481specific permissions are described at
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -0700482[https://developer.android.com/guide/topics/security/security.html](https://develo
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700483per.android.com/guide/topics/security/security.html).
484
485There are some device capabilities, such as the ability to send SMS broadcast
486intents, that are not available to third-party applications, but that may be
487used by applications pre-installed by the OEM. These permissions use the
488signatureOrSystem permission.
489
490##How Users Understand Third-Party Applications
491
492Android strives to make it clear to users when they are interacting with
493third-party applications and inform the user of the capabilities those
494applications have. Prior to installation of any application, the user is shown
495a clear message about the different permissions the application is requesting.
496After install, the user is not prompted again to confirm any permissions.
497
498There are many reasons to show permissions immediately prior to installation
499time. This is when user is actively reviewing information about the
500application, developer, and functionality to determine whether it matches their
501needs and expectations. It is also important that they have not yet
502established a mental or financial commitment to the app, and can easily compare
503the application to other alternative applications.
504
505Some other platforms use a different approach to user notification, requesting
506permission at the start of each session or while applications are in use. The
507vision of Android is to have users switching seamlessly between applications at
508will. Providing confirmations each time would slow down the user and prevent
509Android from delivering a great user experience. Having the user review
510permissions at install time gives the user the option to not install the
511application if they feel uncomfortable.
512
513Also, many user interface studies have shown that over-prompting the user
514causes the user to start saying "OK" to any dialog that is shown. One of
515Android's security goals is to effectively convey important security
516information to the user, which cannot be done using dialogs that the user will
517be trained to ignore. By presenting the important information once, and only
518when it is important, the user is more likely to think about what they are
519agreeing to.
520
521Some platforms choose not to show any information at all about application
522functionality. That approach prevents users from easily understanding and
523discussing application capabilities. While it is not possible for all users to
524always make fully informed decisions, the Android permissions model makes
525information about applications easily accessible to a wide range of users. For
526example, unexpected permissions requests can prompt more sophisticated users to
527ask critical questions about application functionality and share their concerns
Jean-Baptiste Queru822f5292012-04-16 12:50:06 -0700528in places such as [Google Play](htts://play.google.com) where they
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700529are visible to all users.
530
531<table>
532<tr>
533<td><strong>Permissions at Application Install -- Google Maps</strong></td>
534<td><strong>Permissions of an Installed Application -- gMail</strong></td>
535</tr>
536<tr>
537<td>
538<img alt="Permissions at Application Install -- Google Maps" width=250
539src="images/image_install.png"/>
540</td>
541<td>
542<img alt="Permissions of an Installed Application -- gMail" width=250
543src="images/image_gmail_installed.png"/>
544</td>
545</tr>
546</table>
547*Figure 2: Display of permissions for applications*
548
549##Interprocess Communication
550
551Processes can communicate using any of the traditional UNIX-type mechanisms.
552Examples include the filesystem, local sockets, or signals. However, the Linux
553permissions still apply.
554
555Android also provides new IPC mechanisms:
556
557+ **Binder**: A lightweight capability-based remote procedure call mechanism
558designed for high performance when performing in-process and cross-process
559calls. Binder is implemented using a custom Linux driver. See
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -0700560[https://developer.android.com/reference/android/os/Binder.html](https://developer
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700561.android.com/reference/android/os/Binder.html).
562
563+ **Services**: Services (discussed above) can provide interfaces directly
564accessible using binder.
565
566+ **Intents**: An Intent is a simple message object that represents an
567"intention" to do something. For example, if your application wants to display
568a web page, it expresses its "Intent" to view the URL by creating an Intent
569instance and handing it off to the system. The system locates some other piece
570of code (in this case, the Browser) that knows how to handle that Intent, and
571runs it. Intents can also be used to broadcast interesting events (such as a
572notification) system-wide. See
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -0700573[https://developer.android.com/reference/android/content/Intent.html](https://developer.android.com/reference/android/content/Intent.html.
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700574
575+ **ContentProviders**: A ContentProvider is a data storehouse that provides
576access to data on the device; the classic example is the ContentProvider that
577is used to access the user's list of contacts. An application can access data
578that other applications have exposed via a ContentProvider, and an application
579can also define its own ContentProviders to expose data of its own. See
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -0700580[https://developer.android.com/reference/android/content/ContentProvider.html](https://developer.android.com/reference/android/content/ContentProvider.html).
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700581
582While it is possible to implement IPC using other mechanisms such as network
583sockets or world-writable files, these are the recommended Android IPC
584frameworks. Android developers will be encouraged to use best practices around
585securing users' data and avoiding the introduction of security vulnerabilities.
586
587##Cost-Sensitive APIs
588
589A cost sensitive API is any function that might generate a cost for the user or
590the network. The Android platform has placed cost sensitive APIs in the list of
591protected APIs controlled by the OS. The user will have to grant explicit
592permission to third-party applications requesting use of cost sensitive APIs.
593These APIs include:
594
595+ Telephony
596+ SMS/MMS
597+ Network/Data
598+ In-App Billing
599+ NFC Access
600
601##SIM Card Access
602
603Low level access to the SIM card is not available to third-party apps. The OS
604handles all communications with the SIM card including access to personal
605information (contacts) on the SIM card memory. Applications also cannot access
606AT commands, as these are managed exclusively by the Radio Interface Layer
607(RIL). The RIL provides no high level APIs for these commands.
608
609##Personal Information
610
611Android has placed APIs that provide access to user data into the set of
612protected APIs. With normal usage, Android devices will also accumulate user
613data within third-party applications installed by users. Applications that
614choose to share this information can use Android OS permission checks to
615protect the data from third-party applications.
616
617![Figure 3: Access to sensitive user data is only available through protected
618APIs](images/image03.png)
619
620*Figure 3: Access to sensitive user data is only available through protected
621APIs*
622
623System content providers that are likely to contain personal or personally
624identifiable information such as contacts and calendar have been created with
625clearly identified permissions. This granularity provides the user with clear
626indication of the types of information that may be provided to the application.
627 During installation, a third-party application may request permission to
628access these resources. If permission is granted, the application can be
629installed and will have access to the data requested at any time when it is
630installed.
631
632Any applications which collect personal information will, by default, have that
633data restricted only to the specific application. If an application chooses to
634make the data available to other applications though IPC, the application
635granting access can apply permissions to the IPC mechanism that are enforced by
636the operating system.
637
638##Sensitive Data Input Devices
639
640Android devices frequently provide sensitive data input devices that allow
641applications to interact with the surrounding environment, such as camera,
642microphone or GPS. For a third-party application to access these devices, it
643must first be explicitly provided access by the user through the use of Android
644OS Permissions. Upon installation, the installer will prompt the user
645requesting permission to the sensor by name.
646
647If an application wants to know the user's location, the application requires a
648permission to access the user's location. Upon installation, the installer will
649prompt the user asking if the application can access the user's location. At
650any time, if the user does not want any application to access their location,
651then the user can run the "Settings" application, go to "Location & Security",
652and uncheck the "Use wireless networks" and "Enable GPS satellites". This will
653disable location based services for all applications on the user's device.
654
655##Device Metadata
656
657Android also strives to restrict access to data that is not intrinsically
658sensitive, but may indirectly reveal characteristics about the user, user
659preferences, and the manner in which they use a device.
660
661By default applications do not have access to operating system logs,
662browser history, phone number, or hardware / network identification
663information. If an application requests access to this information at install
664time, the installer will prompt the user asking if the application can access
665the information. If the user does not grant access, the application will not be
666installed.
667
668##Application Signing
669
670Code signing allows developers to identify the author of the application and to
671update their application without creating complicated interfaces and
672permissions. Every application that is run on the Android platform must be
673signed by the developer. Applications that attempt to install without being
Jean-Baptiste Queru822f5292012-04-16 12:50:06 -0700674signed will rejected by either Google Play or the package installer on
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700675the Android device.
676
Jean-Baptiste Queru822f5292012-04-16 12:50:06 -0700677On Google Play, application signing bridges the trust Google has with the
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700678developer and the trust the developer has with their application. Developers
679know their application is provided, unmodified to the Android device; and
680developers can be held accountable for behavior of their application.
681
682On Android, application signing is the first step to placing an application in
683its Application Sandbox. The signed application certificate defines which user
684id is associated with which application; different applications run under
685different user IDs. Application signing ensures that one application cannot
686access any other application except through well-defined IPC.
687
688When an application (APK file) is installed onto an Android device, the Package
689Manager verifies that the APK has been properly signed with the certificate
690included in that APK. If the certificate (or, more accurately, the public key
691in the certificate) matches the key used to sign any other APK on the device,
692the new APK has the option to specify in the manifest that it will share a UID
693with the other similarly-signed APKs.
694
695Applications can be signed by a third-party (OEM, operator, alternative market)
696or self-signed. Android provides code signing using self-signed certificates
697that developers can generate without external assistance or permission.
698Applications do not have to be signed by a central authority. Android currently
699does not perform CA verification for application certificates.
700
701Applications are also able to declare security permissions at the Signature
702protection level, restricting access only to applications signed with the same
703key while maintaining distinct UIDs and Application Sandboxes. A closer
704relationship with a shared Application Sandbox is allowed via the [shared UID
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -0700705feature](https://developer.android.com/guide/topics/manifest/manifest-element.htm
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700706l#uid) where two or more applications signed with same developer key can
707declare a shared UID in their manifest.
708
709##Digital Rights Management
710
711The Android platform provides an extensible DRM framework that lets
712applications manage rights-protected content according to the license
713constraints that are associated with the content. The DRM framework supports
714many DRM schemes; which DRM schemes a device supports is left to the device
715manufacturer.
716
717The [Android DRM
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -0700718framework](https://developer.android.com/reference/android/drm/package-summary.ht
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700719ml) is implemented in two architectural layers (see figure below):
720
721+ A DRM framework API, which is exposed to applications through the Android
722application framework and runs through the Dalvik VM for standard applications.
723
724+ A native code DRM manager, which implements the DRM framework and exposes an
725interface for DRM plug-ins (agents) to handle rights management and decryption
726for various DRM schemes
727
728![Figure 4: Architecture of Digital Rights Management on Android
729platform](images/image02.png)
730
731*Figure 4: Architecture of Digital Rights Management on Android platform*
732
733#Android Updates
734
735Android provides system updates for both security and feature related purposes.
736
737There are two ways to update the code on most Android devices: over-the-air
738(OTA updates) or side-loaded updates. OTA updates can be rolled out over a
739defined time period or be pushed to all devices at once, depending on how the
740OEM and/or carrier would like to push the updates. Side-loaded updates can be
741provided from a central location for users to download as a zip file to their
742local desktop machine or directly to their handset. Once the update is copied
743or downloaded to the SD card on the device, Android will recognize the update,
744verify its integrity and authenticity, and automatically update the device.
745
746If a dangerous vulnerability is discovered internally or responsibly reported
747to Google or the Android Open Source Project, the Android security team will
748start the following process.
749
7501. The Android team will notify companies who have signed NDAs regarding the
751problem and begin discussing the solution.
7522. The owners of code will begin the fix.
7533. The Android team will fix Android-related security issues.
7544. When a patch is available, the fix is provided to the NDA companies.
7555. The Android team will publish the patch in the Android Open Source Project
7566. OEM/carrier will push an update to customers.
757
758The NDA is required to ensure that the security issue does not become public
759prior to availabilty of a fix and put users at risk. Many OHA members run their
760own code on Android devices such as the bootloader, wifi drivers, and the
761radio. Once the Android Security team is notified of a security issue in this
762partner code, they will consult with OHA partners to quickly find a fix for the
763problem at hand and similar problems. However, the OHA member who wrote the
764faulty code is ultimately responsible for fixing the problem.
765
766If a dangerous vulnerability is not responsibly disclosed (e.g., if it is
767posted to a public forum without warning), then Google and/or the Android Open
768Source Project will work as quickly as possible to create a patch. The patch
769will released to the public (and any partners) when the patch is tested and
770ready for use.
771
772At Google I/O 2011, many of the largest OHA partners committed to providing
773updates to devices for 18 months after initial shipment. This will provide
774users with access to the most recent Android features, as well as security
775updates.
776
777Any developer, Android user, or security researcher can notify the Android
778security team of potential security issues by sending email to
779security@android.com. If desired, communication can be encrypted using the
780Android security team PGP key available here:
781[https://developer.android.com/security_at_android_dot_com.txt](https://develope
782r.android.com/security_at_android_dot_com.txt).
783
784#Other Resources
785
786Information about the Android Open Source Project is available at
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -0700787[https://source.android.com](https://source.android.com).
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700788
789Information for Android application developers is here:
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -0700790[https://developer.android.com](https://developer.android.com).
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700791
792The Android Security team can be reached at
793[security@android.com](mailto:security@android.com).
794
795Security information exists throughout the Android Open Source and Developer
796Sites. A good place to start is here:
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -0700797[https://developer.android.com/guide/topics/security/security.html](https://develo
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700798per.android.com/guide/topics/security/security.html).
799
800A Security FAQ for developers is located here:
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -0700801[https://developer.android.com/resources/faq/security.html](https://developer.andr
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700802oid.com/resources/faq/security.html).
803
804A community resource for discussion about Android security exists here:
Jean-Baptiste Queru60c81412012-04-19 15:00:44 -0700805[https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss](https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss).
Adrian Ludwigbb084c52011-09-14 12:46:21 -0700806