Guidance

End User Devices Security Guidance: Apple iOS Application Security Guidance

Updated 14 October 2013

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 document provides guidance on application security for iOS devices. It provides recommendations on development good practices to help applications appropriately store and process OFFICIAL information.

Future guidance is planned to cover applications for other platforms.

This document should be read by:

• Anyone developing applications which will handle protectively marked data

• Administrators considering deploying applications for use with protectively marked data

• Organisations who are considering development of a custom in-house application for use with protectively marked data.

• Developers seeking general guidance on writing applications which do not themselves handle protectively marked data, but run on a device which does.

1. Key Principles

• This document discusses the process by which third-party apps should be designed, developed and deployed on public sector iOS devices. It complements existing guidance around secure application development in general, and does not remove the need for developers to adopt secure development practices.

• Applications which store, process, handle, or have network access to protectively marked information, must be developed within certain security constraints, and should be audited and assessed before use.

• If iOS is natively used to store protectively marked information, then third-party applications may be able to access that information through platform API methods. Exactly which data the applications have access to, and what constraints are involved, must be understood before the application is deployed.

• At this time, CESG cannot provide any services for the assessment of third-party applications. Departments must undertake this work on an individual, per-application basis. We may look to providing such services or assessment schemes in the future.

2. Context

This document refers to concepts described in the iOS Security Whitepaper [b] and the CESG Security Procedures for iOS 6 [c]. It is recommended that these documents be read and understood before reading this document.

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	kSecAttrAccessibleAfterFirstUnlock
D	NSFileProtectionNone (default on iOS 6)	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.

3. Goals and Assumptions

The goals of the recommendations are to:

• Ensure that sensitive data and credentials are protected appropriately when stored and transmitted.

• Ensure the device is protected by any existing protective monitoring solutions that the network might offer.

• Minimise the opportunity for accidental data leakage across application boundaries, whilst still permitting it when intentional.

• Ensure only authorised parties can access sensitive information.

• Maximise the usability of these applications whilst meeting a minimum required level of security in the development of the application.

In attempting to achieve these goals, the following assumptions are made:

• The device is configured broadly in line with the CESG platform configuration guidance for iOS

• The device is able to be jailbroken, which could compromise Class D data directly, and higher classes if the user subsequently unlocks the device without realising the device has been attacked.

• The device could have other third-party applications installed.

• The device will be in a locked state if lost or stolen.

4. Securing Applications

Applications which can be installed on an iOS device fall into five different categories, each of which has different considerations regarding information security.

4.1 Basic applications

Basic applications are third-party applications from Apple’s public App Store which are not designed or intended to handle protectively marked material, and will not have been through any extra audit process beyond the normal App Store review. It should be assumed that some proportion of basic applications will have unwanted functionality in them - either they are deliberately malicious, or by-design they will exhibit behaviours which may be detrimental to the overall security of the enterprise network.  

Nevertheless, to limit the opportunity for malicious code to be run on these devices, only a trusted set of application which provide a business benefit should be permitted to run on the enterprise device.

Trusted and permitted basic applications should be put into an enterprise app catalogue, which subsequently links through to the iOS public App Store. This requires that the public App Store is enabled, meaning that any application can be installed. Policies and procedures should be put into place to regularly audit devices via MDM to ensure any unpermitted applications are not installed.

Security Considerations

When deploying basic applications, the primary concerns for an organisation are protecting the enterprise network infrastructure from attack from these applications (as they will share the device’s VPN with other applications), and preventing data from leaking from a sensitive data store into the basic application. As the behaviour of the basic application can not normally be modified, this means that the protection has to be provided elsewhere, via network protections and appropriate use of iOS data-stores.

Network Protection

The diagram below, taken from the CESG Platform Security Guidance for iOS , illustrates the recommended network configuration for iOS devices which handle protectively marked 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

Figure 1. Recommended iOS Network Architecture

To prevent the basic 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 authenticate 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.

Data Store Hardening

By default, basic applications on iOS will be able to access the users’ Calendars, Contacts, Camera, Location, Photos and Social Networking accounts. On iOS 6 (and higher) these accesses are prompted on first use in each application such that the user can accept or decline the permission. Additionally using the Restrictions menu on the device, these prompts can be set to be automatically declined if required.

Nevertheless, there remains the possibility that the user could accept these accesses and the application could access data in these stores. If an untrusted application accessing the 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.

