System security best practices

This section contains recommendations for ensuring the security of the core Android operating system and devices.

Biometric authentication

Acquire, store, and process biometric data for user authentication carefully. You should:

  • Mandate the primary authentication method before using any other form of authentication (including biometrics).
  • Require an explicit confirmation to indicate intent when using passive biometric modalities, such as facial recognition, for transactions (for example, payments) that involve authentication-bound keys.
  • Require the primary authentication method every 72 hours.
  • Use a fully secure pipeline for all biometric data and handling.
  • Never send biometric data (including raw sensor measurements and derived features) off-device. If possible, keep this data in a secure isolated environment, such as the Trusted Execution Environment (TEE) or Secure Element.

Devices with biometrics should support the BiometricPrompt API, which offers a common and consistent interface for app developers to take advantage of biometrics-based authentication in their apps. Only strong biometrics can integrate with BiometricPrompt and integrations must follow Android Compatibility Definition Document (CDD) guidelines.

For more biometric guidelines, see Biometric HAL implementation guidelines.

SELinux

SELinux provides the definition and enforcement of much of Android's security model. Correctly using SELinux is critical to the security of Android devices and can help mitigate the impact of security vulnerabilities. All Android devices should implement a robust SELinux policy for this reason.

  • Implement a least privilege policy.
  • Avoid granting CAP_DAC_OVERRIDE, CAP_SYS_ADMIN, and CAP_NET_ADMIN permissions.
  • Don't log system data to the SD card.
  • Use provided types for driver access, such as gpu_device, audio_device, etc.
  • Use meaningful names for processes, files, and SELinux types.
    • Ensure default labels aren't used and access isn't granted to them.
  • Device-specific policy should account for 5 to 10% of the overall policy running on a device. Customizations in the 20%+ range almost certainly contain over-privileged domains and dead policy. Unnecessarily large policy wastes memory, wastes disk space by necessitating a larger boot image, and negatively affects runtime policy lookup times.

Dynamic loading of SELinux policy

Don't dynamically load SELinux policy on Android devices. Doing so can result in issues, such as:

  • Preventing the acceptance of critical security patches.
  • Exposing the ability to root a device through reloading of policies.
  • Exposing a vector for man-in-the-middle attacks against the policy updater.
  • Resulting in bricked devices due to errors with policy updates.

Backdoors

Android apps shouldn't have any backdoors or ways to access the system or data that bypass normal security mechanisms. This includes diagnostics, debugging, development, or warranty repair special access gated by secrets known to the developer. To prevent backdoors:

  • Scan all third-party apps using an industry-recognized app vulnerability scanning tool.
  • Perform code reviews of all code with sensitive access, including third-party libraries.
  • Utilize Google Play Protect by uploading apps to Google Play for scanning. You can upload apps for scanning without publishing to Google Play.
  • Don't preload diagnostics- or repair-focused tools on release builds. Only install these tools on-demand to solve specific issues. Additionally, these tools must not operate upon or upload any account-specific data.

Development tools

Development tools, such as debugging, testing, and diagnostic tools, can often create unintended security gaps on your device by revealing how they operate and the data that they collect. To make sure that development tools don't make it into production builds:

  • Develop a blacklist of in-house debug and testing tool hashes and scan builds for these APKs prior to using the system image.
  • Scan all first-party apps using an industry-recognized app vulnerability scanning tool.
  • Hire a third-party app security testing firm to evaluate all critical on-device diagnostic apps before any major update, especially if the app is developed by a third party.
  • Ensure that only the user can enable the tool, either verbally or over chat, during a support session. Store artifacts of consent and disable the tool after collecting the necessary diagnostic information.
  • Store this tool's record of use in a log accessible by the user in their carrier account.
  • Ensure that any personally identifiable information (PII) or device telemetry data collected by the tool is subject to anonymization, retention and deletion practices relevant to the country. Only data relevant for the support call should be collected. This data should be deleted after each call.
  • Ensure that techniques that can be used for spyware, such as keystroke logging, microphone usage, or camera usage, aren't used without explicit user consent. Apps utilizing these potentially privacy-invasive methods should be very clearly disclosed along with a privacy policy that the user must consent to. Apps like this shouldn't be enabled without explicit consent by the user.

Here are some additional suggestions to refer to when implementing disclosure and consent:

In-app disclosure

  • Display the normal usage of the app directly in-app. Don't require the user to navigate into a menu or settings.
  • Describe the type of data being collected and explain how the data is used.
  • Ideally don't embed this information in a privacy policy or terms of service. Don't include it with other disclosures unrelated to personal or sensitive data collection.
  • Consent must be affirmative. Don't consider navigation away from the disclosure, including tapping away or pressing the back or home button, as consent.
  • Present the consent dialog in a clear and unambiguous way.
  • Require affirmative user action, such as tap to accept or speak a command, to accept.
  • Don't collect personal or sensitive data before obtaining affirmative consent.
  • Don't use auto-dismissing or expiring messages.

