App security

Elements of apps

Android provides an open source platform and app environment for mobile devices. The core operating system is based on the Linux kernel. Android apps are most often written in the Java programming language and run in the Android Runtime (ART) virtual machine. However, apps can also be written in native code. Apps are installed from a single file with the APK file extension.

The main Android app building blocks are:

  • AndroidManifest.xml: The AndroidManifest.xml file is the control file that tells the system what to do with all the top-level components (specifically activities, services, broadcast receivers, and content providers described below) in an app. This also specifies which permissions are required.

  • Activities: An activity is, generally, the code for a single, user-focused task using the Activity class. An activity usually includes displaying a UI to the user, but it doesn't have to; some activities never display UIs. Typically, one of the app's activities is the entry point to an app.

  • Services: A Service is a body of code that runs in the background. It can run in its own process, or in the context of another app's process. Other components "bind" to a Service and invoke methods on it via remote procedure calls. An example of a Service is a media player: even when the user quits the media-selection UI, the user probably still intends for music to keep playing. A Service keeps the music going even when the UI has completed.

  • Broadcast Receiver: A BroadcastReceiver is an object that is instantiated when an IPC mechanism known as an Intent is issued by the operating system or another app. An app may register a receiver for the low battery message, for example, and change its behavior based on that information.

Android permission model: Access protected APIs

All apps on Android run in an Application Sandbox. By default, an Android app can only access a limited range of system resources. The system manages Android app access to resources that, if used incorrectly or maliciously, could adversely impact the user experience, the network, or data on the device.

These restrictions are implemented in a variety of different forms. Some capabilities are restricted by an intentional lack of APIs to the sensitive functionality (for example, there is no Android API for directly manipulating the SIM card). In some instances, separation of roles provides a security measure, as with the per-app isolation of storage. In other instances, the sensitive APIs are intended for use by trusted apps and protected through a security mechanism known as Permissions.

These protected APIs include:

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

These resources are only accessible through the operating system. To make use of the protected APIs on the device, an app must define the capabilities it needs in its manifest. All Android versions 6.0 and higher use a runtime permissions model. If a user requests a feature from an app that requires a protected API the system displays a dialog, prompting the user to deny or allow the permission.

Once granted, the permissions are applied to the app as long as it is installed. To avoid user confusion, the system doesn't notify the user again of the permissions granted to the app, and apps that are included in the core operating system or bundled by an OEM don't request permissions from the user. Permissions are removed if an app is uninstalled, so a subsequent reinstallation again results in a display of permissions.

Within the device settings, users are able to view permissions for apps they have previously installed. Users can also turn off some functionality globally when they choose, such as disabling GPS, radio, or Wi-Fi.

In the event that an app attempts to use a protected feature which hasn't been declared in the app's manifest, the permission failure typically results in a security exception being thrown back to the app. Protected API permission checks are enforced at the lowest possible level to prevent circumvention. An example of the user messaging when an app is installed while requesting access to protected APIs is shown in Figure 2.

The system default permissions are described at https://developer.android.com/reference/android/Manifest.permission.html. Apps may declare their own permissions for other apps to use. Such permissions aren't listed in the above location.

When defining a permission a protectionLevel attribute tells the system how the user is to be informed of apps requiring the permission, or who is allowed to hold a permission. Details on creating and using app specific permissions are described at https://developer.android.com/guide/topics/security/security.html.

There are some device capabilities, such as the ability to send SMS broadcast intents, that aren't available to third-party apps, but that may be used by apps pre-installed by the OEM. These permissions use the signatureOrSystem permission.

How users understand third-party apps

Android strives to make it clear to users when they are interacting with third-party apps and inform the user of the capabilities those apps have. Prior to installation of any app, the user is shown a clear message about the different permissions the app is requesting. After install, the user isn't prompted again to confirm any permissions.

