| V9 | Other Mobile Vulnerabilities | Category | Comments | Android | iOS | Cordova |
|---|---|---|---|---|---|---|
9.2 |
Verify that Function Level Access Control is being enforced |
Coding/Observation Task |
Limited to webviews. |
|||
9.3 |
Verify that there are no insecure direct object references. |
Coding/Observation Task |
Limited to webviews. |
8.6. OWASP Threat Model Project
This is a summary of notes taken from the OWASP Threat Model Project.
8.6.1. Mobile Threat Model Overview
To carry out threat modelling, you will need to have a clear understanding of the underlying system. Its important to define the following areas to understand possible threat to the mobile application.
-
Mobile App Architecture - This area describes how the application is designed from device specific features used by the application, such as:
-
Wireless transmission protocols
-
Data transmission mediums
-
Interaction with hardware components
-
Other applications
-
-
Mobile Data - This area cover what data does the application store and process, the business purpose of this data and what are the data workflows.
-
Threat Agent Identification - This area covers the threats to the mobile application and who are the threat agents.
-
Methods of Attack - This area covers the most common attacks utilized by threat agents.
-
Controls - This area covers the controls that can be used to prevent attacks.
8.6.2. Mobile Architecture
The mobile application architecture should, at the very least, describe device specific features used by the application such as:
-
Wireless transmission protocols
-
Data transmission medium
-
Interaction with hardware components and other applications.
Once you know what features/resources are used within the mobile app architecture, you can then begin to look at the attack surface.
Although mobile applications vary in function, they can be described using a generalized model as follows:
-
Wireless interfaces
-
Transmission Type
-
Hardware Interaction
-
Interaction with on device applications/services
-
Interaction with off device applications/services
-
Encryption Protocols
8.6.3. Mobile Data
Its important to know what purpose does the app serve from a business perspective and what data the app stores, transmits and receives. It’s also important to review data flow diagrams to determine exactly how data in the mobile app is handled.
You should aim to answer the following questions:
-
What is the business functions of the app?
-
Does personal data intermingle with corporate data?
-
Is there specific business logic built into the app to process data?
-
What does the data give you (or an attacker) access to?
-
Do stored keys allow you to break crypto functions (data integrity)?
-
Third party data, is it being stored/transmitted?
-
Are there regulatory requirements to meet specific to user privacy?
-
How does other data on the device affect the app (sandboxing restrictions enforced?)
-
What is the impact of Jailbroken/Rooted vs Non Jailbroken/Rooted device and how this affects app data?
8.6.4. Threat Agent Identification
This area covers what the threats to the mobile application are and who are the threat agents.
Identifying Threat Agents
The process of identifying a threat agent is very simple and have been mentioned in the below steps:
-
S1: Take the list of all sensitive data
-
S2: Make a list of all the ways to access this data
-
S3: The medium used to access the same listed in S2 above is the Threat Agent to be identified
Listing of Threat Agents - By Category
8.7. OWASP M-Tools
This is a summary of the tools that are described in OWASP Mobile Security M Tools page.
8.7.1. iMAS
-
What is it?
-
iOS secure application framework research to reduce iOS application vulnerabilities and information loss
-
-
Source code
-
Modules
-
-
Cipherlib, crypto manager, keychain crypto
-
-
-
Custom iOS user authentication mechanism (password with security questions for self reset)
-
-
-
Allows an application to verify if an iOS passcode has been set and what complexity. Based on this, an application can programmatically decide to execute fully or in a degraded state given this system evidence
-
-
-
Provides a Core Data encrypted SQLite store using SQLCipher.
-
-
-
Application level, attached debug detect and jailbreak checking
-
-
-
Library for securely clearing and validating iOS application memory
-
Eliminate clear-text sensitive data from memory after app use
-
-
8.7.2. GoatDroid
-
What is it?
-
A fully functional and self-contained training environment for educating developers and testers on Android security
-
-
Source Code
8.7.3. iGoat
-
What is it?
-
A safe environment where iOS developers can learn about the major security pitfalls they face as well as how to avoid them.
-
-
Source Code
8.7.4.
-
A project gives mobile testers and developers an iOS application to practice attacking/defending skill sets
-
-
Source code
8.7.5. MobiSec
-
What is it?
-
The MobiSec Live Environment Mobile Testing Framework project is a live environment for testing mobile environments, including devices, applications, and supporting infrastructure.
-
8.7.6. Androick
-
What is it?
-
Androick is a tool that allows any user to analyze an Android application
-
-
Source Code
8.7.7. NowSecure App Testing Community Edition
-
What is it?
-
It is the freely downloadable version of the powerful App Testing suite. Users are offered a number of features such as network capture, automation, import / export, and reporting to test and secure mobile apps
-
-
Tools
-
-
Santoku is dedicated to mobile forensics, analysis, and security, and packaged in an easy to use, Open Source platform
-
-
-
An app to scan vulnerabilities on Android
-
-
-
Inject JavaScript to explore native apps on Windows, macOS, Linux, iOS, Android, and QNX.
-
-
-
Portable reversing framework
-
-
8.8. iOS Security Whitepaper
This is a summary of the iOS security whitepaper.
8.8.1. System Security
Secure boot chain
Each step of the startup process contains components that are cryptographically signed by Apple to ensure integrity and that proceed only after verifying the chain of trust.
System Software Authorization
-
To prevent devices from being downgraded to older versions that lack the latest security updates, iOS uses a process called System Software Authorization.
-
During an iOS upgrade, iTunes (or the device itself, in the case of OTA software updates) connects to the Apple installation authorization server and sends it a list of cryptographic measurements for each part of the installation bundle to be installed (for example, iBoot, the kernel, and OS image), a random anti-replay value (nonce), and the device’s unique ID (ECID).
-
The authorization server checks the presented list of measurements against versions for which installation is permitted and, if it finds a match, adds the ECID to the measurement and signs the result. The server passes a complete set of signed data to the device as part of the upgrade process. Adding the ECID “personalizes” the authorization for the requesting device. By authorizing and signing only for known measurements, the server ensures that the update takes place exactly as provided by Apple
Secure Enclave
-
The Secure Enclave is a coprocessor fabricated in the Apple S2, Apple A7, and later A-series processors
-
Provides all cryptographic operations for Data Protection key management and maintains the integrity of Data Protection even if the kernel has been compromised
-
Additionally, data that is saved to the file system by the Secure Enclave is encrypted with a key entangled with the UID and an anti-replay counter
-
The Secure Enclave is responsible for processing fingerprint data from the Touch ID sensor, determining if there is a match against registered fingerprints, and then enabling access or purchases on behalf of the user
TouchId
-
The fingerprint sensor is active only when the capacitive steel ring that surrounds the Home button detects the touch of a finger, which triggers the advanced imaging array to scan the finger and send the scan to the Secure Enclave.
-
The resulting map of nodes is stored without any identity information in an encrypted format that can only be read by the Secure Enclave, and is never sent to Apple or backed up to iCloud or iTunes
8.8.2. File Data Protection
Overview
-
Every time a file on the data partition is created, Data Protection creates a new 256-bit key (the “per-file” key) and gives it to the hardware AES engine, which uses the key to encrypt the file as it is written to flash memory using AES CBC mode.
-
The content of a file is encrypted with a per-file key, which is wrapped with a class key and stored in a file’s metadata, which is in turn encrypted with the file system key.
Passcode
-
By setting up a device passcode, the user automatically enables Data Protection.
-
The passcode is entangled with the device’s UID, so brute-force attempts must be performed on the device under attack.
-
A large iteration count is used to make each attempt slower.
Data Protection classes
-
Complete Protection - NSFileProtectionComplete
-
Shortly after the user locks a device (10 seconds, if the Require Password setting is Immediately), the decrypted class key is discarded, rendering all data in this class inaccessible until the user enters the passcode again or unlocks the device using Touch ID
-
-
Protected Unless Open - NSFileProtectionCompleteUnlessOpen
-
To protect files that need to be written while the device is locked
-
-
Protected Until First User Authentication - NSFileProtectionCompleteUntilFirstUserAuthentication
-
This class behaves in the same way as Complete Protection, except that the decrypted class key isn’t removed from memory when the device is locked
-
This is the default class for all third-party app data not otherwise assigned to a Data Protection class
-
-
No Protection - NSFileProtectionNone
Keychain Data Protection
-
The Keychain is implemented as a SQLite database stored on the file system.
-
Keychain items can only be shared between apps from the same developer.
-
Keychain data is protected using a class structure similar to the one used in file Data Protection.
-
When unlocked - kSecAttrAccessibleWhenUnlocked
-
While locked - N/A
-
After first unlock - kSecAttrAccessibleAfterFirstUnlock
-
Always - kSecAttrAccessibleAlways
-
Passcode Enabled - kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly
-
-
Keychain classes have a “This device only” counterpart, which is always protected with the UID when being copied from the device during a backup, rendering it useless if restored to a different device
-
Keychains can use access control lists (ACLs) to set policies for accessibility and authentication requirements
Access to Safari saved passwords
-
iOS apps can interact with Keychain items saved by Safari for password autofill using the following two APIs:
-
SecRequestSharedWebCredential
-
SecAddSharedWebCredential
-
-
Access will be granted only if both the app developer and website administrator have given their approval, and the user has given consent.
Keybags
-
The keys for both file and Keychain Data Protection classes are collected and managed in keybags.
-
iOS uses the following keybags:
-
user
-
Is where the wrapped class keys used in normal operation of the device are stored.
-
-
device
-
Is used to store the wrapped class keys used for operations involving device-specific data
-
On iOS devices configured for use by a single user (the default configuration), the device keybag and the user keybag are one and the same, and are protected by the user’s passcode
-
-
backup
-
Is created when an encrypted backup is made by iTunes and stored on the computer to which the device is backed up
-
If a user chooses not to encrypt an iTunes backup, the backup files aren’t encrypted regardless of their Data Protection class, but the Keychain remains protected with a UID-derived key.
-
-
escrow
-
Is used for iTunes syncing and MDM, allows iTunes to back up and sync without requiring the user to enter a passcode, and it allows an MDM server to remotely clear a user’s passcode.
-
-
iCloud Backup
-
Is similar to the backup keybag
-
-
8.8.3. App Security
App code signing
-
To ensure that all apps come from a known and approved source and haven’t been tampered with, iOS requires that all executable code be signed using an Apple-issued certificate
-
To protect the system and other apps from loading third-party code inside of their address space, the system will perform a code signature validation of all the dynamic libraries that a process links against at launch time.
-
At runtime, code signature checks of all executable memory pages are made as they are loaded to ensure that an app has not been modified since it was installed or last updated
Runtime process security
-
All third-party apps are “sandboxed,” so they are restricted from accessing files stored by other apps or from making changes to the device.
-
System files and resources are also shielded from the user’s apps. The majority of iOS runs as the non-privileged user “mobile,” as do all third-party apps.
-
Access by third-party apps to user information and features such as iCloud and extensibility is controlled using declared entitlements.
-
Address space layout randomization (ASLR) protects against the exploitation of memory corruption bugs.
-
Further protection is provided by iOS using ARM’s Execute Never (XN) feature, which marks memory pages as non-executable.
Extensions
-
Extensions are special-purpose signed executable binaries, packaged within an app.
-
The system automatically launches extension processes as needed and manages their lifetime.
-
Extensions run in their own address space. Communication between the extension and the app from which it was activated uses interprocess communications mediated by the system framework. They don’t have access to each other’s files or memory spaces.
-
Extensions are designed to be isolated from each other, from their containing apps, and from the apps that use them.
-
Custom keyboards are a special type of extension
-
A keyboard extension will be used for any text field except the passcode input and any secure text view
-
To restrict the transfer of user data, custom keyboards run by default in a very restrictive sandbox that blocks access to the network, to services that perform network operations on behalf of a process, and to APIs that would allow the extension to exfiltrate typing data.
-
App Groups
-
Apps and extensions owned by a given developer account can share content when configured to be part of an App Group.
-
Once configured to be part of an App Group, apps have access to the following:
-
A shared on-disk container for storage, which will stay on the device as long as at least one app from the group is installed
-
Shared preferences
-
Shared Keychain items
-
Data Protection in apps
-
Data Protection is available for file and database APIs, including NSFileManager, CoreData, NSData, and SQLite
-
User-installed apps that don’t opt-in to a specific Data Protection class receive Protected Until First User Authentication by default.
Accessories
-
When an MFi accessory communicates with an iOS device using a Lightning connector or via Bluetooth, the device asks the accessory to prove it has been authorized by Apple by responding with an Apple-provided certificate, which is verified by the device.
-
The device then sends a challenge, which the accessory must answer with a signed response.
-
This process is entirely handled by a custom integrated circuit that Apple provides to approved accessory manufacturers and is transparent to the accessory itself
Homekit
-
This stored data is encrypted using keys derived from the user’s HomeKit identity keys, plus a random nonce.
-
Additionally, HomeKit data is stored using Data Protection class Protected Until First User Authentication.
-
Is only backed up in encrypted backups, so, for example, unencrypted iTunes backups don’t contain HomeKit data
-
Data synchronization
-
The HomeKit data is encrypted during the synchronization using keys derived from the user’s HomeKit identity and random nonce.
-
HealthKit
-
User’s health data is stored in Data Protection class Complete Protection, which means it is accessible only after a user enters their passcode or uses Touch ID to unlock the device
-
Management data is stored in Data Protection class Protected Until First User Authentication
-
Temporary journal files store health records are stored in Data Protection class Protected Unless Open.
-
Isn’t synced between devices, is included in device backups to iCloud and encrypted iTunes backups
8.8.4. Network Security
TLS
-
iOS supports Transport Layer Security (TLS v1.0, TLS v1.1, and TLS v1.2, which supports both AES 128 and SHA-2) and DTLS
-
CFNetwork disallows SSLv3, and apps that use WebKit (such as Safari) are prohibited from making an SSLv3 connection
-
The RC4 symmetric cipher suite is deprecated in iOS 10 and macOS Sierra
-
App Transport Security
-
provides default connection requirements so that apps adhere to best practices for secure connections when using NSURLConnection, CFURL, or NSURLSession APIs
-
VPN
-
iOS supports VPN On Demand for networks that use certificate-based authentication.
-
iOS also supports Per App VPN support, facilitating VPN connections on a much more granular basis.
-
iOS supports Always-on VPN, which can be configured for devices managed via MDM and supervised using Apple Configurator or the Device Enrollment Program.
Single Sign-on
-
iOS supports authentication to enterprise networks through Single Sign-on (SSO).
-
SSO works with Kerberos-based networks to authenticate users to services they are authorized to access.
-
To configure SSO, iOS supports a configuration profile payload that allows MDM servers to push down the necessary settings.