Embedded functionality in AOSP

Embedding additional functionality in AOSP can often have unexpected behavior and consequences; proceed with caution.

  • Ensure that the user is prompted if they want to use different default apps (for example, search engine, web browser, launcher) and disclose sending data off device.
  • Ensure that AOSP APKs are signed with the AOSP certificate.
  • Run regression tests and keep a change-log to determine whether the AOSP APKs have had code added.

Security updates

Android devices should receive ongoing security support for at least two years from launch. This includes receiving regular updates that address known security vulnerabilities.

  • Work with hardware partners, such as your SoC vendors, to put appropriate support agreements in place for all components on your Android device.
  • Ensure that security updates can be installed with minimal user interaction to increase the likelihood of users accepting and installing updates on their Android device. Implementing Seamless System Updates or an equivalent security feature is strongly recommended.
  • Ensure that you understand the cumulative requirement of the Android Security Patch Level (SPL) as declared in the Android Security Bulletin. For example, devices that use the 2018-02-01 security patch level must include all issues associated with that security patch level, as well as fixes for all issues reported in all previous security bulletins.

Dynamic kernel updates

Don't dynamically modify critical system components. While there is some research to suggest that dynamic kernel updates help protect against emergency threats, the assessed cost currently outweighs the benefits. Instead, create a robust OTA update method to quickly distribute vulnerability protections.

Key management

Maintain good key management policies and practices to ensure the security of signing keys.

  • Don't share signing keys with external parties.
  • If a signing key is compromised, generate a new key and double sign all apps going forward.
  • Store all keys in high-security module hardware or services requiring multiple factors to access.

System image signing

The signature of the system image is critical to determine device integrity.

  • Don't sign devices with a publicly known key.
  • Manage device-signing keys in a manner consistent with industry-standard practices for handling sensitive keys, including a hardware security module (HSM) that provides limited, auditable access.

Unlockable bootloaders

Many Android devices support unlocking, enabling the device owner to modify the system partition or install a custom operating system. Common use cases include installing a third-party system image and performing systems-level development on the device. For example, to unlock the system image on a Google Nexus or Pixel, a user can run fastboot oem unlock, which displays this message:

As a best practice, unlockable Android devices must securely erase all user data prior to being unlocked. Failure to properly delete all data on unlocking may allow a physically proximate attacker to gain unauthorized access to confidential Android user data. To prevent the disclosure of user data, a device that supports unlocking must implement it properly.

  • After the user confirms the unlocking command, the device must start an immediate data wipe. The unlocked flag mustn't be set until after the secure deletion is complete.
  • If a secure deletion can't be completed, the device must stay in a locked state.
  • If supported by the underlying block device, ioctl(BLKSECDISCARD)or equivalent should be used. For embedded MultiMediaCard (eMMC) devices, this means using a Secure Erase or Secure Trim command. For eMMC 4.5 and later, this means using a normal Erase or Trim followed by a Sanitize operation.
  • If BLKSECDISCARD isn't supported by the underlying block device, ioctl(BLKDISCARD) must be used instead. On eMMC devices, this is a normal Trim operation.
  • If BLKDISCARD isn't supported, overwriting the block devices with all zeros is acceptable.
  • A user must have the option to require that user data be wiped before flashing a partition. For example, Nexus devices use the fastboot oem lock command to wipe user data.
  • A device may record, via eFuses or similar mechanism, whether a device was unlocked and/or relocked. However, we strongly recommend that relocking the bootloader with subsequent factory reset should restore full device functionality.

These requirements ensure that all data is destroyed upon the completion of an unlock operation. Failure to implement these protections is considered a moderate level security vulnerability.

A device that is unlocked may be subsequently relocked using the fastboot oem lock command. Locking the bootloader provides the same protection of user data with the new custom OS as was available with the original device manufacturer OS (for example, user data is wiped if the device is unlocked again).

Device pentesting

Devices should be reviewed by a competent pentester prior to shipment. Pentesting should establish that the device followed security guidance provided here as well as internal OEM security guidance.

Security testing

Use the Security Testing tools provided by AOSP. In particular

  • Use memory safety tools during development: use MTE where supported (ARMv9 and above), and HWASan where it isn't. Run as many tests as possible with these tools enabled.
  • Use GWP-ASan and KFENCE in production, for probabilistic detection of memory safety issues.