1.1 Datastore hardening
By default, third party App Store applications on iOS will be able to ask for access the users’ Calendars, Contacts, Camera, Location, Photos, and Social Networking accounts. On iOS these accesses are prompted on first use in each application, such that the user can accept or decline the permission. You can configure Restrictions settings on the device to prevent this functionality being used. Within an organisation, this is typically configured and deployed using an MDM-based solution. More information about MDM managed devices can be found within NCSC’s end user device guidance.
Nevertheless, there remains the possibility that the user could accept these access permissions and the application could access data in these stores. If there's a risk of an untrusted app accessing this data, then you should not store sensitive information within these datastores. A third party application may be able to store this information more securely than the default stores.
As the potential exists that the device may be compromised, on-device encryption routines cannot be solely relied on to protect sensitive information. Sensitive information should not be stored on a device for longer than it is required. Where sensitive information is stored on the device, even if temporarily, the following steps should be taken:
- Sensitive credentials should be sufficiently encrypted before being stored within the keychain using the appropriate keychain class described in section 1.3 below.
- The appropriate data protection class should still be used.
- Sensitive data stored by the application should be marked with the 'do not backup' attribute to ensure that specified files are not included within an iTunes or iCloud backup.
1.2 Network protection
The diagram below, taken from the NCSC EUD Security Guidance for iOS, illustrates the recommended network configuration for iOS 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, should provide authentication with each request so that the reverse proxy can validate the request. Stored credentials should 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 recommendations
The following section contains recommendations that an iOS 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 iOS, and a number of documented code snippets and examples are available on Apple’s developer portal.
Secure data storage
In order to store sensitive data in a secure manner, iOS applications should conform to the following:
- Applications should use the iOS Keychain APIs to store credentials.
- Applications should use the iOS Data Protection API to store sensitive file system data.
- Applications should store as much data as possible using data protection classes A and B.
- Private keys should be marked as non-migratory.
- Where a credential is required to authenticate to a remote service that provides access to sensitive data, applications must store this credential in Class A or C keychain protection classes, or prompt for the credential on application launch.
- The
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnlyattribute could also be used to further harden local credential storage to prevent any synchronisation with the iCloud keychain. This acts the same askSecAttrAccessibleWhenUnlocked.However, it is only available when devices have a passcode set and is protected via hardware-backed storage mechanisms. - Developers should be careful when storing information in the cloud. iCloud or other Internet-based storage solutions should not be used to store sensitive information (e.g. credentials). The application must work as expected if iCloud is disabled on the device.
- Certain keychain APIs can be used to further constrain specific keychain items. To only allow access for Touch ID only, use
kSecAccessControlTouchIDCurrentSet. A similar effect can be achieved using the secure enclave hardware-based key manager (kSecAttrTokenIDSecureEnclave). These attributes should be investigated to ensure the appropriate level of protection is implemented during development of a feature. More information about the secure enclave can be found within the API documentation. - On iOS version 9 and later, it is also possible to prevent a physical attacker from enrolling their own fingerprint on the device. This can be performed by reading the
evaluatedPolicyDomainStatevariable to determine if TouchID enrolment changes have occurred since last usage. - We recommend that the application performs a wipe of its keychain data on first install (not upgrade). This can prevent keychain data being reused if the device is, for example, sold at a later stage and a full device wipe has not been performed.
- Mask off all sensitive data on screen when the application receives notifications that will enter the background state using
applicationWillResignActiveandapplicationDidEnterBackground. This is to ensure that the screenshot taken of the application does not contain sensitive information. - Network communication can also be cached within certain databases within the application sandbox. Ensure any network-level caching is not performed when sensitive data is being retrieved from the server side. Certain iOS APIs perform caching of network traffic (including plaintext data sent via HTTPS) on the device. If an attacker is able to gain access to the contents of the sandbox, they may be able to recover this data. Therefore, caching related APIs should be reviewed to ensure that sensitive data is not stored. More information can be found within Apple’s cache policy documentation.
Server side controls
Applications which store credentials must have robust server-side control procedures in place in order to revoke credentials should the device or data be compromised.
Pasteboard and debugging data
The application must manage the pasteboard effectively by doing one (or more) of the following:
- Clear the pasteboard when the application exits or loses focus (crashes may still result in data leakage).
- Implement a private pasteboard within your application - do not use the system pasteboard.
- Encrypt the pasteboard with a key stored in the Developer’s keychain. This also allows pasting between the same developer’s applications.
- Exclude sensitive information from the Universal Clipboard (Handoff Feature). This can be performed by using the
setItems(_:options:)method with thelocalOnlyoption within theUIPasteBoardclass.
The application must ensure that debugging output has been removed and sensitive information prevented from appearing within the device log files.
- Logging APIs such as ‘NSLog’, ‘printf’, ‘NSAssert’, etc. should be reviewed and removed from production builds if sensitive information is being logged using these APIs.
- The application should detect and notify a user when screen capture is performed on iOS 11 and take appropriate action. For example, the application could display a warning and/or exit to prevent screen capture of sensitive data. More information about this feature can be found within the API documentation.
Secure data transmission
In order to transmit sensitive data securely, iOS applications should conform to the following:
- All off-device communications must take place over a mutually-authenticated, cryptographically-protected connection. For example:The application must not allow its sensitive data to be opened in other applications on the device (e.g. through Open In) unless that application is on an appropriate enterprise-managed allow list.
- the assured IPsec VPN to the corporate network
- Secure Chorus for secure real-time media streaming such as secure voice
- Transport Layer Security (TLS) with certificate pinning to a known endpoint to a service within the corporate network; more information on TLS can be found within NCSC’s TLS documentation
- Any security-critical settings (such as server addresses and certificates) must be defined at build time or be enterprise-managed. The user must not be able to alter these settings.
- If cloud services, such as iCloud, are used by the app to store information, this should be protected using the appropriate encryption mechanisms both from a network transmission perspective and data storage perspective.
- Applications should make use of App Transport Security (ATS) and should not disable this feature or add domains to the exception allow list. Applications should aim to keep perfect forward secrecy (PFS) enabled and not reduce the minimum TLS version supported.
- Ensure that
kSecAttrSynchronizableis not set for security-sensitive keychain items (as they will be included in an iCloud keychain backup, if this functionality is enabled).
Note that at present there is no API on iOS 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
To hinder the exploitation of any potential memory corruption vulnerabilities, the following recommendations should be followed:
- The application should be compiled using the latest supported security flags.
- The binary should be compiled with the Process Independent Executable (PIE) flag set.
- The application should make use of Automatic Reference Counting (ARC) – which is enabled by default.
- The application should not use private APIs.
Client side security
The following recommendations should be followed to improve the security of the client:
- Secure coding practices should be followed to protect against input injection attacks. More information can be found in Apple’s secure coding guide.
- If the application uses Web Views (
UIWebView,WKWebVieworFSafariViewController) it should disable features which are not required by content loaded into the WebView (for example JavaScript or local file access). This will lead to a reduction in attack surface and help protect this area of the application. - If content is being loaded locally into a Web View, users should be prevented from changing the filename or path which is loaded and they should not be able to edit the loaded file.
Security requirements
The following list includes some other behaviours which can increase the overall security of an application.
- Applications should store as much data as possible in data protection classes A and B (as described at the top of this page).
- Applications should sanitise in-memory buffers after use, where possible, if the data is no longer required for operation (for example a temporary password or PIN buffer).
- Applications should not upgrade the storage class of an existing file from Class D to a higher class. Instead, create a new file and copy the data across before deleting the original file. This ensures that the file is wrapped with a new key that may not be forensically recovered from Class D analysis.
- Applications should minimise the amount of data stored on the device. Retrieve data from the server when needed, over a secure connection, and erase it when it is no longer required.
- Applications that require authentication when launched should also request this authentication credential when returning back into the foreground after previously being backgrounded by a user, allowing for a small grace period.
PAGE 10 OF 16
Questions for application developers
For anyone procuring an application built by a third party, you can ask developers the example questions below. Their answers will help you gain more (or less) confidence about the security of their products.
The most thorough way to assess an application before deploying it would be to conduct a full source code review to ensure it meets the security recommendations and contains no malicious or unwanted functionality. Unfortunately, for the majority of third party applications, this will be infeasible or impossible. However, the responses from the third party should help provide confidence that the application is well written and likely to protect information properly.
2.1 Secure data storage
The following questions will help you gain confidence that an iOS application stores sensitive data securely:
2.2 Secure data transmission
The following questions will help you gain confidence that an iOS application transmits sensitive data securely:
2.3 IPC mechanisms
The following questions will help you gain confidence that an iOS application shares sensitive data securely:
2.4 Binary protection
The following questions will help you gain confidence that an iOS application protects its data within a binary:
2.5 Server side controls
The following questions will help you gain confidence that an iOS application protects its data on the server side:
2.6 Client side controls
The following questions will help you gain confidence that an iOS application protects its data on the client side:
2.7 Other
These additional questions will help you gain confidence in how an iOS application protects itself.
PAGE 11 OF 16
Secure deployment of iOS applications
This section recommends how to securely deploy the application, should it be from third party organisation or via an in-house application.
3.1 Third party app store applications
iOS supports a number of methods to install new third party applications. The following section divides these into two categories, trusted and untrusted.
Untrusted third party applications
Untrusted applications are those that have been produced by developers that your organisation does not have a relationship with. This includes applications hosted on the Apple App Store. Untrusted applications should be restricted from handling sensitive material. You should assume that a proportion of third party applications will have unwanted functionality. While this functionality may not necessarily be malicious, these applications should be viewed as potential sources of leakage for sensitive data. You should evaluate whether or not an application can run on the device.
Operating system features can be used to help restrict third party applications from corporate infrastructure. Although these features should be regarded as techniques to help mitigate the potential threat posed by the installation of third party applications, they cannot guarantee complete protection.
The ideal method of mitigation is to not allow any third party applications to be installed on the device, though in reality this decision must be taken on a per application basis. Where possible, consult the developers of the application to understand better its limitations and restrictions. To help your evaluation, you can use the questions given above in the Questions for application developers section (feel free to ask more, these represent the minimum you should find out).
Trusted third party applications
A trusted third party application is an application that has not been developed in-house, but where the risk of trusting the application has been accepted. This should not result in complete trust in the application. Steps should be taken to minimise the threat and impact an application may have if it turns out to be malicious, or compromised.
Unless specifically designed to handle sensitive material, a third party application should never have access to it. Native operating system features, such as Open In Management, should be used to restrict sensitive access only to applications that have been approved. A third party PDF reader installed from Apple’s App Store, for example, should never be allowed to access your corporate infrastructure.
You should learn as much as possible about the security posture of an application, so that the risks of deploying it can be understood and managed wherever possible. Organisations should ideally establish a relationship with the developers of these products and work with them to understand how their product does (or does not) meet its expected security posture.
Where a third party application is being considered to manage sensitive data, you may also wish to consider commissioning independent assurance. This is particularly true if the application implements its own protection technologies (such as a VPN or data-at-rest encryption), and does not use the native protections provided by iOS. Many enterprise applications feature server side components and when present, these should be considered as part of the wider risk assessment.
Security considerations
Third party applications may pose a threat to your organisation. Though Apple screens applications submitted to the App Store, this does not ensure that they are free of malware. Malicious applications may seek to gain access to sensitive information, or attempt to access your organisation’s network. Precautions should be taken in order to mitigate these threats.
In order to prevent sensitive information being leaked to a third party application, it should be stored and transmitted securely. The data should be stored on the device using Class A data storage. When in transit, encrypted protocols should be used.
Third party applications should be excluded from accessing your organisation’s network. This can be achieved by only allowing trusted applications to access the VPN to your organisation’s network, using the Per App VPN feature.
Approaching the developers of an application will help gain an insight into its construction. An application should not be installed if it is likely to leak data, interfere with other applications or track the movements of a user.
Security requirements
Best practice when using third party applications is as follows:
- Server side components such as a reverse proxy should be used to restrict network enterprise access to trusted applications.
- The developers should be contacted in order to better understand the security posture of the application. Use the Questions for Application Developers section as your starting point.
- Data should be protected from third party applications by making appropriate use of the keychain.
- Open-in Management should be used to ensure certain file types can only be accessed by approved applications. This will help prevent applications that were not designed for handling sensitive documents from doing so.
3.2 In-house applications
In-house applications are those designed and commissioned by an organisation to fulfil a particular business requirement. The organisation can stipulate the functionality and security requirements of the application, and can enforce these contractually if the development work is subcontracted.
The intention when securing these applications is to minimise the opportunity for data leakage from these applications, and to harden them against physical and network-level attacks. For the purposes of this document, these applications are assumed to access, store, and process sensitive data.
Security considerations
Regardless of whether the application is developed by an internal development team, or under contract by an external developer, you should ensure that supplied binaries match the version which you were expecting to receive if supplied via business-to-business or the App Store. Either way, applications should then be installed onto managed devices through an MDM server or enterprise app catalogue front-end, to gain the benefits of the app being enterprise-managed.
Security requirements
Both in-house and third party App Store applications should be deployed directly to devices through an enterprise app catalogue. This means they will be marked as managed applications which will not be subject to iCloud backup routines.
Third party applications listed on an enterprise app catalogue may link through to the public App Store. In order for a user to install these applications, the public App Store must be enabled, meaning that any application from the public App Store can be installed. To manage this risk, policies and procedures should be put in place to audit devices, ensuring any unpermitted applications are not installed.
PAGE 12 OF 16
Applications wrappers
4. Application wrappers
This section covers the different types of application wrappers, giving descriptions and the security considerations of each.
4.1 Security considerations
A variety of 'application wrapping' technologies exist on the market today. Whilst these technologies ostensibly come in a variety of forms, each providing different end-user benefits, on most platforms (including iOS) they essentially work in one of three ways:
Category 1: These provide a remote view of an enterprise service. For example, a Remote Desktop view of a set of internal applications that are running at a remote location, or a HTML-based web application. Multiple applications may appear to be contained within a single application container, or may live separately in multiple containers to simulate the appearance of multiple native applications. Usually only temporary cached data and/or a credential is persistent on the device itself.
Category 2: These are added to an application binary after compilation and dynamically modify the behaviour of the running application (for example to run the application within another sandbox and intercept and modify platform API calls) in an attempt to enforce data protection.
Category 3: The source code to the surrogate application is modified to incorporate a Software Development Kit (SDK) provided by the technology vendor. This SDK modifies the behaviour of standard API calls to instead call the SDK's API. The developer of the surrogate application will normally need to be involved in the wrapping process.
4.2 Security requirements
Category 1 technologies are essentially normal platform applications but which store and process minimal information, rather than deferring processing and storage to a central location. The development requirements for these applications are identical to other native platform applications. Developers should follow the guidelines given above.
Category 2 and 3 wrapping technologies are frequently used to provide enterprise management to applications via the MDM that the device is managed by. SDKs are integrated into these MDM solutions and can be used to configure settings in the application or to modify the behaviour of the application. For example, the application could be modified to always encrypt data or not use certain API calls.
On iOS, both category 2 and category 3 wrapping technologies require the surrogate developer’s co-operation to wrap the application into a signed package for deployment onto an iOS device. As such, normally only custom-developed in-house applications, and sometimes B2B applications (with co-operation) can use these technologies.
As the robustness of these wrapping technologies cannot be asserted in the general case, they should not be used with an untrusted application; they should only be used to modify the behaviour of trusted applications, or for ease of management of the wrapped application. Preferably, in-house applications should be developed specifically against the previously described security recommendations wherever possible. The use of app-wrapping technologies should be seen as a less favourable alternative method of meeting the above security recommendations, where natively meeting them is not possible.
Ultimately, it is more challenging to gain confidence in an application whose behaviour has been modified by a category 2 technology. It is difficult to assert that dynamic application wrapping can cover all the possible ways an application may attempt to store, access and modify data. It is also difficult to make any general assertions about how any given wrapped application will behave. As such, the NCSC cannot give any assurances about category 2 technologies or wrapped applications in general, and hence cannot recommend their use as a security barrier at this time.
However, category 3 technologies are essentially an SDK or library which developers use as they would any other library or SDK. In the same way that the NCSC does not assure any standalone cryptographic libraries, we do not provide assurance in SDKs which wrap applications. The developer using the SDK should be confident of its functionality, as they would be with any other library.
