Apple iOS application development guidance

This guidance contains recommendations for the secure development, procurement and deployment of iOS applications. Please familiarise yourself with the generic application development guidance before continuing.

Contents

1. Secure iOS application development
2. Questions for application developers
3. Secure deployment of iOS applications
4. Application wrappers

Regarding data at rest and keychain protection classes, the following terminology will be used:

Availability Class Name						Data Protection Class						Keychain Protection Class
A (When Unlocked)						NSFileProtectionComplete						kSecAttrAccessibleWhenUnlocked
B (While Unlocked)						NSFileProtectionCompleteUnlessOpen						N/A
C (After first unlock)						NSFileProtectionCompleteUntilFirstUserAuthentication (default on iOS 7 and above)						kSecAttrAccessibleAfterFirstUnlock
D (Always)						NSFileProtectionNone						kSecAttrAccessibleAlways
Passcode enabled						N/A						kSecAttrAccessible WhenPasscodeSetThisDeviceOnly*

Note that the other keychain classes have a ‘This device only’ counterpart. More information about these protection classes can be found within Apple’s security guide document and API documentation.

1. Secure iOS application development

This section covers techniques and recommendations for developers when building an application for the Apple iOS platform.

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.

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 kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly attribute could also be used to further harden local credential storage to prevent any synchronisation with the iCloud keychain. This acts the same as kSecAttrAccessibleWhenUnlocked. 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 evaluatedPolicyDomainState variable 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 applicationWillResignActive and applicationDidEnterBackground. 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 the localOnly option within the UIPasteBoard class.

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 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
• 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 whitelist.
• 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 whitelist. Applications should aim to keep perfect forward secrecy (PFS) enabled and not reduce the minimum TLS version supported.
• Ensure that kSecAttrSynchronizable is 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, WKWebView or FSafariViewController) 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.

2. 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:

Questions	What to look for in answers
What is the flow of data through the application – source(s), storage, processing and transmission?	Answers should cover all forms of input including data entered by the user, network requests, and inter-process communication.
Which data protection classes are used to store the various data types on the device?	Data should be stored using NSFileProtectionComplete (Class A) if access to that data is not required when the device is locked.					Data should be stored using NSFileProtectionCompleteUnlessOpen (Class B) if it is received when the device is locked, and access is not required during the locked state (e.g. email). When the device is subsequently unlocked, Class B data should be upgraded to Class A.				All other data should be stored using NSFileProtectionCompleteUntilFirstUserAuthentication (Class C). This is data required for background processing while the device is locked. If it is not required for background processing, it should be stored in Class A.			Answers to this question should generally be provided on a per-file or per-file-type basis. The answer “All data is stored using Class C” is not acceptable.
What device or user credentials are being stored?				Are these stored in the Keychain? Which Keychain protection class is used?				As with the Data Protection classes above, the appropriate Keychain classes should also be used to protect key material based on time of need.

2.2 Secure data transmission

The following questions will help you gain confidence that an iOS application transmits sensitive data securely:

Questions	What to look for in answers
Is transmitted and received data protected by cryptographic means, using well-defined protocols? If not, why not?	Mutually authenticated TLS, Secure Chorus, or other mutually authenticated secure transport should be used to protect information as it travels between the device and other resources. This should be answered specifically for each service the application communicates with to send and receive sensitive information.
Is App Transport Security enabled and are there any exceptions for certain domains? If so why?	App Transport Security should be enabled and exception domains should be avoided where possible.

2.3 IPC mechanisms

The following questions will help you gain confidence that an iOS application shares sensitive data securely:

Questions	What to look for in answers
Are any URL schemes or Universal Links declared or handled by the application?				What actions can these invoke?				Answers should cover any instances of use and suitably explain how and why they are used, rather than a ‘yes’ or ‘no’ reply.  Any inability to explain rationale should be taken as concern about the application.
Can other applications cause the application to perform a malicious action or request on its behalf?	Interactions with other applications should be limited to only those essential for the application to function.

2.4 Binary protection

The following questions will help you gain confidence that an iOS application protects its data within a binary:

Questions	What to look for in answers
Is the application compiled with Position Independent Execution (PIE)?	PIE should be used to help prevent exploitation of vulnerabilities in applications.
Is the application compiled with Automatic Reference Counting (ARC)?	ARC should be used for automatic object garbage collection to avoid developers manually allocating and freeing application memory.
Is the application compiled in release mode and has all debug information been removed from the binary?						All debugging information should have been removed from the application.
Does the application make use of binary anti-tamper or anti-hooking protections?						These protections improve the security of the application. If they are not used, reasons should be given to suitably explain why.
Does the application make use of obfuscated code or other protections against reverse engineering?						Code obfuscation can be used to help hinder reverse engineering of applications.  However, application code should not include any sensitive data.

2.5 Server side controls

The following questions will help you gain confidence that an iOS application protects its data on the server side:

Questions	What to look for in answers
If the application connects to remote services to access sensitive data, how can that access be revoked?				How long does that revocation take?			What is the window of opportunity for theft?			Assessors should be aware of the length of window of opportunity for data theft.

2.6 Client side controls

The following questions will help you gain confidence that an iOS application protects its data on the client side:

Questions	What to look for in answers
Does the application make use of iOS Web Views? Is JavaScript enabled within the Web View?	By default iOS Web Views support JavaScript. Therefore – where it is not needed – we recommend that this is explicitly disabled to protect against malicious JavaScript if injected into the Web View.
Are there any JavaScript bridges implemented within the application?	Assessors should be aware of the risks of JavaScript bridges and the attack surface exposed.

2.7 Other

These additional questions will help you gain confidence in how an iOS application protects itself.

Questions	What to look for in answers
Does the application implement jailbreak detection, and if so how?	Jailbreaking can never be completely protected against, but the more advanced the detection the more effort is required to bypass it. Mechanisms for detecting jailbroken devices range from checking for the installation of known jailbroken applications such as Cydia, through to technologies that will attempt to detect if a third party process has hooked into the application.
How is copy and paste managed?	Whichever solution is used to manage copy and paste, the appropriate risk owner should understand how data could leak and accept the risk. Is the Universal Clipboard being used? Have controls been implemented to protect against sensitive information being shared using device Handoff?
Is potentially sensitive data masked-off on screen when the application is sent to the background?	This should be performed to ensure that sensitive data is not leaked in screenshots taken of apps for task switching.
What configuration options are available to end users, and what is the impact to the solution’s security if the user were to change those settings?	Some user configuration options may cause the security of the solution to be weakened or disabled.
Has all debugging output been removed from the binary?				Are there no debug messages logged to the console output?				All debugging information should have been removed from the application.
Does the application make use of extensions?				Have they been subject to the same security controls as the main application?				Answers should cover any instances of use and suitably explain how and why they are used, rather than a ‘yes’ or ‘no’ reply.  Any inability to explain rationale should be taken as concern about the application.

3. 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 (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.

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.

Source: NCSC