There are many reasons to show permissions immediately prior to installation time. This is when user is actively reviewing information about the app, developer, and functionality to determine whether it matches their needs and expectations. It is also important that they haven't yet established a mental or financial commitment to the app, and can easily compare the app to other alternative apps.

Some other platforms use a different approach to user notification, requesting permission at the start of each session or while apps are in use. The vision of Android is to have users switching seamlessly between apps at will. Providing confirmations each time would slow down the user and prevent Android from delivering a great user experience. Having the user review permissions at install time gives the user the option to not install the app if they feel uncomfortable.

Also, many user interface studies have shown that over-prompting the user causes the user to start saying "OK" to any dialog that is shown. One of Android's security goals is to effectively convey important security information to the user, which can't be done using dialogs that the user will be trained to ignore. By presenting the important information once, and only when it is important, the user is more likely to think about what they are agreeing to.

Some platforms choose not to show any information at all about app functionality. That approach prevents users from easily understanding and discussing app capabilities. While it isn't possible for all users to always make fully informed decisions, the Android permissions model makes information about apps easily accessible to a wide range of users. For example, unexpected permissions requests can prompt more sophisticated users to ask critical questions about app functionality and share their concerns in places such as Google Play where they are visible to all users.

Permissions at app install — Google Translate Permissions of an installed app — Gmail
Permissions at Application Install -- Google Translate Permissions of an Installed Application — Gmail

Figure 1. Display of permissions for apps

Interprocess communication

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

Android also provides new IPC mechanisms:

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

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

  • Intents: An Intent is a simple message object that represents an "intention" to do something. For example, if your app wants to display a web page, it expresses its "Intent" to view the URL by creating an Intent instance and handing it off to the system. The system locates some other piece of code (in this case, the Browser) that knows how to handle that Intent, and runs it. Intents can also be used to broadcast interesting events (such as a notification) system-wide. See https://developer.android.com/reference/android/content/Intent.html.

  • ContentProviders: A ContentProvider is a data storehouse that provides access to data on the device; the classic example is the ContentProvider that is used to access the user's list of contacts. An app can access data that other apps have exposed via a ContentProvider, and an app can also define its own ContentProviders to expose data of its own. See https://developer.android.com/reference/android/content/ContentProvider.html.

While it is possible to implement IPC using other mechanisms such as network sockets or world-writable files, these are the recommended Android IPC frameworks. Android developers will be encouraged to use best practices around securing users' data and avoiding the introduction of security vulnerabilities.

Cost-sensitive APIs

A cost sensitive API is any function that might generate a cost for the user or the network. The Android platform has placed cost sensitive APIs in the list of protected APIs controlled by the OS. The user will have to grant explicit permission to third-party apps requesting use of cost sensitive APIs. These APIs include:

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

Android 4.2 adds further control on the use of SMS. Android will provide a notification if an app attempts to send SMS to a short code that uses premium services which might cause additional charges. The user can choose whether to allow the app to send the message or block it.

SIM card access

Low level access to the SIM card isn't available to third-party apps. The OS handles all communications with the SIM card including access to personal information (contacts) on the SIM card memory. Apps also can't access AT commands, as these are managed exclusively by the Radio Interface Layer (RIL). The RIL provides no high level APIs for these commands.

Personal information

Android has placed APIs that provide access to user data into the set of protected APIs. With normal usage, Android devices will also accumulate user data within third-party apps installed by users. Apps that choose to share this information can use Android OS permission checks to protect the data from third-party apps.

Access to sensitive user data available only through protected APIs

Figure 2. Access to sensitive user data is available only through protected APIs

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

Any apps which collect personal information will, by default, have that data restricted only to the specific app. If an app chooses to make the data available to other apps though IPC, the app granting access can apply permissions to the IPC mechanism that are enforced by the operating system.

Sensitive data input devices

Android devices frequently provide sensitive data input devices that allow apps to interact with the surrounding environment, such as camera, microphone or GPS. For a third-party app to access these devices, it must first be explicitly provided access by the user through the use of Android OS Permissions. Upon installation, the installer will prompt the user requesting permission to the sensor by name.

