Saktanong - stock.adobe.com
Intro to iPhone encryption features for Apple admins
Encryption for iOS devices comes baked into the device itself, but iOS devices also have some significant enterprise-level protections that IT must enable and deploy policies for.
Mobile devices can access sensitive internal documents and other files through company apps or portals, so IT professionals should understand how mobile device encryption can protect this data from hacking attempts.
There are two categories that make up Apple iPhone encryption: hardware-level and file-level. Apple automatically enables hardware-level encryption out of the box for its mobile devices, and this encryption protects the devices' core processes from direct access by any software or firmware. Because of this default, there is nothing for IT to configure and no way for users to disable it.
File-level encryption requires a bit more management and decision-making from IT, but mobile admins should know both types of iPhone encryption to properly manage their users.
Out of box hardware-level encryption for iOS devices
Each iOS device includes a dedicated Advanced Encryption Standard (AES 256) cryptography engine to support hardware-level iPhone encryption, and it sits between the system memory and flash storage. This engine works in conjunction with the device's unique identifier (UID) to segregate system operations and cryptographically tie data to the device. The UID is an AES 256-bit encryption key fused into the application processor and Secure Enclave during manufacturing.
Software that runs on the Secure Enclave, a coprocessor security chip, uses the UID to protect sensitive device information. The Secure Enclave also processes fingerprint and face data associated with Touch ID and Face ID. In addition, the Secure Enclave carries out all cryptographic operations related to file-level encryption. Communication between the Secure Enclave and application processor is isolated and highly controlled.
There is much more to hardware-level encryption, but the important point that mobile admins should understand is that an iOS device automatically uses advanced cryptographic techniques to protect core system functions. These hardware-level security capabilities also provide a foundation for file-level data security, a feature known as data protection.
Key points of file-level encryption
The data protection feature on iOS devices encrypts data on the device's flash drive by assigning a new 256-bit key to each file when a user or IT pro creates it. On iOS devices that support the Apple File System (APFS), IT can assign keys on a per-extent basis, in which different parts of a single file receive different keys.
The data protection feature wraps each file key in one of several key classes that determine data accessibility; the app that creates the specified file assigns it a class. For example, IT can deploy a policy for an app that encrypts all files of a certain format to the "Protected Until First User Authentication" class, which is the default class for all third-party apps on iOS. IT configures each class on encryption with a specific set of policies that define the files' accessibility. The Security Enclave handles all wrapped file keys and extent keys so they are never directly exposed to the app.
Data protection ensures that each file on the device's flash drive is encrypted. Unlike hardware-level iPhone encryption, however, data protection is not enabled out of the box. To deploy these file-level encryption policies, IT must enable the passcode feature on the desired iOS devices.
Encryption relies on passcodes
Passcodes and the data protection feature are inextricably tied in iOS because a user's passcode is linked with the device's UID. An attacker cannot access data in the protected classes without the passcode, which is why organizations should always require passcodes on their managed iOS devices.
Passcodes not only ensure that file data is encrypted; they also protect against brute-force attacks by escalating the time delays after each consecutive failed passcode attempt. For example, the time delay is one minute after five failed attempts, but after nine failed attempts, the delay is one hour. In addition, IT can configure its devices to automatically wipe the data after 10 failed attempts.
IT can manage a device's passcode settings and requirements through a mobile device management or enterprise mobility management tool such as VMware AirWatch or MobileIron. With these tools, IT can specify whether or not a passcode is required, the complexity of that passcode and several other settings. The more complex a user's passcode is, the stronger the file-level encryption -- though the more difficult it is for the user to enter. However, if the managed devices support Touch ID or Face ID, IT can require a much more complex passcode because users don't have to supply it as frequently.