4.2 In-house Applications

In-house applications are those applications which are designed and commissioned by an organisation to fulfill 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 protectively marked 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 B2B or the App Store. Either way, apps should then be installed onto managed devices through an MDM or enterprise app catalogue front-end to gain the benefits of an app being enterprise-managed

Secure Development Recommendations

The following list is a set of recommendations that an iOS application should conform to in order to to store, handle or process protectively-marked data. Many of these recommendations are normal good-practice behaviours for applications on iOS, and a number of documented code snippets and examples are available for these on Apple’s developer portal.

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

• 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 protectively marked 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 protectively marked data, applications must store this credential in Class A or C storage, or prompt for it on application launch.

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

• The application must manage the pasteboard effectively by doing one (or more) of the following:

  • Clear the pasteboard when the application exits (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 protectively marked 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.

• All off-device communications must take place over a mutually-authenticated cryptographically-protected connection. For example:

  • The assured IPsec VPN to the corporate network (though see note below);

  • MIKEY-SAKKE with SRTP for secure real-time media streaming (secure voice);

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

• Internet-bound traffic must be HTTP or HTTPS and traverse the corporate infrastructure – proxy server, firewalls, and any enterprise monitoring solutions. Non-HTTP traffic may not be allowed to traverse the corporate firewalls, so functionality may not work. Using the NSURL and NSURLRequest APIs is an easy way of achieving this, as these requests will use any configured proxy settings on the device.

• The application must not allow its protectively marked 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.

• iCloud or other non-accredited Internet-based storage solutions must not be used to store protectively marked or sensitive information (e.g. credentials). The application must work as expected if iCloud is disabled on the device.

• The application must be compiled using the latest supported security flags, including PIE.

• The application must only use officially supported APIs.

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.

Additional Security Recommendations

The following list include 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 protectively marked 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 some time after the application was suspended.

Deploying Applications to Devices

Both in-house and basic 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, and will have more controls present in iOS 7.0 and higher.

Basic applications listed on an enterprise app store will 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 into place to audit devices ensuring any unpermitted applications are not installed.

4.3 Commodity Enterprise Applications

These applications are publicly available applications which provide business functionality that an organisation may wish to adopt, for example a PDF reader. The organisation may wish to access, store and process protectively marked information using these applications, but will generally lack a suitable relationship with the developer to be able to levy security requirements on them, or even find out details of application security information in the first place.

As the application will - through its use - have access to protectively marked information, the organisation should consider ways in which it will maximise the trust in it, and ways in which unexpected application behaviour could be detected. It is strongly recommended that application access to protectively marked information is limited to only those applications which the enterprise has determined trustworthy.

It is therefore recommended that the organisation seek to learn as much as possible about the security posture of the application, so that the risks of deploying that application can be understood and accepted if appropriate. For an example of some of the discussions organisations could have with these application developers, see the section Questions to ask application developers.

4.4 Enterprise application suites

These applications are publicly available applications which provide extensive business functionality contained in one application or set of applications, for example a replacement email, calendar, notes, and contacts suite of applications performing PIM sync. These applications will inevitably access, store and process a significant amount of protectively marked material. These applications may also require server-side components to be installed inside an organisation’s core network, which should also be considered as part of a wider risk assessment.

As with ‘commodity enterprise applications’, organisations are encouraged to learn as much as possible about the security posture of such 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.

Prior to deployment, organisations may also wish to consider commissioning independent assurance on an application of this type, due to the scale of access to protectively marked 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.

For an example of some of the discussions organisations could have with these application developers, see the section Questions to ask application developers.

4.5 Application wrappers

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

Category 1 technologies are essentially normal platform applications but which store and process minimal information, rather 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 cooperation) 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 an 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.

5. Questions to discuss with 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. Their responses should help provide confidence that the application is well-written and is likely to properly protect information.

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

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

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

• 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 on its behalf, or request.

• Is the application compiled with position independent execution (PIE)?

  • PIE should be used to help prevent exploitation of vulnerabilities in applications.

• Are cloud services, such as iCloud, used by the app? What data is stored there? How is it protected in transit?

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

• How is copy and paste managed?

  • Whichever solution is used to manage copy and paste, how data could leak should be understood and accepted by the appropriate risk owner.

• Is potentially-sensitive data masked off on-screen when you are backgrounded?

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

• If the application connects to remote services to access to protectively marked 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