This is a summary of the Android Security Guide.

Kernel Security

Application Sandbox

Android uses the UNIX user-based protection to identify and isolate running applications. The Android system assigns a unique UID (User ID) to each Android application and runs the application as a certain user in a separate process. By default, applications cannot interact with each other. This is due to the user privileges being different for each application. Memory corruption errors in one application will not lead to corruption in other applications, due to this isolation.

However, if the android:sharedUserId attribute is set (in the App Manifest) to the same value for two or more applications, they will all share the same User ID — provided that their certificate sets are identical. Applications with the same user ID can access each other’s data and also run in the same process.

Filesystem Permissions

The filesystem permissions ensure that one user cannot alter or read another user’s files. In the context of Android, this means that one application, cannot access or alter the data for another application, unless they explicitly allow it.

Device Rooting

By default, only the kernel and small number of core applications run using root permissions. Root permissions will allow you full access to all applications on the device, as well as their applications data.

Encrypting data with a key stored on the device will not protect the application from a root user. Applications could use a key stored off-device, but this approach will only provide temporary protection while the key is not present on the device. At some point the key must be provided to the application and it then becomes accessible to root users.

Filesystem Encryption

A number of different filesytem encryption approaches have been used by different versions of Android.

Android 3.0

Full filesystem encryption in the kernel.

Android 5.0

Full-disk encryption which uses a single key—protected with the user’s device password—to protect the whole of a device’s userdata partition.

Upon boot, users must provide their credentials before any part of the disk is accessible.

Android 7.0

File-based encryption allows different files to be encrypted with different keys that can be unlocked independently.

The Direct Boot feature allows encrypted devices to boot straight to the lock screen.

This makes profiles more secure because it allows more than one user to be protected at a time as the encryption is no longer based solely on a boot time password.

Application Security

Certificate Authorities

Android includes a set of installed system Certificate Authorities, which are trusted system-wide. Devices running Android 7.0 and above will have an Android stock set of system CAs as device manufacturers supplied CA’s are no longer permitted.

Application Signing

APK Signing will allow a developer to identify the author of the application. The signed application certificate defines which user id is associated with which application. The application signing ensures that applications cannot access each other except through a well-defined IPC (Inter-process communication).

Authentication

Two key pieces make up Authentication and Key Storage from Android 6.0.

Android Keystore - Cryptographic key storage which also provides standard crypto actions.

Authentication Components - Assert the user’s presence and/or provide user authentication.

There are two authentication components:

Gatekeeper - Pin, Pattern and Password Authentication

Fingerprint - Fingerprint Authentication

The two authentication components work with the Keystore and (other components) to support the use of hardware-backed authentication tokens or AuthTokens.

Enrollment

On first boot of the device, the user must initially enroll a PIN/pattern/password with Gatekeeper. This is known as enrollment. This is necessary to to create the User’s SID (User Secure Identifier) which is a 64-bit randomly generated ID.

This SID is cryptographically bound to the user’s password, so when a successful authentication takes place, the AuthTokens will contain the User SID for that password.

Authentication Process

Once a user has set up a credential (eg. a Pattern lock) and they have received their User SID (Secure User Id), they are now ready to authenticate.

As part of Android authentication, an operating system (known as Trusty OS) runs on a processor intended to provide a TEE (Trusted Execution Environment).

Figure 1: Android Authentication Process

Authentication begins when a user enters a Gatekeeper credential (eg. a Pin, Pattern, Password) or a Fingerprint.

The next step involves either the Gatekeeper daemon (gatekeeperd) or the Fingerprint daemon (fingerprintd) depending on what authentication credential is used.

The gatekeeperd daemon will send a hash of the password/pin/pattern it received in step 1, to its counterpart gatekeeper in the TEE (TEE OS).

Alternatively, the fingerprintd daemon sends the data to its fingerprint counterpart in the TEE.

If authentication in the TEE (TEE OS) is successful, gatekeeper or fingerprint in the TEE sends an AuthToken containing the corresponding User SID, signed with the AuthToken HMAC key, to its counterpart in the Android OS.

Remember that the SID is cryptographically bound to the user’s password.

The HMAC is used for message integrity.

The gatekeeperd or fingerprintd daemon receives a signed AuthToken from the TEE and passes the AuthToken to the keystore service.

Lastly, the keystore service passes the AuthTokens received from gatekeeperd and fingerprintd to the keymaster. The AuthToken is verified with the AuthToken HMAC key which was previously shared with the gatekeeper and fingerprint "trustlets" in step 2. The keymaster trusts the timestamp in the token as the last authentication time and bases a key release decision (to allow an app to use the key) on the timestamp.

Keystore

