16 August 2013
This article requires that the reader have a knowledge of DPS App Builder as well as access to an iOS Developer account. In addition, the reader should have a familiarity with the iOS application provisioning process. The reader should also be familiar with Enterprise Mobile Device Management (MDM) software and/or services for Enterprise app deployment.
Original publication date: 07/15/2013
Modified: 07/15/2013 (Change log)
User level: Intermediate
Additional required other products
Note: If you have questions about this article, use the comments feature at the bottom of the article. Please don’t contact technical support with questions about Adobe Developer Connection articles.
DPS offers an easy solution for periodical publishing to tablets. It also offers a convenient and robust platform for Enterprise document distribution. Many Enterprise customers want on-device content protection for their DPS apps on iOS devices, so that those documents will be difficult or impossible to access outside of the DPS app. This article will explore how to protect content on an iOS device, as well as just how secure this protection method is.
For this article, we will define protection to mean that files on the device are protected from reading, modifying, deleting or removing from the device while they are on the device. This is different from encryption, which scrambles the contents of your files so that even if they are removed from the device, they will not be usable without the key to descramble them. The technique that we will discuss offers file protection, and does not offer encryption of files once they are removed from the device.
It is well known that certain utilities allow users to access content from an iOS device if the device is connected to the computer. These utilities expose the files on the device, sometimes mounting the device on the desktop, and other times providing a file tree interface that users can explore. In either case, unless content is somehow protected against prying eyes, the device is wide open to these utilities.
Fortunately, Apple provides a Data Protection layer called On-Disk Encryption that leverages the lock screen PIN to restrict access to content on a per-app basis. Under this scheme, all files that are associated with an app will be protected by this method. Note that I say “protected” and not “encrypted.” While the files will be encrypted while on the device, Apple’s method leverages encryption at the file system level, so that when the device is unlocked, the files are unlocked. The app (in our case, a DPS app) does not need to know anything about keys in order to use this encryption method. When your device is unlocked, your files are decrypted and available to your app and for browsing with a file utility. When your device is locked, the files are encrypted and unavailable to your app and for browsing with a file utility. So, while your app’s files will technically be encrypted, this is not the same as having an encrypted file, such as a PDF that would need a password to open in Adobe Reader. In that case, the file remains encrypted whether or not the device is locked, and you need to have the proper key to view the unscrambled contents.
With iOS, you can configure your app to use one of three levels of content protection. According to the iPhone App Programming Guide , pages 119-120, these are:
Consider the folowing example. You create a DPS multi-folio app with direct entitlement and publish it using Enterprise MDM. What, exactly, is in the app? There is an .ipa file, which consists of all of the code that runs on your device to display your folios, to talk to entitlement server, to localize the menu items, and to display your custom storefront. In addition, as folios are received by the app, they get stored in the app’s private file storage area on the device. The app, for our purposes, is a folder containing code and assets. This entire folder and its contents become encrypted when you enable Apple On-Disk Encryption. The files remain encrypted on the device at all times, but when the device is unlocked, the OS decrypts them “on the fly” so that they appear unlocked for all intents and purposes. This means that your code is accessible to run, and that the code can find and use all of the assets it needs while the device is unlocked. When the device is locked, then the code and assets are no longer readable, so your app will stop working. The good thing for us is that all apps are designed to do this with iOS. Your DPS app goes to sleep, so to speak, when you close your smart cover. There are a few services that are allowed to run while in sleep, such as geolocation, and your DPS app is not coded for native geolocation, even though it might use geolocation in a Web overlay for a map.
Since most DPS apps should do not require access to files while the device is locked, it seems reasonable to use the Complete method to protect your DPS app. Nevertheless, you should test each scheme to find the one that works for your configuration. For instance, if your app requires Newsstand Push, it will not be able to receive any content while the device is locked, even though it may be on wifi. As a result, do not use Content Protection with a Newsstand app. Also, if your app uses Content Protection, any background downloads will fail if you close the device during download, since the app can no longer access its own content when the device is closed. As this article is geared toward the Enterprise use case, we will proceed with how to enable Complete Protection.
To enable Content Protection, you need to create an App ID in the iOS Developer portal. This can be a “standard” iOS Developer Account (individual or team) or an Enterprise Developer Account. In the iOS Developer Center, choose Identifiers from the iOS options. If you are creating a new app, click the plus sign to add a new app.
For a new app, fill in the required information for a new app. Follow your company’s naming conventions and policies with respect to creating a new iOS app. In the App Services section, enable Data Protection.
Enable any other desired services, and then click Continue, then click Submit. Once completed, you can create a set of developer and distribution mobileprovision files for this new AppID. For more details on creating and using mobileprovision files for your DPS apps, please refer to the "Adobe DPS iOS Publishing Companion Guide".
If you are modifying an existing app, select it from the list and click the Settings button.
Once you have enabled Data Protection, click Done. You now need to download NEW developer and distribution mobileprovision files for this app, as the old mobileprovision files do not contain the Data Protection service request.
Once you have your new or rebuilt mobileprovision files, you can use App Builder to create a new app or update an existing app. In either case, use the new developer and distribution mobileprovision files for your app, and sign it appropriately. Download your new .ipa and .zip files from the App Builder, and you are ready to deploy. Submit your new App to your internal Mobile Device Management platform for distribution, or use iTunes Connect to submit it to iTunes. Regardless of whether it is a new or existing app in iTunes, you would need to submit the binary to Apple and go through app approval.
Using Apple’s On-Disk Encryption is an easy way for you to protect your DPS content so long as the device is locked. It does not protect your content if the device is unlocked, and it does not provide an app-specific key-based encryption for DPS content. So long as the device’s password remains unknown, the content is locked. For many customers, using Apple’s On-Disk Encryption plus Enterprise MDM app management provides a robust security layer for DPS apps.
Comments are currently closed as we migrate to a new commenting system. In the interim, please provide any feedback using our feedback form. Thank you for your patience.
Added note that Content Protection should not be used with a Newsstand app or an app that uses background downloads.
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. Permissions beyond the scope of this license, pertaining to the examples of code included within this work are available at Adobe.