Guidance

Apple iOS Application Development Guidance

Published 3 September 2014

This guidance was withdrawn on 9 June 2016

This content has been moved to the CESG website: https://www.cesg.gov.uk/eud-guidance

This guidance refers to concepts described in the iOS Security Whitepaper (Apple Inc, 2014) and the CESG End User Devices Security Guidance: Apple iOS 7 (CESG, 2014). It is recommended that these documents be read and understood before reading this document. Furthermore, it is recommended that developers read and understand Apple’s iOS Secure Coding Guide (Apple Inc, 2014).

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

Availability Class Name	Data Protection Class	Keychain Protection Class
A	NSFileProtectionComplete	kSecAttrAccessibleWhenUnlocked
B	NSFileProtectionCompleteUnlessOpen	n/a
C	NSFileProtectionCompleteUntilFirstUserAuthentication (default on iOS 7)	kSecAttrAccessibleAfterFirstUnlock
D	NSFileProtectionNone	kSecAttrAccessibleAlways

Developers who are eligible to receive CESG publications are also encouraged to read other CESG documentation on Secure Application Development - for example, Developers’ Note 6, which discusses coding best practices for C and C++ based code.

1. Changes between iOS 6.1 and iOS 7

iOS 7 introduces additional enterprise features which developers and application vendors can take advantage of. These features can be leveraged to provide additional security to the device or its applications, or increase the functionality without compromising the security of the device or its data.

1.1 Open In Management

Open In Management (OIM) is a Mobile Application Management (MAM) feature introduced in iOS 7 that allows data to be protected by restricting which applications are allowed to open the data. Only approved applications should be allowed to open OFFICIAL information, preventing unauthorised access to the data by third party applications. The OIM feature requires Mobile Device Management (MDM) support to be configured, but does not protect against copy/paste actions between applications.

1.2 Managed Distribution

Managed Distribution is an update to Apple’s Volume Purchase program. It allows an organisation that has purchased volume licenses for an application to retain control over the licenses after they have been installed on devices. Using a MDM solution, the organisation can revoke, and reassign applications licenses where they are required. Where a device has been lost or stolen, this can be used to revoke the devices license to use an application that has access to sensitive information.

1.3 Enterprise Single Sign On (SSO)

SSO is a Kerberos implementation for iOS 7. It requires a Kerberos environment in the corporate infrastructure. SSO allows configured applications to authenticate to protected URL prefixes, after which specified applications will not require authentication until the Kerberos ticket expires. A configuration profile can be installed on the device which whitelists applications that are allowed to use the SSO feature for the corporate infrastructure.

1.4 Third-Party App Data Protection

Third-Party Application Data Protection causes all third party application data to be protected by Class C data protection by default. This data is unencrypted when the device is in use, so Class A should still be used to protect sensitive data.

2. Secure iOS Application Development

2.1 Data Store Hardening

By default, third party App Store applications on iOS will be able to 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. Organisations can use the Restrictions menu on the device to set these prompts to be automatically declined if required.

Nevertheless, there remains the possibility that the user could accept these access permissions and the application could access data in these stores. If an untrusted application accessing any of this data represents a risk, then action should be taken to prevent this, by either:

• Not storing sensitive information in these data stores. Another third-party application may be able to store this information more securely than the default stores;
• Using the Restrictions menu to prevent application access to these stores.

As the potential exists that the device may be Jailbroken, the native datastore APIs 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 on the keychain.
• The appropriate data protection class should still be used to the level required.
• Sensitive data stored by the application should be marked with the “do not back up” attribute to ensure that specified files are not backed up to either iTunes or iCloud.

2.2 Network Protection

The diagram below, taken from the CESG Platform Security Guidance for iOS, illustrates the recommended network configuration for iOS devices which handle OFFICIAL information. In summary, a VPN is used to bring device traffic back to the enterprise, and access to internal services is brokered through a reverse proxy server, which protects the internal network from attack.

Recommended network architecture for deployments of iOS 7

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.

2.3 Secure Application Development Recommendations

The following list is a set of recommendations that an iOS application should conform to in order to store, handle or process OFFICIAL 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.

Organisations should consider how they will ensure developers follow these recommendations.

Secure Data Storage

• Applications must use the iOS Keychain APIs to store credentials.
• Applications must use the iOS Data Protection API to store sensitive file-system data.
• Applications must only use Class A or B
• Storage for OFFICIAL data, even if data is subsequently super-encrypted as part of another cryptosystem (e.g. proprietary encryption of an application’s database). Private keys must be marked as non-migratory.
• Where a credential is required to authenticate to a remote service that provides access to OFFICIAL data, applications must store this credential in Class A or C storage, or prompt for it on application launch.
• Developers should be careful when storing information in the cloud. iCloud or other non-accredited Internet-based storage solutions should not be used to store OFFICIAL or sensitive information (e.g. credentials). The application must work as expected if iCloud is disabled on the device.

Server Side Controls

• Applications which store credentials in Class C must have robust server-side control procedures in place to revoke that credential should the device or data be compromised.

Other

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.
• Mask off all OFFICIAL data on screen when the application receives notifications that it will enter the background state (applicationWillResignActive and applicationDidEnterBackground) to ensure that the screenshot taken of the application does not contain sensitive information.

Secure Data Transmission