The Android Keystore system allows storage of cryptographic keys inside a container to make it more difficult to extract them from a device. Once keys are in the keystore, they can be used for cryptographic operations with the key material remaining non-exportable.

Trusted Execution Environment

A TEE processor is generally a separate microprocessor or a virtualized instance of the main processor. The TEE processor is isolated from the rest of the system using memory and I/O protection mechanisms supported by the hardware.

TEE is necessary as the main processor on mobile devices is considered "untrusted". It is not allowed access to certain areas of RAM or where other device-specific cryptographic keys are stored. Applications running on the main processor will therefore delegate any operations that require use of secret/sensitive data to the TEE processor.

This is a summary of the Android Developer Security Guide.

Overview

The following core security features help you build secure apps:

The Android Application Sandbox, which isolates your app data and code execution from other apps.

An application framework with robust implementations of common security functionality such as cryptography, permissions, and secure IPC.

Technologies like ASLR, NX, ProPolice, safe_iop, OpenBSD dlmalloc, OpenBSD calloc, and Linux mmap_min_addr to mitigate risks associated with common memory management errors.

An encrypted file system that can be enabled to protect data on lost or stolen devices.

User-granted permissions to restrict access to system features and user data.

Application-defined permissions to control application data on a per-app basis.

Data Storage

The most common security concern for an application on Android is whether the data that you save on the device is accessible to other apps.

There are three fundamental ways to save data on the device:

Internal Storage

By default, files that you create on internal storage are accessible only to your app. Android implements this protection, and it’s sufficient for most applications.

Avoid the MODE_WORLD_WRITEABLE or MODE_WORLD_READABLE modes for IPC files because they do not provide the ability to limit data access to particular applications, nor do they provide any control of data format. If you want to share your data with other app processes, instead consider using a content provider, which offers read and write permissions to other apps and can make dynamic permission grants on a case-by-case basis.

External Storage

Files created on external storage, such as SD cards, are globally readable and writable. Because external storage can be removed by the user and also modified by any application, don’t store sensitive information using external storage.

You should Perform input validation when handling data from external storage as you would with data from any untrusted source. You should not store executables or class files on external storage prior to dynamic loading. If your app does retrieve executable files from external storage, the files should be signed and cryptographically verified prior to dynamic loading.

Content Providers

Content providers offer a structured storage mechanism that can be limited to your own application or exported to allow access by other applications. If you do not intend to provide other applications with access to your ContentProvider, mark them as android:exported=false in the application manifest. Otherwise, set the android:exported attribute to true to allow other apps to access the stored data.

If you are using a content provider for sharing data between only your own apps, it is preferable to use the android:protectionLevel attribute set to signature protection. Signature permissions do not require user confirmation, so they provide a better user experience and more controlled access to the content provider data when the apps accessing the data are signed with the same key.

Permissions

Android permissions are ranked in four different categories based on the protection level they offer:

Normal: the lower level of protection. It gives the apps access to isolated application-level feature, with minimal risk to other apps, the user or the system. It is granted during the installation of the App. It is also the default value for the cases when no protection level is specified. Example: android.permission.INTERNET

Dangerous: This permission usually gives the app control over the user data or over the device that impacts the user. This type of permission may not be granted at installation time, leaving it to the user to decide whether the app should have the permission or not. Example: android.permission.RECORD_AUDIO

Signature: This permission is granted only if the requesting app was signed with the same certificate as the app that declared the permission. If the signature matches, the permission is automatically granted. Example: android.permission.ACCESS_MOCK_LOCATION

SystemOrSignature: Permission only granted to the apps embedded in the system image or that were signed using the same certificated as the app that declared the permission. Example: android.permission.ACCESS_DOWNLOAD_MANAGER

IP Networking

You should use HTTPS over HTTP anywhere that HTTPS is supported on the server, because mobile devices frequently connect on networks that are not secured, such as public Wi-Fi hotspots. Authenticated, encrypted socket-level communication can be easily implemented using the SSLSocket class.

Some applications use localhost network ports for handling sensitive IPC. You should not use this approach because these interfaces are accessible by other applications on the device. Instead, use an Android IPC mechanism where authentication is possible, such as with a Service. Binding to INADDR_ANY is worse than using loopback because then your application may receive requests from anywhere.

Make sure that you don’t trust data downloaded from HTTP or other insecure protocols. This includes validation of input in WebView and any responses to intents issued against HTTP.

Telephony Networking

Beware that SMS is neither encrypted nor strongly authenticated on either the network or the device. In particular, any SMS receiver should expect that a malicious user may have sent the SMS to your application. Don’t rely on unauthenticated SMS data to perform sensitive commands.

Also, you should be aware that SMS may be subject to spoofing and/or interception on the network. On the Android-powered device itself, SMS messages are transmitted as broadcast intents, so they may be read or captured by other applications that have the READ_SMS permission.

Input Validation

Insufficient input validation is one of the most common security problems affecting applications, regardless of what platform they run on. Android has platform-level countermeasures that reduce the exposure of applications to input validation issues, and you should use those features where possible.

If you are using native code, any data read from files, received over the network, or received from an IPC has the potential to introduce a security issue. The most common problems are buffer overflows, use after free, and off-by-one errors. Android provides a number of technologies like ASLR and DEP that reduce the exploitability of these errors, but they don’t solve the underlying problem. You can prevent these vulnerabilities by carefully handling pointers and managing buffers.

If you are using data within queries that are submitted to an SQL database or a content provider, SQL injection may be an issue. The best defense is to use parameterized queries, as is discussed in the above section about content providers. Limiting permissions to read-only or write-only can also reduce the potential for harm related to SQL injection.

You should make sure to use well-structured data formats and verify that the data conforms to the expected format. While blacklisting of characters or character-replacement can be an effective strategy, these techniques are error prone in practice and should be avoided when possible.

Handling User Data

In general, the best approach for user data security is to minimize the use of APIs that access sensitive or personal user data. If you have access to user data and can avoid storing or transmitting it, don’t store or transmit the data.

Consider if there is a way that your application logic can be implemented using a hash or non-reversible form of the data.

For example, your application might use the hash of an email address as a primary key to avoid transmitting or storing the email address. This reduces the chances of inadvertently exposing data, and it also reduces the chance of attackers attempting to exploit your application.

If your app requires access to sensitive data, evaluate whether you need to transmit it to a server or you can run the operation on the client. Consider running any code using sensitive data on the client to avoid transmitting user data.

Also, make sure that you do not inadvertently expose user data to other applications on the device through overly permissive IPC, world-writable files, or network sockets. Overly permissive IPC is a special case of leaking permission-protected data.

If a GUID is required, create a large, unique number and store it. Don’t use phone identifiers such as the phone number or IMEI, which may be associated with personal information.

Be careful when writing to on-device logs. In Android, logs are a shared resource and are available to an application with the READ_LOGS permission.

Using Webviews

Because WebView consumes web content that can include HTML and JavaScript, improper use can introduce common web security issues such as XSS. Android includes a number of mechanisms to reduce the scope of these potential issues by limiting the capability of WebView to the minimum functionality required by your application

If your application doesn’t directly use JavaScript within a WebView, do not call setJavaScriptEnabled(). By default, WebView does not execute JavaScript, so XSS is not possible.

If your application accesses sensitive data with a WebView, you may want to use the clearCache() method to delete any files stored locally. You can also use server-side headers such as no-cache to indicate that an application should not cache particular content.

Use addJavaScriptInterface() with particular care because it allows JavaScript to invoke operations that are normally reserved for Android applications. If you use it, expose addJavaScriptInterface() only to web pages from which all input is trustworthy. In general, the Android documentation recommends exposing addJavaScriptInterface() only to JavaScript that is contained within your application APK.

Handling Credentials

To make phishing attacks more conspicuous and less likely to be successful, minimize the frequency of asking for user credentials. Instead use an authorization token and refresh it.

Where possible, don’t store user names and passwords on the device. Instead, perform initial authentication using the user name and password supplied by the user, and then use a short-lived, service-specific authorization token.

Services that are accessible to multiple applications should be accessed using AccountManager. If possible, use the AccountManager class to invoke a cloud-based service and don’t store passwords on the device.

After using AccountManager to retrieve an Account, use CREATOR before passing in any credentials so that you do not inadvertently pass credentials to the wrong application.

If credentials are used only by applications that you create, you can verify the application that accesses the AccountManager using checkSignature(). Alternatively, if only one application uses the credential, you might use a KeyStore for storage.

Cryptography

Use a secure random number generator, SecureRandom, to initialize any cryptographic keys generated by KeyGenerator. Use of a key that is not generated with a secure random number generator significantly weakens the strength of the algorithm and may allow offline attacks.

If you need to store a key for repeated use, use a mechanism, such as KeyStore, that provides a mechanism for long term storage and retrieval of cryptographic keys.

IPC

Some apps attempt to implement IPC using traditional Linux techniques such as network sockets and shared files. However, you should instead use Android system functionality for IPC such as Intent, Binder or Messenger with a Service, and BroadcastReceiver. The Android IPC mechanisms allow you to verify the identity of the application connecting to your IPC and set a security policy for each IPC mechanism.

Many of the security elements are shared across IPC mechanisms. If your IPC mechanism is not intended for use by other applications, set the android:exported attribute to false in the component’s manifest element.

If your IPC is accessible to other applications, you can apply a security policy by using the <permission> element. If IPC is between your own separate apps that are signed with the same key, it is preferable to use signature level permission in the android:protectionLevel.

Intents

For activities and broadcast receivers, intents are the preferred mechanism for asynchronous IPC in Android. Depending on your application requirements, you might use sendBroadcast(), sendOrderedBroadcast(), or an explicit intent to a specific application component. For security purposes, explicit intents are preferred.

