Biometric authentication

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.

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.

Dynamic loading of SELinux policy

Do not 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 should not 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:

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.

Do not 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.

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, are not 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 should not 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. Do not require the
user to navigate into a menu or settings.

Describe the type of data being collected and explain how the data will
be used.

Ideally do not embed this information in a privacy policy or terms of
service. Do not include it with other disclosures unrelated to personal or
sensitive data collection.

Request for consent

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.

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

Do not 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.

Do not share signing keys with external parties.

If a signing key is compromised, generate a new key and double sign all
apps going forward.

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:

Unlock bootloader?

If you unlock the bootloader, you will be able to install custom
operating system software on this phone.

A custom OS is not subject to the same testing as the original OS, and
can cause your phone and installed apps to stop working properly.

Press the Volume Up/Down buttons to select Yes or No. Then press the
Power button to continue.

Yes: Unlock bootloader (may void warranty)

No: Do not unlock bootloader and restart phone.

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 must not 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 is not supported by the underlying block
device, ioctl(BLKDISCARD) must be used instead. On eMMC
devices, this is a normal Trim operation.

If BLKDISCARD is not supported, overwriting the block
devices with all zeros is acceptable.

A user must have the option to require that user data be wiped
beofre 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 (e.g. user data will be 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.

Content and code samples on this page are subject to the licenses described in the Content License. Java is a registered trademark of Oracle and/or its affiliates.