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