Data Flow on iOS
Continuing our series on iOS data security, we need to take some time to understand how data moves onto and around iOS devices before delving into security and management options.
Data on iOS devices falls into one of a few categories, each with different data protection properties. For this discussion we assume that Data Protection is enabled, because otherwise iOS provides no real data security.
- Emails and email attachments.
- Calendars, contacts, and other non-email user information.
- Application data
When the iOS Mail app downloads mail, message contents and attachments are stored securely and encrypted using Data Protection (under the user’s passphrase). If the user doesn’t set a passcode, the data is stored along with all the rest of user data, and only encrypted with the device key. Reports from forensics firms indicate that Data Protection on an iPad 2 or iPhone 4S (or later, we presume) running iOS 5 cannot currently be cracked, by other than brute force. Data Protection on earlier devices can be cracked.
Assuming the user properly uses Data Protection, mail attachments viewed with the built-in viewer app are also safe. But once a user uses “Open In…”, the document/file is moved into the target application’s storage sandbox, and may thus be exposed. When a user downloads an email and an attachment, and views them in the Mail app, both are encrypted twice (once by the underlying FDE and once by Dat Protection). But when the user opens the document with Pages to edit it, a copy stored in the Pages store, which does not use Data Protection – and the data can be exposed.
This workflow is specific to email – calendars, contacts, photos, and other system-accessible user information is not similarly protected, and is generally recoverable by a reasonably sophisticated attacker who has physical possession of the device. Data in these apps is also available system-wide to any application. It is a special class of iOS data using a shared store, unlike third-party app data.
Other (third party) application data may or may not utilize Data Protection – this is up to the app developer – and is always sandboxed in the application’s private store. Data in each application’s local store is encrypted with the user’s passcode. This data may include whatever the programmer chooses – which means some data may be exposed, although documents are nearly always protected when Data Protection is enabled. The programmer can also restrict what other apps a given document is allowed to open in, although this is generally an all or nothing affair. If Data Protection isn’t enabled, all data is protected only with the device’s default hardware encryption. But sandboxing stil prevents apps from accessing each other’s data.
The only exception is files stored in a shared service like Dropbox. Apps which access dropbox still store their local copies in their own private document stores, but other apps can access the same data from the online service to retrieve their own (private) copies.
So application data (files) may be exposed despite Data Protection if the app supports “Open In…”. Otherwise data in applications is well protected. If a network storage service is used, the data is still protected and isolated within the app, but becomes accessible to other compatible apps once it is stored on a server. This isn’t really a fault of iOS, but this possibility needs to be considered when looking at the big picture. Especially if a document is opened in a Data Protection enabled app (where it’s secure), but then saved to a storage service that allows insecure apps to access it and store unencrypted copies.
Thus iOS provides both protected and unprotected data flows. A protected data flow places content in a Data Protection encrypted container and only allows it to move to other encrypted containers (apps). An unprotected flow allows data to move into unencrypted apps. Some kinds of data (iOS system calendars, contacts, photos, etc.) cannot be protected and are always exposed.
On top of this, some apps use their own internal encryption, which isn’t tied to the device hardware or the user’s passcode. Depending on implementation, this could be more or less secure than using the Data Protection APIs.
The key, from a security perspective, is to understand how enterprise data moves onto the device (what app pulls it in), whether that app uses Data Protection or some other form of encryption, and what other apps that data can move into. If the data ever moves into an app that doesn’t encrypt, it is exposed.
I can already see I will need some diagrams for the paper! But no time for that now – I need to get to work on the next post, where we start digging into data security options…