If you use an intent to bind to a Service, ensure that your app is secure by using an explicit intent. Using an implicit intent to start a service is a security hazard because you can’t be certain what service will respond to the intent, and the user can’t see which service starts.

Senders of an intent can verify that the recipient has permission by specifying a non-null permission with the method call. Only applications with that permission receive the intent. If data within a broadcast intent may be sensitive, you should consider applying a permission to make sure that malicious applications can’t register to receive those messages without appropriate permissions. In those circumstances, you may also consider invoking the receiver directly, rather than raising a broadcast.

Services

A Service is often used to supply functionality for other applications to use. Each service class must have a corresponding <service> declaration in its manifest file.

By default, services are not exported and cannot be invoked by any other application. However, if you add any intent filters to the service declaration, it is exported by default. It’s best if you explicitly declare the android:exported attribute to be sure it behaves as you’d like. Services can also be protected using the android:permission attribute. By doing so, other applications need to declare a corresponding <uses-permission> element in their own manifest to be able to start, stop, or bind to the service.

If your app targets Android 5.0 (API level 21) or later, you should use the JobScheduler to execute background services.

A service can protect individual IPC calls into it with permissions, by calling checkCallingPermission() before executing the implementation of that call. You should use the declarative permissions in the manifest, since those are less prone to oversight.

Binder and Messenger Interfaces

Using Binder or Messenger is the preferred mechanism for RPC-style IPC in Android. They provide a well-defined interface that enables mutual authentication of the endpoints, if required.

If you are providing an interface that does require access controls, use checkCallingPermission() to verify whether the caller has a required permission. This is especially important before accessing a service on behalf of the caller, as the identify of your application is passed to other interfaces.

Broadcast Receivers

A BroadcastReceiver handles asynchronous requests initiated by an Intent.

By default, receivers are exported and can be invoked by any other application. If your BroadcastReceiver is intended for use by other applications, you may want to apply security permissions to receivers using the <receiver> element within the application manifest. This prevents applications without appropriate permissions from sending an intent to the BroadcastReceiver.

Dynamically Loading Code

Loading code from outside of your application APK significantly increases the likelihood of application compromise due to code injection or code tampering.

If your application does dynamically load code, the most important thing to keep in mind about dynamically-loaded code is that it runs with the same security permissions as the application APK.

The major security risk associated with dynamically loading code is that the code needs to come from a verifiable source.

Virtual Machine Security

Dalvik is Android’s runtime virtual machine (VM). Your application runs in a secure sandbox environment, so other processes on the system can’t access your code or private data.

Security with HTTPS and SSL

This is a summary of the Android Developer Security with HTTPS and SSL Guide.

The Secure Sockets Layer (SSL)—now technically known as Transport Layer Security (TLS)—is a common building block for encrypted communications between clients and servers. It’s possible that an application might use SSL incorrectly such that malicious entities may be able to intercept an app’s data over the network.

As of Android 4.2 (Jelly Bean), Android currently contains over 100 CAs that are updated in each release. Similar to a server, a CA has a certificate and a private key. When issuing a certificate for a server, the CA signs the server certificate using its private key. The client can then verify that the server has a certificate issued by a CA known to the platform.

HTTPS Example

Assuming you have a web server with a certificate issued by a well known CA, you can make a secure request with code as simple this:

URL url = new URL("https://wikipedia.org"); URLConnection urlConnection = url.openConnection(); InputStream in = urlConnection.getInputStream(); copyInputStreamToOutputStream(in, System.out);

Suppose instead of receiving the content from getInputStream(), it throws an exception:

javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.

This can happen for several reasons, including:

Unknown CA - The CA that issued the server certificate was unknown.

In this case, the SSLHandshakeException occurs because you have a CA that isn’t trusted by the system. It could be because you have a certificate from a new CA that isn’t yet trusted by Android or your app is running on an older version without the CA. More often a CA is unknown because it isn’t a public CA, but a private one issued by an organization such as a government, corporation, or education institution for their own use. With a custom TrustManager that knows about your CAs, the system is able to validate that your server certificate come from a trusted issuer.

Self-Signed Server Certificate - The server certificate wasn’t signed by a CA, but was self signed.

The second case of SSLHandshakeException is due to a self-signed certificate, which means the server is behaving as its own CA. As before, you can create your own TrustManager, this time trusting the server certificate directly.

Missing Intermediate CA - The server configuration is missing an intermediate CA.

The third case of SSLHandshakeException occurs due to a missing intermediate CA. Most public CAs don’t sign server certificates directly. Instead, they use their main CA certificate, referred to as the root CA, to sign intermediate CAs. They do this so the root CA can be stored offline to reduce risk of compromise.

However, operating systems like Android typically trust only root CAs directly, which leaves a short gap of trust between the server certificate—signed by the intermediate CA—and the certificate verifier, which knows the root CA.

To solve this, the server doesn’t send the client only it’s certificate during the SSL handshake, but a chain of certificates from the server CA through any intermediates necessary to reach a trusted root CA.

There are two approaches to solve this issue:

Configure the server to include the intermediate CA in the server chain. Most CAs provide documentation on how to do this for all common web servers. This is the only approach if you need the site to work with default Android browsers at least through Android 4.2.

Or, treat the intermediate CA like any other unknown CA, and create a TrustManager to trust it directly, as done in the previous two sections.

Hostname verification

There are two key parts to verifying an SSL connection:

The first is to verify the certificate is from a trusted source, which was the focus of the previous section.

The second part is making sure the server you are talking to presents the right certificate. When it doesn’t, you’ll typically see an error like this:

java.io.IOException: Hostname 'example.com' was not verified at libcore.net.http.HttpConnection.verifySecureSocketHostname(HttpConnection.java:223) at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.connect(HttpsURLConnectionImpl.java:446)

One reason this can happen is due to a server configuration error. The server is configured with a certificate that does not have a subject or subject alternative name fields that match the server you are trying to reach. It is possible to have one certificate be used with many different servers.

Warnings About Using SSLSocket Directly

SSLSocket does not perform hostname verification. It is up the your app to do its own hostname verification, preferably by calling getDefaultHostnameVerifier() with the expected hostname. Further beware that HostnameVerifier.verify() doesn’t throw an exception on error but instead returns a boolean result that you must explicitly check.

Blacklisting

SSL relies heavily on CAs to issue certificates to only the properly verified owners of servers and domains. In rare cases, CAs are either tricked or breached, resulting in the certificates for a hostname to be issued to someone other than the owner of the server or domain.

In order to mitigate this risk, Android has the ability to blacklist certain certificates or even whole CAs. While this list was historically built into the operating system, starting in Android 4.2 this list can be remotely updated to deal with future compromises.

Pinning

An app can further protect itself from fraudulently issued certificates by a technique known as pinning. This prevents the compromise of one of the other 100+ CAs in the system from resulting in a breach of the apps secure channel.

Client Certificates

SSL also supports the notion of client certificates that allow the server to validate the identity of a client.

Nogotofail: A Network Traffic Security Testing Tool

Nogotofail is a tool gives you an easy way to confirm that your apps are safe against known TLS/SSL vulnerabilities and misconfigurations. It’s an automated, powerful, and scalable tool for testing network security issues on any device whose network traffic could be made to go through it.

Nogotofail is useful for three main use cases:

Finding bugs and vulnerabilities.

Verifying fixes and watching for regressions.

Understanding what applications and devices are generating what traffic.

Network Security Configuration

This is a summary of the Android Developer Network Security Configuration Guide.

Configuration

The Network Security Configuration feature lets apps customize their network security settings in a safe, declarative configuration file without modifying app code. These settings can be configured for specific domains and for a specific app. The key capabilities of this feature are as follows:

Custom trust anchors: Customize which Certificate Authorities (CA) are trusted for an app’s secure connections. For example, trusting particular self-signed certificates or restricting the set of public CAs that the app trusts.

Debug-only overrides: Safely debug secure connections in an app without added risk to the installed base.

Cleartext traffic opt-out: Protect apps from accidental usage of cleartext traffic.

Certificate pinning: Restrict an app’s secure connection to particular certificates.

The Network Security Configuration feature uses an XML file where you specify the settings for your app. You must include an entry in the manifest of your app to point to this file.

Example reference of the network security settings from the applications manifest xml:

<?xml version="1.0" encoding="utf-8"?> <manifest … > <application android:networkSecurityConfig="@xml/network_security_config" … > … </application> </manifest>

Customizing Trusted CAs

An app may want to trust a custom set of CAs instead of the platform default. The most common reasons of this are:

Connecting to a host with a custom certificate authority, such as a CA that is self-signed or is issued internally within a company.

Limiting the set of CAs to only the CAs you trust instead of every pre-installed CA.

Trusting additional CAs not included in the system.

An app can customize its own connections using base-config (for app-wide customization) or domain-config (for per-domain customization).

For Configuring CA’s, configuration examples are available in the Android Documentation.

Configuring a Custom CA

Limiting the Set of Trusted CAs

Trusting Additional CAs

Configuring CAs for Debugging

Opting Out of Cleartext Traffic

Applications intending to connect to destinations using only secure connections can opt-out of supporting cleartext (using the unencrypted HTTP protocol instead of HTTPS) to those destinations. This option helps prevent accidental regressions in apps due to changes in URLs provided by external sources such as backend servers.

For example, an app may want to ensure that all connections to secure.example.com are always done over HTTPS to protect sensitive traffic from hostile networks.

res/xml/network_security_config.xml:

<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config cleartextTrafficPermitted="false"> <domain includeSubdomains="true">secure.example.com</domain> </domain-config> </network-security-config>

Pinning Certificates

