Introduction
Advice on how to minimise the loss of data from applications running on devices handling sensitive data.
It is primarily for risk assessors and application developers, and contains recommendations for the secure development, procurement and deployment of generic and platform-specific applications.
- We recommend that you read the generic application development section of this guidance in full, before you read the platform-specific guidance sections.
- Note that the NCSC does not provide services for the assessment of third-party applications; organisations must undertake this work on an individual, per-application basis.
About this guidance
This guidance will help you to:
- ensure sensitive data is protected appropriately when stored and transmitted
- minimise the opportunity for accidental data leakage across application boundaries
- ensure only authorised parties can access sensitive information
- maximise the usability of applications whilst maintaining security in the development phase
- restrict access to sensitive data to those applications designed to handle such material in a secure manner
In achieving these goals, the following assumptions are made:
- devices are configured in line with the NCSC End User Device guidance
- devices could have other third-party applications installed
- devices will be in a locked state if lost or stolen
- attackers can gain total control of devices (such as through jailbreaking/rooting) or otherwise gaining administrative privileges
In addition, the following principles are followed throughout:
- applications that store, process, handle, or have network access to sensitive information should be developed with security in mind from the start, and should be audited and assessed before use
- use the functionality of modern platforms to enhance the security of applications (this is the focus of the platform-specific guidance)
- if sensitive information is stored using the platform’s native functionality, then third-party applications may be able to access that information
- the specific data that applications can access (and the constraints are involved) must be understood with respect to each platform’s security model
PAGE 2 OF 16
Generic application development
This guidance provides advice on how to minimise the loss of data from applications running on devices handling sensitive data. It is primarily for risk assessors and application developers, and contains recommendations for the secure development, procurement and deployment of generic applications.
The guidance below is platform-agnostic, and describes how to mitigate common security issues, regardless of the platform used. We recommend that you read this generic application development guidance in full, before you read the platform-specific guidance.
Common security issues
When building an application, you should use the security mechanisms built into the native platform. Common security issues can be grouped into the following three areas:
- Secure data handling
- Application hardening
- Third party applications
Secure data handling
Data storage APIs
- You should not store sensitive information on a device when it's not required. If it must be stored on a device, make use of any native data storage protection APIs available on the platform.
- Make a model of the data flow in and out of the device, taking into consideration realistic threats that the system (and its users) may encounter. Most platforms provide documented APIs that allow data to be stored with different levels of protection.
- Always encrypt sensitive information when stored, protected by an authentication mechanism such as a passcode or platform-specific equivalent. When the sensitive data is no longer required on the device, it should be securely removed.
- Ensure the applications allows administrators to delete sensitive data from devices if they are compromised or lost.
Cryptography
- Secure implementation of cryptographic functions requires significant effort to properly design and verify, so wherever possible use native capabilities available on the platform.
- If using non-native cryptographic schemes, ensure they are reviewed and tested by third party experts.
- Storing cryptographic keys on the device will reduce the effectiveness of an additional cryptographic layer (as keys stored locally could be recovered from the device). Storing the keys on a remote server would prevent an attacker with physical access to the device from retrieving them. Users should be required to authenticate to the server. Alternately, you can use TPMs (trusted platform modules) and secure enclaves to improve the security of stored keys.
Data access authorisation
- Store sensitive information securely, and hide it from the user until they have been authenticated (and authorised) to view it.
- Perform user authentication using the native platform mechanisms, with each account being linked to an individual.
- Where practical, manage user accounts centrally.
- When the application has lost focus (or been backgrounded for a short amount of time), the authentication process should be repeated to ensure the identity or permissions of the current user have not changed.
Secure data transmission
- Send any sensitive information transferred between device and server using an appropriate encryption mechanism. All modern platforms have built-in support for transport layer security (TLS), which is the NCSC's preferred option.
- Restrict supported ciphers on both ends of the communication, so that only strong ciphers may be used. Take additional steps to maximise the security of the data connection, such as using certificate pinning to ensure the application connects to a host with a known, trusted certificate.
- Never send sensitive data over an insecure or unencrypted connection, and where possible non-sensitive data should also be sent over a secure connection.
- Alert the user if any suspicious attributes are detected that indicate the secure communication channel is under attack. In this case, the connection should be denied until a verified secure channel is available.
Session handling
- Session handling requires appropriate controls to be placed on the backend server to which the application connects.
- Ensure the backend server treats the application (and its user) as untrusted, until they can provide appropriate authentication.
- Ensure that sessions timeout periodically and require the user or application to repeat the authentication process.
Application hardening
Modern platforms typically avoid compiling applications to native code, instead preferring to use an intermediate language running in a container. However, it is possible, and sometimes necessary, to include native code components. As a developer you should be aware of the security differences between native and managed code. Principally, native code does not provide the same protections against memory mismanagement issues, such as buffer overflows and use-after-freevulnerabilities.
Stack protection
- Compile native code portions of the application to take advantage of any protection mechanisms that are available on the platform.
- Enable features such as Address Space Layout Randomisation (ASLR) and Stack Canaries during compilation in order to make the application more difficult to exploit. However, these should only be used to increase the effort needed to exploit vulnerabilities, and should not be solely relied upon to prevent exploitation.
Code obfuscation
You can take steps to make your applications more difficult to reverse engineer, but it's important that applications remain secure even when the entire system is understood by an attacker. As such, obfuscation techniques should only be considered to prevent the reverse engineering of technologies to safeguard (for example) intellectual property, and not to provide a robust security system. Even so, you can use obfuscation of both native and managed code to make reverse engineering attempts more difficult. This is also likely to increase the effort required for attackers to understand how to attack and break the application’s security model.
Jailbreak and root detection
Jailbroken or rooted devices are a threat to sensitive data they contain. As a method of hardening the application, consider implementing checks to detect if the device has been compromised. Detection will always be subject to circumvention by a determined attacker, however tests for common jailbreak and rooting methods allow for the application to take appropriate steps, such as alerting the user, or preventing the device from processing sensitive information.
Third party applications
You might be considering deploying third party applications on the same device as applications that handle sensitive data. The primary concerns here are:
- protecting the enterprise network infrastructure from attack via the third party applications
- preventing data from leaking from a sensitive datastore into a third party application
Modern platforms have built-in support for segregation of applications and users, which you should use wherever possible.
As the behaviour of third party applications cannot normally be modified, protection has to be provided elsewhere, via network protections and appropriate use of data-stores. Where possible, the developers of any third party applications should be approached in order to gain a deeper understanding of their product.
Applications that are likely to:
- be sources of data leaks
- track user movements
- interfere with other applications
- should not be installed. If software must be used despite security concerns that cannot be mitigated with technical controls, users should be given training on how best to manage the risk.
PAGE 3 OF 16
Android application development
This guidance contains recommendations for the secure development, procurement and deployment of Android applications. Please familiarise yourself with the generic application development guidance before continuing.
- Note that this guidance also refers to concepts described in the Android Security Centre and the NCSC End User Devices Security Guidance. We recommend you familiarise yourself with these documents before reading this guidance.
- A general guide to secure Android programming can be found on the Android developer web site.
PAGE 4 OF 16
Secure Android application development
1.1 Datastore hardening
Android, by default, provides each application on a device with access to a private directory to store its files. This protection is implemented using Linux user and group permissions. The security model is further enforced by applying Security-Enhanced Linux mandatory access control policies and leveraging a seccomp system call filter.
Android, as of version 7.0, on devices with file-based encryption (FBE), provides two storage locations on devices with FBE and Direct Boot. On FBE-enabled devices, developers should only store sensitive data in the Credential Encrypted (CE) storage.
Applications are able to access other areas of the device, such as contacts and SMS, by requesting permission from the user at runtime. The user can choose to permit the application access to areas such as the device’s calendar and phonebook, as well as features such as making phone calls or reading the current location. Once permitted, the application may use these features without further interaction from the user.
Despite protection offered by Android's sandboxing, it remains the responsibility of the application to store its data securely and to not undermine any protections that are in place by (for instance):
- writing data to publicly readable locations such as the external storage
- handling intents that can be called by any other application on the same device
- creating files with world readable/writable permissions
Remember that a process running on the device with sufficient permissions, will always be able to read and write any data in any application’s sandbox. We strongly recommended that applications holding sensitive data should build upon the sandbox with more secure functionality by (for example) leveraging the hardware-backed KeyStore.
Ultimately, it is not possible to guarantee the security of data on a device. You should assume that if a user continues to use a device after it has been compromised, the malware will be able to access the data. Android provides an API called SafetyNet for assessing the health and safety of the device. This API examines both hardware and software information about the device, to help determine if it has been tampered with or otherwise modified. We recommend that application developers use the API, then send the signed SafetyNet API results to their own servers to be validated, rather than on the device. SafetyNet should be used as a means to gain confidence about the integrity of the device, but it is not guaranteed to detect a compromise.
1.2 Network protection
The diagram below, taken from the EUD Security Guidance for Android, illustrates the recommended network configuration for Android devices which handle sensitive information. In summary, a VPN is used to bring device traffic back to the enterprise. Access to internal services is brokered through a reverse proxy server, which protects the internal network from attack.
To prevent the application from accessing sensitive internal resources, it is important that the reverse proxy server authenticates any requests from devices. This means that applications on the device which are trusted to access sensitive data must provide authentication with each request so that the reverse proxy can validate the request. Stored credentials must be private to only the trusted applications accessing those resources.
Internet requests from the application should be routed via the standard corporate internet gateway, to permit traffic inspection.
1.3 Secure application development
The following section contains recommendations that an Android application should conform to in order to store, handle or process sensitive data. Many of these recommendations are general good-practice behaviours for applications on Android. A number of documented code snippets and examples are available on the Android developer portal.
Secure data storage
In order to store sensitive data in a secure manner, Android applications should conform to the following:
- Applications should minimise the amount of data stored on the device. When needed, data should be retrieved from the server over a secure connection, and erased when it is no longer required.
- Sensitive information, if required, should only be stored in the hardware-backed KeyStore.
- The device’s external storage (for example the SD card) should not be used by the application to store sensitive data.
Server-side controls
Applications which store credentials should have robust server-side control procedures in place to revoke the credential, should the device or data be compromised.
Secure data transmission
In order to transmit sensitive data securely, Android applications should conform to the following:
- All off-device communications handling sensitive data should take place over a mutually-authenticated, cryptographically protected, connection.
- For TLS connections, the application should perform certificate pinning to a known endpoint. This process should leverage the Network Security Configuration. For more information refer to the NCSC’s TLS documentation.
- Certificates used by the application should be stored on the device using the Android KeyStore provider.
Note that at present there is no API on Android to check the status of the VPN. To securely check the status of the VPN, the internal service with which the application is communicating must be authenticated. The recommended way of performing this authentication is TLS with a pinned certificate. If mutual authentication is required to the internal service, mutual TLS with pinned certificates should be used.
Application security
- The application should be compiled using the latest supported compiler security flags.
- The application should not be compiled with the debug flag enabled.
- The application should not use any private APIs.
- The application should be compiled in release mode with all debug information stripped from the binaries.
- If Android Studio is used, it should be configured to shrink and optimise Java code.
Security recommendations
The behaviours listed below can increase the overall security of an application.
- Any data that is deemed necessary to store on the device should be encrypted either with keys that are not stored on the device, or that are stored in the Android KeyStore. Furthermore, key attestation should be used when hardware-backed key storage is available.
- Where possible, applications should sanitise in-memory buffers of sensitive data after use (if the data is no longer required for operation).
- Applications that require authentication on application launch should also request this authentication credential when returning back to the foreground after previously being backgrounded by a user, allowing for a small grace period.
- As the standard Android clipboard is shared between all applications on the device, do not not use it when accessing sensitive data. A private clipboard can be implemented if required by the application.
- The application should disable both manual and automatic screenshots within activities that display sensitive data by setting secure flags of the window within the application.
- Applications that use a shared UID will share the same sandbox. This means that if one application was compromised, all data in any application with a shared UID would also be compromised. Developers should share functionality between applications using intents, restricted by permissions.
- Intents created for IPC between trusted applications should use signature permissions to restrict access by other applications on the device.
- Applications that use Web Views should limit the features and capabilities to the minimum functionality required.The application should ensure that debugging output has been removed and sensitive information prevented from appearing within the device log files.
- JavaScript and local file access should be disabled unless specifically required.
- Caching should be disabled to prevent unnecessary exposure of sensitive data.
- The application should ensure that debugging output has been removed and sensitive information prevented from appearing within the device log files.
