Application development

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.