Normally, an app trusts all pre-installed CAs. If any of these CAs were to issue a fraudulent certificate, the app would be at risk from a man-in-the-middle attack. Some apps choose to limit the set of certificates they accept by either limiting the set of CAs they trust or by certificate pinning.

Certificate pinning is done by providing a set of certificates by hash of the public key (SubjectPublicKeyInfo of the X.509 certificate). A certificate chain is then valid only if the certificate chain contains at least one of the pinned public keys.

Note that, when using certificate pinning, you should always include a backup key so that if you are forced to switch to new keys or change CAs (when pinning to a CA certificate or an intermediate of that CA), your app’s connectivity is unaffected. Otherwise, you must push out an update to the app to restore connectivity.

res/xml/network_security_config.xml:

<?xml version="1.0" encoding="utf-8"?> <network-security-config> <domain-config> <domain includeSubdomains="true">example.com</domain> <pin-set expiration="2018-01-01"> <pin digest="SHA-256">7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=</pin>  <pin digest="SHA-256">fwza0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1oE=</pin> </pin-set> </domain-config> </network-security-config>

Configuration Inheritance Behavior

Values not set in a specific configuration are inherited. This behavior allows more complex configurations while keeping the configuration file readable.

If a value is not set in a specific entry, then the value from the more general entry is used. For example, values not set in a domain-config are taken from the parent domain-config, if nested, or from the base-config if not. Values not set in the base-config use the platform default values.

For example, consider where all connections to subdomains of example.com must use a custom set of CAs. Additionally, cleartext traffic to these domains is permitted except when connecting to secure.example.com. By nesting the configuration for secure.example.com inside the configuration for example.com, the trust-anchors does not need to be duplicated.

Configuration File Format

The Network Security Configuration feature uses an XML file format. The overall structure of the file is shown in the following code sample:

<?xml version="1.0" encoding="utf-8"?> <network-security-config> <base-config> <trust-anchors> <certificates src="…"/> … </trust-anchors> </base-config>
<domain-config> <domain>android.com</domain> ... <trust-anchors> <certificates src="..."/> ... </trust-anchors> <pin-set> <pin digest="...">...</pin> ... </pin-set> </domain-config> ... <debug-overrides> <trust-anchors> <certificates src="..."/> ... </trust-anchors> </debug-overrides> </network-security-config>

The full network security configuration options can be seen here.

SafetyNet

SafetyNet provides a set of services and APIs that help protect your app against security threats, including device tampering, bad URLs, potentially harmful apps, and fake users.

SafetyNet Attestation API

The SafetyNet Attestation API provides services for determining whether a device running your app satisfies Android compatibility tests.

SafetyNet examines software and hardware information on the device where your app is installed to create a profile of that device. The service then attempts to find this same profile within a list of device models that have passed Android compatibility testing. The API also uses this software and hardware information to help you assess the basic integrity of the device, as well as the APK information of the calling app. This attestation helps you to determine whether or not the particular device has been tampered with or otherwise modified.

SafetyNet Safe Browsing API

The SafetyNet Safe Browsing API provides services for determining whether a URL has been marked as a known threat by Google. Your app can use a URL check to determine whether a URL poses a known threat.

SafetyNet reCAPTCHA API

The SafetyNet reCAPTCHA API service includes a reCAPTCHA API that you can use to protect your app from malicious traffic. reCAPTCHA is a free service that uses an advanced risk analysis engine to protect your app from spam and other abusive actions. If the service suspects that the user interacting with your app might be a bot instead of a human, it serves a CAPTCHA that a human must solve before your app can continue executing.

SafetyNet Verify Apps API

The SafetyNet Verify Apps API allows your app to interact programmatically with the Verify Apps feature on a device, protecting the device against potentially harmful apps. The SafetyNet Verify Apps API allows you to leverage this feature to protect your app’s data. By using this API, you can determine whether a user’s device is protected by the Verify Apps feature, encourage users not already using the feature to opt in to its protection, and identify any known potentially harmful apps that are installed on the device.

Key Attestation

This is a summary of the Android Developer Key Attestation Security Guide and the Android 7.0: "Security Benefits that Truly Matter" post.

Verifying Hardware Backed Keypairs

Key Attestation will allow developers to make sure the keys they may be using in their apps are valid and stored in the phone’s hardware-backed keystore and not in software. When the attestation tool is given a generated alias for a key (the actual key should never be shared) it then generates a certificate chain that can be used to verify the key. Developers can verify both the key as well as the verified boot state to make sure everything is valid.

Phones that ship with Android N and use Google services will have a certificate that’s issued by Google as the root (or primary) authority while other phones that have been upgraded will need a certificate issued by the company who made them.

Not all phones that can run Android N have a trusted hardware environment to store encryption keys, and in those cases, software-level key attestation is used instead. The verified boot state can still be checked to make sure the system software hasn’t been tampered with.

Retrieving and Verifying a Hardware-backed Key Pair

During key attestation, you specify the alias of a key pair. The attestation tool, in return, provides a certificate chain, which you can use to verify the properties of that key pair.

If the device supports hardware-level key attestation, the root certificate within this chain is signed using an attestation root key, which the device manufacturer injects into the device’s hardware-backed keystore at the factory.

On devices that ship with hardware-level key attestation, Android 7.0 (API level 24), and Google Play services, the root certificate is signed with the Google attestation root key. You should verify that this root certificate appears within Google’s list of root certificates.

Implementing Key Attestation

Use a KeyStore object’s getCertificateChain() method to get a reference to the chain of X.509 certificates associated with the hardware-backed keystore.

Check each certificate’s validity using a X509Certificate object’s checkValidity() method. Caution: Although you can complete this process within your app directly, it’s safer to check the certificates' revocation lists on a separate server that you trust.

On a separate server that you trust, obtain a reference to the ASN.1 parser library that is most appropriate for your toolset. Use this parser to extract the attestation certificate extension data, which appears within the first element of the certificate chain.

The Key Attestation sample uses the ASN.1 parser from Bouncy Castle to extract an attestation certificate’s extension data. You can use this sample as a reference for creating your own parser.

Compare the extension data that you’ve retrieved from your ASN.1 parser with the set of values that you expect the hardware-backed key to contain. Caution: Although you can complete this process within your app directly, it’s safer to check the certificate’s extension data on a separate server that you trust.

Device Management Policies

It allows developers to create an application that manages access to its content by enforcing device management policies. Specifically, the application can be configured such that it ensures a screen-lock password of sufficient strength is set up before displaying restricted content to the user.

Define and Declare policy

Declare the policy in the res/xml/device_admin.xml file, example:

<device-admin xmlns:android="http://schemas.android.com/apk/res/android"> <uses-policies> <limit-password /> </uses-policies> </device-admin>

Then reference it in the Android manifest file:

<receiver android:name=".Policy$PolicyAdmin" android:permission="android.permission.BIND_DEVICE_ADMIN"> <meta-data android:name="android.app.device_admin" android:resource="@xml/device_admin" /> <intent-filter> <action android:name="android.app.action.DEVICE_ADMIN_ENABLED" /> </intent-filter> </receiver>

Create the Device Administration Receiver

The receiver will get notified of events related to the policies you’ve declared to support. An application can selectively override callback methods. For example:

public static class PolicyAdmin extends DeviceAdminReceiver {
@Override public void onDisabled(Context context, Intent intent) { // Called when the app is about to be deactivated as a device administrator. // Deletes previously stored password policy. super.onDisabled(context, intent); SharedPreferences prefs = context.getSharedPreferences(APP_PREF, Activity.MODE_PRIVATE); prefs.edit().clear().commit(); } }

Activate the Device Administrator

Before enforcing any policies, the user needs to manually activate the application as a device administrator. It can be done like this:

if (!mPolicy.isAdminActive()) {
Intent activateDeviceAdminIntent = new Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN);
activateDeviceAdminIntent.putExtra( DevicePolicyManager.EXTRA_DEVICE_ADMIN, mPolicy.getPolicyAdmin());
// It is good practice to include the optional explanation text to // explain to user why the application is requesting to be a device // administrator. The system will display this message on the activation // screen. activateDeviceAdminIntent.putExtra( DevicePolicyManager.EXTRA_ADD_EXPLANATION, getResources().getString(R.string.device_admin_activation_message));
startActivityForResult(activateDeviceAdminIntent, REQ_ACTIVATE_DEVICE_ADMIN); }

Implement the Device Policy Controller

After the device administrator is activated successfully, the application then configures Device Policy Manager with the requested policy. For example:

Require password has minimum uppercase letters

DevicePolicyManager mDPM = (DevicePolicyManager) context.getSystemService(Context.DEVICE_POLICY_SERVICE); ComponentName mPolicyAdmin = new ComponentName(context, PolicyAdmin.class); ... mDPM.setPasswordQuality(mPolicyAdmin, PASSWORD_QUALITY_VALUES[mPasswordQuality]); mDPM.setPasswordMinimumLength(mPolicyAdmin, mPasswordLength); if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) { mDPM.setPasswordMinimumUpperCase(mPolicyAdmin, mPasswordMinUpperCase); }

If the requirement is not met, invoke the activity to ask user to reset password:

