When requesting any Android permission, the developer must provide documentation as to the need for the permission.
Passwords should be masked so that they are not visibly displayed.
Passwords must be at least # characters long.
Insert additional password requirements.
Passwords must be encrypted in transit when transmitted.
Mobile devices require the use of a standard Notice and Consent banner, the contents of which are detailed in this section. The banner shall be implemented as a click-through at logon to the device or application.
Sensitive and personally identifiable information (PII) shall be protected by means of FIPS 140-2 compliant cryptographic algorithms and implementations.
Sensitive data should not be stored in the /sdcard partition.
Sensitive data should not be stored in files with world-read or world-write permissions.
Text fields should be strongly typed, meaning that the allowed characters, lengths, and ranges are known and enforced through input validation.
User input should not be directly passed to SQL queries. Instead, prepared or parameterized statements should be used for SQL queries.
The Java Class.forName, Class.newInstance, and Runtime.exec method calls should be avoided, with native Java calls used instead of making system calls when possible. If these methods need to be used, the developer must justify their use in documentation.
All Android application packages must be signed by a private key associated with a certificate held by the application developer or a trusted authority.
Application developers should avoid use of the Android NDK or Java JNI unless their use is necessary. Developers must justify in writing any use of the NDK or JNI.
Mobile applications should use data-in-transit encryption for all transmitted information unless a specific reason exists not to, which must be justified in writing.
SSL version 2.0 must not be used.
TLS versions 1.0, 1.1, 1.2, or above should be used.
In RSA PKI certificate environments, the TLS recommended cipher suites are:
In elliptic curve PKI certificate environments, the TLS recommended cipher suites are:
Android applications should be configured to only trust the appropriate PKI root certification authorities that are needed for communication by that application, rather than using the default Android root certificate list.
FIPS validated cryptographic implementations should be used.
TLS clients must always authenticate the server's certificate.
TLS client certificate authentication should be used when possible as it is a strong authentication method.
When username and password authentication is used, storing passwords on the Android device is prohibited. Instead, the client should obtain an authentication token from the server and store that instead if needed.
When IPsec VPNs are used, the guidance in NIST Special Publication 800-77 and 800-57 Part 3 should be followed. A FIPS validated IPsec client should be used.
Sensitive information such as phone number,device serial number, and device ID should not be used to identify connections.
Applications should use explicit Intents whenever it is possible to address a specific destination component.
Applications must use explicit Intents if the Intent is for an internal component (intra-application communication).
When sending broadcast Intents, applications should define a custom permission (or use existing appropriate permission) and only send the Intent to receivers that hold the permission in order to control who can receive the Intent. If all receiving applications are written by the same developer and signed by the same key, the permission should be declared as a signature-level permission.
Especially when implicit Intents are used, applications should avoid placing sensitive information inside the Intent. Applications should also perform input validation on any received response.
Before sending an explicit Intent, an application should check that the receiving application holds an appropriate permission to receive the Intent. In especially sensitive environments, an application should check the receiving application's package signature to ensure that it matches an expected value.
Internal application components (that have no need to be invoked by other applications) should explicitly be declared as not exported in the manifest
Applications must perform null checks on all received Intents.
Applications must ensure that received broadcast messages match an expected action before continuing processing them.
Applications should set permissions on their external components to control which other applications can invoke them. In especially sensitive environments, the application should obtain the sending application's package signature to ensure that it matches an expected value.
Sticky Broadcasts should not be used to send Intents with sensitive information.
Content Providers must only be exported when other applications have a need to use them.
If a Content Provider is exported, the application developer must define read and write permissions to prevent the Content Provider from being misused by malicious applications.