This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
1. - Apple's enterprise features: Read more in this section
Explore other sections in this guide:
- 2. - Android isn't down for the count
- 3. - Windows mobile devices in the enterprise
- 4. - Glossary of mobile device management terms
Apple's data protection and built-in iOS encryption provide a powerful system for securing information, but only if those technologies are properly implemented.
If workers don't enable data protection on their devices, or if they use apps that don't utilize it, devices rely on basic iOS encryption to protect sensitive data, which only makes the devices easier to wipe. Making sure that users have data protection and associated settings enabled will help you take advantage of the robust encryption that Apple's system provides.
When Apple released iOS 4, the company added an important new feature: Data protection, an architectural enhancement that beefs up iOS encryption on devices. It works in conjunction with the encryption mechanisms built into devices' hardware and firmware to protect data better. In iOS 5, Apple enhanced data protection to provide more flexibility for file access even if a device is locked, without putting data at risk.
Built-in iOS encryption
Since the release of the iPhone 3GS, Apple has built encryption into the hardware and firmware of its iPads and iPhones. Every iOS device now has a dedicated Advanced Encryption Standard (AES) 256-bit crypto engine that sits between the flash storage and main system memory. The engine works in conjunction with the SHA-1 cryptographic hash function – which is implemented in the hardware as well -- to reduce overhead for cryptographic operations.
More on iOS encyption
Mobile data encryption techniques
Apple seeks to better iPad, iPhone security
An iPad administrator's best friend: Configuration profiles
Also built into the device's hardware is the unique identifier (UID), an AES 256-bit key fused into the application processor. The UID is specific to the device and is not recorded anywhere else. No software or firmware can read it directly. They can see only the results of the encryption and decryption operations. Plus, because the key is burnt into the silicon, it cannot be tampered with or bypassed. Only the crypto engine can access it. As a result, data is cryptographically tied to a specific device and cannot be related to any other identifier or device.
Building encryption into the physical architecture makes it easier to encrypt all data stored on an iOS device. In fact, Apple enables this level of encryption by default and does not permit it to be disabled. But such iOS encryption provides little in the way of real protection, other than to facilitate a fast, secure wipe of the system. This is an important feature, especially if a device is lost or stolen and remote wipe has been configured beforehand. Under such circumstances, a device's data can theoretically be erased before someone can hack or jailbreak it. But if a device can't be wiped quickly enough, a hacker can crack the security and get at sensitive data.
Enabling iOS data protection
That's where iOS data protection comes in. Data protection is implemented at the software level and works with the hardware and firmware encryption to provide a greater degree of security.
When data protection is enabled, each data file is associated with a specific class that supports a different level of accessibility and protects data based on when it needs to be accessed. The encryption and decryption operations associated with each class are based on a complex key hierarchy that utilizes the device's UID and passcode, plus a class key, file system key and per-file key. The per-file key is used to encrypt the file content. The class key is wrapped around the per-file key and stored in the file's metadata. The file system key is used to encrypt the metadata. The UID and passcode protect the class key.
Fortunately, this operation is invisible to users. They access their apps as they always have. The important thing to take from this is not the specifics of how the encryption-related mechanisms work together (unless you're a developer), but that for a device to utilize data protection, a passcode must be used when accessing that device. The passcode not only unlocks the device, but also becomes inextricably enmeshed with the UID to create iOS encryption keys that are more resistant to hacking efforts and brute-force attacks. In fact, users need to enable passcodes on their devices to enable data protection.
Protecting data in iOS
If you support iOS devices in your organization, your policies should direct workers to use passcodes to help protect sensitive data. But remember that not all passcodes are created equal. On an iOS device, passcodes come in two types: the simple, four-digit, numerical passcode and the more complex alphanumeric passcode, which is normally much greater in length. Not surprisingly, the more complex the alphanumeric passcode, the better.
For example, according to Apple documentation, a brute-force attack on a device that uses a nine-digit numerical passcode will take 2.5 years to try all possible combinations, in part because iOS enforces escalating time delays to help discourage such attacks. On the other hand, a six-character passcode that mixes numbers and lowercase letters will take 5.5 years. As you would expect, a four-digit numerical passcode should take no time at all. Of course, if users set their devices to be automatically wiped after 10 failed attempts, the number of tries is not an issue (unless the passcode can be discovered within those 10 attempts). Even if a hacker were able to jailbreak a device and bypass the passcode, the data would still be inaccessible because the hacker would not know the passcode.
Yet passcodes are not the only consideration if you want to take full advantage of iOS data protection. An app must be designed to use the data protection application program interfaces to ensure that data is protected when it's accessed by the application. The app must also ensure that data can't be moved to apps that don't use data protection. In other words, an unsecure app should not be able to access the data in a secure app. Keep in mind that, even if an application is designed to protect all its data, it can run up against limitations out of its control. For example, data protection can't be used on files that participate in iCloud storage.
With the release of iOS 6, users have a bit more control over apps being able to access secure data in other apps. Although the encryption mechanisms themselves did not change in iOS 6, the operating system now requires a user's permission before a newly installed app can access private data, such as calendars, reminders and contacts. Users can now also modify data access for certain application in the device's settings (under Privacy).
The key to taking full advantage of iOS encryption resides not only in enforcing passcode policies, but also in maintaining complete control of the apps implemented on iOS devices, or at least those apps that deal with your organization's sensitive data. Anything less can amount to practically no protection at all.