• All off-device communications must take place over a mutually-authenticated cryptographically-protected connection. For example:
• The assured IPsec VPN to the corporate network.
• MIKEY-SAKKE with SRTP 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 – do not use the built-in certificate store for trust.
• The application must not allow its OFFICIAL data to be opened in other applications on the device (e.g. through Open In) unless that application is 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, depending on the information stored different security measures should be taken
• Assessors should make sure that sensitive data is not transmitted to unassured cloud services. If non-sensitive data is transmitted, or data is transmitted to accredited data centres then questions should be asked about data in transit protection.

Note that at present there is no appropriate 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

• 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).
• The application should only use officially supported APIs.

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 Classes A and B.
• Applications should sanitise in-memory buffers of OFFICIAL data after use.
• 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 on application launch should also request this authentication credential when switching back to the application sometime after the application was suspended.

3. Questions for application developers

The most thorough way to assess an application before deploying it would be to conduct a full source-code review of the product to ensure it meets the security recommendations and contains no malicious or unwanted functionality. As it is recognised that for the majority of third-party applications this will be infeasible or impossible, this section instead provides some example questions which an organisation may consider asking application developers, and some information on responses to expect. Their responses should help provide confidence that the application is well-written and is likely to properly protect information.

3.1 Secure Data Storage

• 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 interprocess 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. e-mail). 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” should not be acceptable.
• What device or user credentials are being stored? Are these stored in the Keychain? Which Keychain class?
  • As with the Data Protection classes above, the appropriate Keychain classes should also be used to protect key material based on time of need.

3.2 Secure Data Transmission

• Is transmitted and received data protected by cryptographic means, using well-defined protocols? If not, why not?
  • Mutually authenticated TLS, MIKEY-SAKKE, 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.

3.3 IPC Mechanisms

• Are any URL schemes or UTIs declared or handled? What actions can these invoke?
  • Can other applications cause the application to perform a malicious action or request on its behalf?

3.4 Binary Protection

• 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.

3.5 Other

• 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 it.
• How is copy and paste managed?
  • Whichever solution is used to manage copy and paste, understanding how data could leak should be understood and accepted by the appropriate risk owner.
• 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?
  • Assessors should be aware of configuration options which may cause the security of the solution to be weakened or disabled.

3.6 Server Side Controls

• If the application connects to remote services to access OFFICIAL data, how can that access be revoked? How long does that revocation take?
  • Assessors should be aware of how long the window of opportunity is for theft.

4. Secure iOS Application Deployment

4.1 Third-Party App Store Applications

Untrusted Third Party Applications

Applications that are untrusted should be restricted from handling OFFICIAL material. It should be assumed that some proportion of third-party applications will have unwanted functionality in them. While this functionality may not necessarily be malicious, these applications should be viewed as potential sources of leakage for sensitive data. An evaluation must be made on whether or not an application is trusted to a high enough degree to run on the device.

Operating system features can be used to help restrict third-party applications from corporate infrastructure, though 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, developers of the application should be consulted in order to understand better the limitations and restrictions of the application. This will help aid its evaluation. The Questions to discuss with application developers section should be used as a minimum set of questions that the developers should be asked about their application.

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, and steps should be taken to minimise the threat and the impact an application may have in the scenario it turns out to be malicious, or compromised. Unless specifically designed to handle OFFICIAL material, a third-party application should never have access to it. Native operating system features introduced in iOS 7, 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 used to open classified information, or be allowed to access the corporate infrastructure.

Organisations are encouraged to 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 the security posture expected of it.

Where a third-party application is being considered to handle OFFICIAL data, organisations may also wish to consider commissioning independent assurance on the application due to the access to OFFICIAL material it will have. 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 an organisation. Though Apple screens applications submitted to the App Store, this does not ensure that it is free of malware. Malicious applications may seek to gain access to sensitive information, or attempt to access an 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, sensitive data 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 to transmit the data. Third-party applications should be excluded from accessing an organisation’s network. This can be only allowing trusted applications to access the VPN to the 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. Questions that can be asked to developers can be found in the Questions for Application Developers section.
• Data should be protected from third party applications by making appropriate use of the keychain.
• Open-in Management should be used to restrict access to certain file types to approved applications. This will help prevent applications that were not designed for handling sensitive documents from doing so.

4.2 In-House Applications

In-house applications are those applications which are 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. For the purposes of this document, these applications are expected to access, store, and process OFFICIAL data. The intention when securing these applications is to minimise the opportunity from data leakage from these applications, and to harden them against physical and network-level attacks.

Security Considerations

Regardless of whether the application is developed by an internal development team, or under contract by an external developer, organisations should ensure that supplied binaries match the version which they 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 a MDM server or enterprise app catalogue front-end to gain the benefits of an 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.3 Application Wrappers

Security Considerations

A variety of “application wrapping” technologies exist on the market today. Whilst these technologies ostensibly come in a variety of forms which provide different end-user benefits, on most platforms, including iOS, they essentially work in one of three ways:

1. They 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.

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

3. The source-code to the surrogate application is modified to incorporate a SDK provided by the technology vendor. This SDK modifies the behaviour of standard API calls to instead call the SDKs API calls. The developer of the surrogate application will normally need to be involved in the wrapping process.

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 all data or not use certain API calls.

On iOS, both category 2 and 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, these technologies 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 applications. Preferably, in-house applications should be developed specifically against the previously described security recommendations wherever possible. The use of App-wrapping technologies should only be used as a less favourable alternative method of meeting the given 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, and in the general case it is difficult to assert how any given wrapped application will behave. As such, CESG 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 a SDK or library which developers use as they would use any other library or SDK. In the same way that CESG do not assure any standalone cryptographic library, we will not provide assurance in SDKs which wrap applications. The developer using the SDK should be confident in the functionality of that SDK as they would be with any other library.