if (!mDPM.isActivePasswordSufficient()) { ... // Triggers password change screen in Settings. Intent intent = new Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD); startActivity(intent); }

Finally, if requirement is met, the app can continue:

if (!mDPM.isAdminActive(..)) { // Activates device administrator. ... } else if (!mDPM.isActivePasswordSufficient()) { // Launches password set-up screen in Settings. ... } else { // Grants access to secure content. ... startActivity(new Intent(context, SecureActivity.class)); }

Supporting Direct Boot

Android 7.0 runs in a secure, Direct Boot mode when the device has been powered on but the user has not unlocked the device.

   	  Most apps should not use Direct Boot mode, as the apps will be running before user has unlocked the device. It should only be used if it’s important for the app to run right after the system is started.

Requesting Access to Run During Direct Boot

Apps must register their components with the system before they can run during Direct Boot mode or access device encrypted storage. For example:

<receiver android:directBootAware="true" > ... <intent-filter> <action android:name="android.intent.action.LOCKED_BOOT_COMPLETED" /> </intent-filter> </receiver>

Accessing Device Encrypted Storage

The app will not be able to access the normal file system as the device is still locked. Android system provides two new storage locations for data:

Credential encrypted storage, which is the default storage location and only available after the user has unlocked the device.

Device encrypted storage, which is a storage location available both during Direct Boot mode and after the user has unlocked the device.

You can access device encrypted storage like this:

Context directBootContext = appContext.createDeviceProtectedStorageContext(); // Access appDataFilename that lives in device encrypted storage FileInputStream inStream = directBootContext.openFileInput(appDataFilename); // Use inStream to read content...

Getting Notified of User Unlock

When the user unlocks the device after restart, your app can switch to accessing credential encrypted storage and use regular system services that depend on user credentials.

To get notified when the user unlocks the device after a reboot, register a BroadcastReceiver from a running component to listen for unlock notification messages.

Migrating Existing Data

If a user updates their device to use Direct Boot mode, you might have existing data that needs to get migrated to device encrypted storage.

You can use:

Context.moveSharedPreferencesFrom()

Context.moveDatabaseFrom()

to migrate preference and database data between credential encrypted storage and device encrypted storage

Using Scoped Directory Access

This function make it easier for apps that just need access to specific directories. For example, photo apps only need to access the Pictures directory.

This is a new function provided from Android 7.0

Accessing an External Storage Directory

Example:

StorageManager sm = (StorageManager)getSystemService(Context.STORAGE_SERVICE); StorageVolume volume = sm.getPrimaryStorageVolume(); Intent intent = volume.createAccessIntent(Environment.DIRECTORY_PICTURES); startActivityForResult(intent, request_code);

The system may confirm the access with the user.

Accessing a Directory on Removable Media

Add a BroadcastReceiver that listens for the MEDIA_MOUNTED notification, for example:

<receiver android:name=".MediaMountedReceiver" android:enabled="true" android:exported="true" > <intent-filter> <action android:name="android.intent.action.MEDIA_MOUNTED" /> <data android:scheme="file" /> </intent-filter> </receiver>

When the user mounts removable media, like an SD card, the system sends a MEDIA_MOUNTED notification. Request access like this:

// BroadcastReceiver has already cached the MEDIA_MOUNTED // notification Intent in mediaMountedIntent StorageVolume volume = (StorageVolume) mediaMountedIntent.getParcelableExtra(StorageVolume.EXTRA_STORAGE_VOLUME); volume.createAccessIntent(Environment.DIRECTORY_PICTURES); startActivityForResult(intent, request_code);

This is a summary of the Cordova Security Guide.

Whitelist

Domain whitelisting is a security model that controls access to external domains over which your application has no control. Cordova provides a configurable security policy to define which external sites may be accessed. By default, new apps are configured to allow access to any site. Before moving your application to production, you should formulate a whitelist and allow access to specific network domains and subdomains.

Be aware that some websites may automatically redirect from their home page to a different url, such as using https protocol or to a country-specific domain. For example http://www.google.com will redirect to use SSL/TLS at https://www.google.com, and then may further redirect to a geography such as https://www.google.co.uk. Such scenarios may require modified or additional whitelist entries beyond your initial requirement

Note that the whitelist applies only to the main Cordova webview, and does not apply to an InAppBrowser webview or opening links in the system web browser.

Iframes and Calback ID Mechanism

If content is served in an iframe from a whitelisted domain, that domain will have access to the native Cordova bridge. This means that if you whitelist a third-party advertising network and serve those ads through an iframe, it is possible that a malicious ad will be able to break out of the iframe and perform malicious actions. Because of this, you should generally not use iframes unless you control the server that hosts the iframe content.

Certificate Pinning

Cordova does not support true certificate pinning. The main barrier to this is a lack of native APIs in Android for intercepting SSL connections to perform the check of the server’s certificate. Since Apache Cordova is meant to offer consistent APIs across multiple platforms, not having a capability in a major platform breaks that consistency.

There are ways to approximate certificate pinning, such as checking the server’s public key (fingerprint) is the expected value when your application starts or at other various times during your application’s lifetime. There are third-party plugins available for Cordova that can do that. However, this is not the same as true certificate pinning which automatically verifies the expected value on every connection to the server.

Self-signed Certificates

Using self-signed certificates on your server is not recommended. If you desire SSL, then it is highly recommended that your server have a certificate that has been properly signed by a well-known CA (certificate authority). The inability to do true certificate pinning makes this important. The reason is that accepting self-signed certificates bypasses the certificate chain validation, which allows any server certificate to be considered valid by the device.

Encrypted storage

For encrypted storage, you could consider using one of a number of secure storage plugins for Cordova. The cordova-plugin-secure-key-store plugin uses the Android Keystore and the iOS Keychain for stores sensitive data.

General Tips

Use InAppBrowser for outside links

Use the InAppBrowser when opening links to any outside website. This is much safer than whitelisting a domain name and including the content directly in your application because the InAppBrowser will use the native browser’s security features and will not give the website access to your Cordova environment. Even if you trust the third party website and include it directly in your application, that third party website could link to malicious web content.

If you want all page loads in your app to go through the InAppBrowser, you can simply hook window.open during initialization. For example:

document.addEventListener("deviceready", onDeviceReady, false); function onDeviceReady() { window.open = cordova.InAppBrowser.open; }

Validate all User Input

Always validate any and all input that your application accepts. This includes:

usernames

passwords

dates

uploaded media etc.

Because an attacker could manipulate your HTML and JS assets (either by decompiling your application or using debugging tools like chrome://inspect), this validation should also be performed on your server, especially before handing the data off to any backend service.

Other sources where data should be validated include:

User Documents

Contacts

Push Notifications

Do not cache sensitive data

If usernames, password, geolocation information, and other sensitive data is cached, then it could potentially be retrieved later by an unauthorized user or application.

Do not assume that your source code is secure

Since a Cordova application is built from HTML and JavaScript assets that get packaged in a native container, you should not consider your code to be secure. It is possible to reverse engineer a Cordova application to recover sensitive app data or hardcoded keys etc.

8.9. Vetting the Security of Mobile Applications
This is a summary of notes taken from the NIST Vetting the Security of Mobile Applications.
8.9.1. App Vetting Process
General Process
In an enterprise environment, before the mobile apps are deployed to the devices, they needs to be vetted. The process works like this:
-
The apps are submitted to the administrator.
-
The administrator submit the app for testing. The app testing process will use both static analysis and dynamic analysis services or tools to identity poteintial vulnerabilities of the apps. It should also generate reports about those vulnerabilities and produce risk assessments.
-
The generated reports will be submitted to an auditor. Based on the reports the auditor will then submit the recommendation to the approver.
-
Approver will either approve or reject the app.
-
If the app is approved, the administrator will deploy the app. Otherwise the administrator will reject the app.
The following diagram can be used to describe the process:
Further note that although app vetting processes may vary among organizations, organizations should strive to implement a process that is repeatable, efficient, consistent, and that limits errors.
Planning the Vetting Process
Before an organization can implement an app vetting process, it is necessary for the organization to first
-
develop app security requirements
-
understand the limitations of app vetting, and
-
procure a budget and staff for supporting the app vetting process.
Recommendation
-
Perform a risk analysis to understand and document the potential security impact of mobile apps on the organization’s computing, networking, and data resources.
-
Review and document the mobile device hardware and operating system security controls, for example an encrypted file system, and identify which security and privacy requirements can be addressed by the mobile device itself.
-
Review and document mobile enterprise security technologies, such as Mobile Device Management (MDM) solutions, and identify which security and privacy requirements can be addressed by these technologies.
-
Review the organization’s mobile security architecture and understand what threats are mitigated through the technical and operational controls. Identify potential security and privacy risks that are not mitigated through these technical and operational controls.
-
Develop organizational app security requirements by identifying general and context-sensitive requirements.
-
Educate organizational staff on the limitations of app vetting and the value of human involvement in an app vetting process.
-
Procure an adequate budget for performing an app vetting process.
-
Hire personnel, particularly auditors, with appropriate expertise.
8.9.2. App Testing
General app security requirements include:
Testing Requirements
Enabling authorized functionality
Preventing unauthorized functionality
Unauthorized functionality, such as data exfiltration performed by malware, must not be supported.
-
Malicious malwares that can
-
exfiltrating confidential information or PII to a third party
-
defrauding the user by sending premium SMS messages
-
injection of fake websites into the victim’s browser
-
the use of banner ads that may be presented in a manner which causes the user to unintentionally select ads that may attempt to deceive the user
-
-
Use open source or commercially available malware detection and analysis tools to identify known or new form of malwares
-
Are there communications with disreputable websites, domains, servers, etc
Limiting permissions
Apps should have only the minimum permissions necessary and should only grant other applications the necessary permissions.
-
File input/output (I/O) and removable storage
-
file scanning or access to files that are not part of an app’s own directory could be an indicator of malicious activity or bad coding practice
-
-
Privileged commands
-
Apps may possess the ability to invoke lower-level command line programs, which may allow access to low-level structures, such as the root directory, or may allow access to sensitive commands.
-
-
APIs
-
The app only uses designated APIs from the vendor-provided software development kit (SDK) and uses them properly; no other API calls are permitted
-
Protecting sensitive data
Apps that collect, store, and transmit sensitive data should protect the confidentiality and integrity of this data. This category includes preserving privacy, such as asking permission to use personal information and using it only for authorized purposes
-
Usage of invalid cryptography modules. See list of FIPS (Federal Information Processing Standards) validated modules
-
Cryptography implementations must also be maintained in accordance with approved practices.
-
Cryptographic key management is often performed improperly, leading to exploitable weaknesses. See NIST Recommendation for Key Management
-
The failure to properly validate digital certificates, leaving communications protected by these certificates subject to man-in-themiddle attacks.
-
-
Privacy considerations need to be taken into account for apps that handle PII, including mobile-specific personal information like location data and pictures taken by onboard cameras, as well as the broadcast ID of the device.
-
Data leakage
-
Through unauthorized network connections.
-
Shared system-level logs, where multiple apps log their security events to a single log file
-
Securing app code dependencies
The app must use any dependencies, such as on libraries, in a reasonable manner and not for malicious reasons. Specifically, an app should properly use other bodies of code, such as libraries, only when needed, and not to attempt to obfuscate malicious activity
-
Native Methods
-
Native method calls are typically calls to a library function that has already been loaded into memory.
-
However, can provide a level of obfuscation that impacts the ability to perform analysis of the app.
-
-
External Libraries and Classes
-
Third-party libraries and classes can be closed source, can have selfmodifying code, or can execute unknown server-side code.
-
Legitimate uses for loaded libraries and classes might be for the use of a cryptographic library or a graphics API.
-
Tools are available that can list libraries, and these libraries can then be searched for in vulnerability databases to determine if they have known weaknesses.
-
-
Dynamic Behavior
-
The key point here is the need to know where data used by an app originates from and knowing whether and how it gets sanitized.
-
It is critical to recognize that data downloaded from an external source is particularly dangerous as a potential exploit vector unless it is clear how the app prevents insecure behaviors resulting from data from a source not trusted by the organization using the app.
-
Requiring some level of risk-tolerance mitigation.
-
-
Inter-Application Communications
-
Be aware of situations where an app is using nonhuman entities to make API calls to other devices, to communicate with third-party services, or to otherwise interact with other systems.
-
Testing app updates
-
All apps, as well as their updates, should go through a software assurance vetting process, because each new version of an app can introduce new unintentional weaknesses or unreliable code.
-
But devices can install updates automatically, or users can install updates from somewhere else
-
Disabling all automatic updates
-
Only permitting use of an organization-provided app store
-
Enabling MDM mobile application management features
-
Testing Approaches
Correctness Testing
-
Software correctness testing is the process of executing a program with the intent of finding errors.
-
Although software correctness testing is aimed primarily at improving quality assurance, verifying and validating described functionality, or estimating reliability, it can also help to reveal potential security vulnerabilities since such vulnerabilities often have a negative effect on the quality, functionality, and reliability of the software.
Source Code Versus Binary Code
-
When source code is available, such as in the case of an open source app, a variety of tools can be used to analyze it.
-
Reviewers should generally use automated static analysis tools whether they are conducting an automated or a manual review, and they should express their findings in terms of Common Weakness Enumeration (CWE) identifiers or some other widely accepted nomenclature.
-
Static Versus Dynamic Analysis
-
Organizations should consider the technical trade-off differences between what static and dynamic tools offer and balance their usage given the organization’s software assurance goals.
Automated Tools
Classes of automated tools include
-
Simulators
-
Remote Device Access
-
Automated Testing
-
User Interface-Driven Testing
-
Data-Driven Testing
-
Fuzzing
-
Network-Level Testing
-
-
Test Automation
-
Static Tools
-
Static Analysis Tools
-
Metrics Tools
-
Organizations will need to use multiple automated tools to meet their testing requirements.
Sharing Results
-
The National Vulnerability Database (NVD) is the U.S. government repository of standards-based vulnerability management data represented using the Security Content Automation Protocol (SCAP)
-
The NVD includes databases of security checklists, security-related software flaws, misconfigurations, product names, and impact metrics.
-
SCAP is a suite of specifications that standardize the format and nomenclature by which security software products communicate software flaw and security configuration information
-
-
The CWE and Common Attack Pattern Enumeration and Classification (CAPEC) collections can provide a useful list of weaknesses and attack approaches to drive a binary or live system penetration test.
Recommendation
-
Review licensing agreements associated with analyzers and understand the security implications surrounding the integrity, intellectual property, and licensing issues when submitting an app to an analyzer.
-
Ensure that apps transmitted over the network use an encrypted channel (e.g., SSL) and that apps are stored on a secure machine at the analyzer’s location. In addition, ensure that only authorized users have access to that machine.
-
Identify general app security requirements needed by the organization.
-
Select appropriate testing tools and methodologies for determining the satisfaction or violation of general app security requirements.
-
Ensure that app updates are tested.
-
Leverage existing testing results where possible.
8.9.3. App Approval/Rejection
Report and Risk Auditing
-
One of the main issues related to report and risk auditing stems from the difficulty in collating and interpreting different reports and risk assessments from multiple analyzers due to the wide variety of security-related definitions, semantics, nomenclature, and metrics
-
It is recommended that an organization identify analyzers that leverage vulnerability reporting and risk assessment standards.
-
Organization-Specific Vetting Criteria
Sample criterias:
-
Requirements
-
Provenance
-
Data Sensitivity
-
App Criticality
-
Target Users
-
Target Hardware
-
Target Environment
-
Digital Signature
-
App Documentation
-
User Guide
-
Test Plans
-
Testing Results
-
Service-Level Agreement
-
Recommendation
-
Use analyzers that leverage a standardized reporting format or risk assessment methodology, or that provides intuitive and easy-to-interpret reports and risk assessments.
-
Ensure sufficient training of auditors on both the organization’s security requirements and interpretation of analyzer reports and risk assessments. Use multiple auditors to increase likelihood of appropriate recommendations.
-
Identify organization-specific vetting criteria necessary for vetting context-sensitive app security requirements.
-
Monitor public databases, mailing lists, and other publicly available security vulnerability reporting repositories to keep abreast of new developments that may impact the security of mobile devices and mobile apps.
8.10. NIAP Mobile App Vetting
This is a summary of the NIAP Mobile App Vetting Guidelines.
8.10.1. Security Functional Requirements
Random Bit Generation Services
The Application should select from the following approaches for its cryptographic operations:
-
use no DRBG functionality
-
invoke platform-provided DRBG functionality
-
implement DRBG functionality
DRBG: Deterministic Random Bit Generator (aka RNG, PRNG) based HMACs, Hashes, and Ciphers. In this requirement, cryptographic operations include all cryptographic key generation/derivation/agreement, IVs (for certain modes), as well as protocol-specific random values.
Storage of Credentials
The Application should select from the following approaches for storage of credentials in non-volatile memory:
-
not store any credentials
-
invoke the functionality provided by the platform to securely store credentials
-
implement functionality to securely store credentials
This requirement ensures that persistent credentials like secret keys, PKI private keys, or passwords are stored in a secure manner.
Access to Platform Resources
The application shall restrict its access to the following and additional hardware resources:
-
No Hardware Resources
-
Network Connectivity
-
Camera
-
Microphone
-
Location Services
-
NFC
-
USB
-
Bluetooth
The intent is to ensure that the selection captures all hardware resources which the application accesses, and that these are restricted to those which are required or used by the application.
The application shall also restrict its access to the following and additional sensitive information repositories:
-
No Sensitive Information Repositories
-
Address Book
-
Calendar
-
Call Lists
-
System Logs
Sensitive information repositories are defined as those collections of sensitive data that could be expected to be shared among some applications, users, or user roles, but to which not all of these would ordinarily require access.
Network Communications
The application shall restrict network communication to the following and additional application-initiated communications:
-
No Network Communication
-
User-initiated Communication for the list of Functions for which the User can Initiate Network Communication
-
Respond to Remotely Initiated Communications
This requirement is intended to restrict both inbound/outbound network communications to only those required, or to those initiated by the user.
Encryption Of Sensitive Application Data
The Application should select from the following approaches for storage of sensitive data in non-volatile memory:
-
Leverage Platform-provided Functionality to Encrypt Sensitive Data
-
Implement Functionality to Encrypt Sensitive Data
-
Not Store any Sensitive Data
Any file that may potentially contain sensitive data shall be protected. The only exception is if the user intentionally exports the sensitive data to non-protected files.
Supported Configuration Mechanism
The application shall invoke the mechanisms recommended by the platform or framework vendor for storing and setting configuration options.
Secure by Default Configuration
The application shall be configured by default with file permissions which protect it and its data from unauthorized access. There should be some form of trust boundary which protects the application and its data.
Specification of Management Functions
The TSF (Target of Evaluation Security Functionality) shall be capable of performing the following management functions:
-
No Management functions.
-
Enable/Disable the Transmission of any information describing the system’s hardware, software, or configuration
-
Enable/Disable the Transmission of any PII (Personally Identifiable Information)
-
Enable/Disable the Transmission of any application state (e.g. crashdump) information
-
Enable/Disable network backup functionality to enterprise or commercial cloud backup systems
TOE (Target of Evaluation) security functionality is the “combined functionality of all hardware, software, and firmware of a TOE that must be relied upon for the correct enforcement of the security functional requirements.
User Consent for Transmission of Personally Identifiable Information
The application shall:
-
Not Transmit PII over a Network
-
Require User Approval before Executing a Function that Transmits PII over a Network
This requirement applies only to PII that is specifically requested by the application; it does not apply if the user volunteers PII without prompting from the application into a general (or inappropriate) data field. A dialog box that declares intent to send PII presented to the user when the application is started is sufficient to meet this requirement.
Anti-Exploitation Capabilities
The application shall:
-
Not allocate any memory region with both write and execute permissions
-
Allocate memory regions with write and execute permissions for only a specified list of functions performing just-in-time compilation
-
Requesting a memory mapping with both write and execute permissions subverts the platform protection provided by DEP.
-
The application shall be compatible with security features provided by the platform vendor.
-
-
This requirement is designed to ensure that platform security features do not need to be disabled in order for the application to run.
-
The application shall not write user-modifiable files to directories that contain executable files unless explicitly directed by the user to do so.
-
-
Executables and user-modifiable files may not share the same parent directory, but may share directories above the parent.
-
The application shall be compiled with stack-based buffer overflow protection enabled.
-
-
Integrity for Installation and Update
The application shall:
-
Provide the ability or leverage the platform to check for updates and patches to the application software.
-
Be distributed using the format of the platform-supported package manager.
-
Be packaged such that its removal results in the deletion of all traces of the application, with the exception of configuration settings, output files, and audit/log events.
-
Not download, modify, replace or update its own binary code.
-
Provide the ability or leverage the platform to query the current version of the application software.
-
Ensure that the installation package and its updates shall be digitally signed such that its platform can cryptographically verify them prior to installation.
Use of Third Party Libraries
The application shall:
-
Be packaged with only third-party libraries that are required and vulnerability free.
Protection of Data in Transit
The application shall use one or more of the approaches for transmitting between itself and another trusted IT product:
-
Not Transmit any Data
-
Not Transmit any Sensitive Data
-
Encrypt all transmitted sensitive data with at least one of the following: HTTPS, TLS, DTLS, SSH
-
Encrypt all transmitted data with at least one of the following: HTTPS, TLS, DTLS, SSH
8.10.2. Security Assurance Requirements
The application shall be labeled with a unique references:
-
Application Name
-
Application Version
-
Application Description
-
Platform on which Application Runs
-
Software Identification (SWID) tags, if available
8.10.3. Selection-Based Security Functional Requirements
Random Bit Generation from Application
The application shall perform all deterministic random bit generation (DRBG) services in accordance with NIST Special Publication 800-90A using any of the following:
-
Hash_DRBG (any)
-
HMAC_DRBG (any)
-
CTR_DRBG (AES)
The deterministic RBG shall be seeded by an entropy source that accumulates entropy from a platform-based DRBG and a:
-
A software-based noise source
-
No other noise source
with a minimum of:
-
128 bits
-
256 bits
of entropy at least equal to the greatest security strength (according to NIST SP 800-57) of the keys and hashes that it will generate.
Cryptographic Key Generation Services
The application shall:
-
Generate no asymmetric cryptographic keys
-
Invoke platform-provided functionality for asymmetric key generation
-
Implement asymmetric key generation
Cryptographic Asymmetric Key Generation
The application shall:
-
Generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm
-
An RSA scheme using cryptographic key sizes of 2048-bit or greater that meet the following:
-
FIPS PUB 186-4, “Digital Signature Standard (DSS)”
-
ANSI X9.31-1998
-
-
Cryptographic Operation - Encryption/Decryption
The application shall:
-
Perform encryption/decryption in accordance with a specified cryptographic algorithm:
-
AES-CBC
-
and
-
AES-GCM
-
No other modes
with cryptographic key sizes of 256-bit.
Cryptographic Operation - Hashing
The application shall:
-
Perform cryptographic hashing services in accordance with a specified cryptographic algorithm:
-
SHA-1
-
SHA-256
-
SHA-384
-
SHA-512
-
No other algorithms
-
and message digest sizes:
-
160
-
256
-
384
-
512
-
No other message digest sizes
Cryptographic Operation - Signing
The application shall:
-
Perform cryptographic signature services (generation and verification) in accordance with a specified cryptographic algorithm:
-
RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 4.
-
Cryptographic Operation - Keyed-Hash Message Authentication
The application shall:
-
Perform keyed-hash message authentication in accordance with a specified cryptographic algorithm:
-
HMAC-SHA-256
-
and
-
SHA-1
-
SHA-384
-
SHA-512
-
No other algorithms
with key sizes the same length as those used in HMAC (in bits) and message digest sizes 256 and
-
160
-
384
-
512
-
No other sizes
bits that meet the following: FIPS Pub 198-1 The Keyed-Hash Message Authentication Code and FIPS Pub 180-4 Secure Hash Standard.
TLS Client Protocol
The application shall:
-
Invoke platform-provided TLS 1.2
-
Implement TLS 1.2 (RFC 5246)
supporting the following cipher suites:
-
Mandatory Cipher Suites: TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 5246
Optional Cipher Suites:
-
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
-
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246
-
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289
-
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
-
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289
-
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
-
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289
-
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
-
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289
-
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
-
TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
-
TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246
-
No other cipher suite
The application shall:
-
Verify that the presented identifier matches the reference identifier according to RFC 6125.
The application shall:
-
Establish a trusted channel only if the peer certificate is valid.
TLS Server Protocol
The application shall:
-
Invoke platform-provided TLS 1.2
-
Implement TLS 1.2 (RFC 5246)
supporting the following cipher suites:
-
Mandatory Cipher Suites: TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 5246
Optional Cipher Suites:
-
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
-
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246
-
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289
-
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
-
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289
-
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
-
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289
-
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
-
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289
-
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
-
TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
-
TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246
-
No other cipher suite
The application shall:
-
Deny connections from clients requesting:
-
SSL 2.0
-
SSL 3.0
-
TLS 1.0
-
TLS 1.1
-
The application shall:
-
Support mutual authentication of TLS clients using X.509 v3 certificates.
The application shall:
-
Not establish a trusted channel if the peer certificate is invalid.
The application shall:
-
Not establish a trusted channel if the distinguished name (DN) or Subject Alternative Name (SAN) contained in a certificate does not match the expected identifier for the peer.
DTLS Implementation
The application shall:
-
Implement the DTLS protocol in accordance with DTLS 1.2 (RFC 6347).
The application shall:
-
Implement the requirements in TLS (FCS_TLSC_EXT.1) for the DTLS implementation, except where variations are allowed according to DTLS 1.2 (RFC 6347).
The application shall:
-
Not establish a trusted communication channel if the peer certificate is deemed invalid.
HTTPS Protocol
The application shall:
-
Implement the HTTPS protocol that complies with RFC 2818.
The application shall:
-
Implement HTTPS using TLS (FCS_TLSC_EXT.1).
The application shall:
-
Notify the user and
-
Not establish the connection
-
Request application authorization to establish the connection
-
No other action
-
if the peer certificate is deemed invalid.
X.509 Certificate Validation
The application shall:
-
Invoked platform-provided functionality
-
Implement functionality
to validate certificates in accordance with the following rules:
-
RFC 5280 certificate validation and certificate path validation.
-
The certificate path must terminate with a trusted CA certificate.
-
The application shall validate a certificate path by ensuring the presence of the basicConstraints extension and that the CA flag is set to TRUE for all CA certificates.
-
The application shall:
-
The application shall validate the extendedKeyUsage field according to the following rules:
-
Certificates used for trusted updates and executable code integrity verification shall have the Code Signing purpose (id-kp 3 with OID <IP_ADDRESS>.<IP_ADDRESS>.3) in the extendedKeyUsage field.
-
Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID <IP_ADDRESS>.<IP_ADDRESS>.1) in the extendedKeyUsage field.
-
Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with OID <IP_ADDRESS>.<IP_ADDRESS>.2) in the extendedKeyUsage field.
-
S/MIME certificates presented for email encryption and signature shall have the Email Protection purpose (id-kp 4 with OID <IP_ADDRESS>.<IP_ADDRESS>.4) in the extendedKeyUsage field.
-
OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp 9 with OID <IP_ADDRESS>.<IP_ADDRESS>.9) in the extendedKeyUsage field.
-
Server certificates presented for EST shall have the CMC Registration Authority (RA) purpose (id-kp-cmcRA with OID <IP_ADDRESS>.<IP_ADDRESS>.28) in the extendedKeyUsage field.
-
The application shall:
-
Treat a certificate as a CA certificate only if the basicConstraints extension is present and the CA flag is set to TRUE.
X.509 Certificate Authentication
The application shall:
-
Use X.509v3 certificates as defined by RFC 5280 to support authentication for:
-
HTTPS
-
TLS
-
DTLS
-
When the application cannot establish a connection to determine the validity of a certificate, the application shall:
-
Allow the administrator to choose whether to accept the certificate in these cases
-
Accept the certificate
-
Not accept the certificate
8.10.4. Objective Security Functional Requirements
TLS Client Protocol
The application shall:
-
Present the signature_algorithms extension in the Client Hello with the supported_signature_algorithms value containing the following hash algorithms:
-
SHA256
-
SHA384
-
SHA512
-
and no other hash algorithms.
Use of Supported Services and APIs
The application shall:
-
Use platform-provided libraries, does not implement functionality for parsing the list of formats parsed that are included in the IANA MIME media types.
Software Identification and Versions
The application shall:
-
Include SWID tags that comply with the minimum requirements for SWID tag from ISO/IEC 19770-2:2009 standard.
-
Valid SWID tags must contain a SoftwareIdentity element and an Entity element as defined in the ISO/IEC 19770-2:2009 standard. SWID tags must be stored with a .swidtag file extensions as defined in the ISO/IEC 19770-2:2009.
-
8.10.5. Optional Security Functional Requirements
Cryptographic Symmetric Key Generation
The application shall:
-
Generate symmetric cryptographic keys using a Random Bit Generator as specified in FCS_RBG_EXT.1 and specified cryptographic key sizes:
-
128 bit
-
256 bit
-
TLS Client Protocol
The application shall:
-
Support mutual authentication using X.509v3 certificates.