If an app wants to know the user's location, the app requires a permission to access the user's location. Upon installation, the installer will prompt the user asking if the app can access the user's location. At any time, if the user doesn't want any app to access their location, then the user can run the "Settings" app, go to "Location & Security", and uncheck the "Use wireless networks" and "Enable GPS satellites". This will disable location based services for all apps on the user's device.

Device metadata

Android also strives to restrict access to data that isn't intrinsically sensitive, but may indirectly reveal characteristics about the user, user preferences, and the manner in which they use a device.

By default apps don't have access to operating system logs, browser history, phone number, or hardware / network identification information. If an app requests access to this information at install time, the installer will prompt the user asking if the app can access the information. If the user doesn't grant access, the app won't be installed.

Certificate authorities

Android includes a set of installed system Certificate Authorities, which are trusted system-wide. Prior to Android 7.0, device manufacturers could modify the set of CAs shipped on their devices. However, devices running 7.0 and above will have a uniform set of system CAs as modification by device manufacturers is no longer permitted.

To be added as a new public CA to the Android stock set, the CA must complete the Mozilla CA Inclusion Process and then file a feature request against Android ( https://code.google.com/p/android/issues/entry) to have the CA added to the stock Android CA set in the Android Open Source Project (AOSP).

There are still CAs that are device-specific and shouldn't be included in the core set of AOSP CAs, like carriers' private CAs that may be needed to securely access components of the carrier's infrastructure, such as SMS/MMS gateways. Device manufacturers are encouraged to include the private CAs only in the components/apps that need to trust these CAs. For more details, see Network Security Configuration.

App signing

Code signing allows developers to identify the author of the app and to update their app without creating complicated interfaces and permissions. Every app that is run on the Android platform must be signed by the developer. Apps that attempt to install without being signed are rejected by either Google Play or the package installer on the Android device.

On Google Play, app signing bridges the trust Google has with the developer and the trust the developer has with their app. Developers know their app is provided, unmodified to the Android device; and developers can be held accountable for behavior of their app.

On Android, app signing is the first step to placing an app in its App Sandbox. The signed app certificate defines which user id is associated with which app; different apps run under different user IDs. App signing ensures that one app can't access any other app except through well-defined IPC.

When an app (APK file) is installed onto an Android device, the Package Manager verifies that the APK has been properly signed with the certificate included in that APK. If the certificate (or, more accurately, the public key in the certificate) matches the key used to sign any other APK on the device, the new APK has the option to specify in the manifest that it will share a UID with the other similarly-signed APKs.

Apps can be signed by a third-party (OEM, operator, alternative market) or self-signed. Android provides code signing using self-signed certificates that developers can generate without external assistance or permission. Apps don't have to be signed by a central authority. Android currently doesn't perform CA verification for app certificates.

Apps are also able to declare security permissions at the Signature protection level, restricting access only to apps signed with the same key while maintaining distinct UIDs and Application Sandboxes. A closer relationship with a shared Application Sandbox is allowed via the shared UID feature where two or more apps signed with same developer key can declare a shared UID in their manifest.

App verification

Android 4.2 and later support app verification. Users can choose to enable “Verify Apps" and have apps evaluated by an app verifier prior to installation. App verification can alert the user if they try to install an app that might be harmful; if an app is especially bad, it can block installation.

Digital rights management

The Android platform provides an extensible digital rights management (DRM) framework that lets apps manage rights-protected content according to the license constraints that are associated with the content. The DRM framework supports many DRM schemes; which DRM schemes a device supports is left to the device manufacturer.

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

  • A DRM framework API, which is exposed to apps through the Android app framework and runs through the ART VM for standard apps.

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

Architecture of Digital Rights Management on Android platform

Figure 3. Architecture of DRM on Android platform