How data files are created and protected
On devices with an A7, S2, or S3 SoC, AES-CBC is used. The initialization vector is calculated with the block offset into the file, encrypted with the SHA-1 hash of the per-file key.
The per-file (or per-extent) key is wrapped with one of several class keys, depending on the circumstances under which the file should be accessible. Like all other wrappings that use RFC 3394, this is performed using NIST AES key wrapping. The wrapped per-file key is stored in the file’s metadata.
Devices with APFS format may support cloning of files (zero-cost copies using copy-on-write technology). If a file is cloned, each half of the clone gets a new key to accept incoming writes so that new data is written to the media with a new key. Over time, the file may become composed of various extents (or fragments), each mapping to different keys. However, all of the extents that comprise a file are guarded by the same class key.
When a file is opened, its metadata is decrypted with the file system key, revealing the wrapped per-file key and a notation on which class protects it. The per-file (or per-extent) key is unwrapped with the class key and then supplied to the hardware AES engine, which decrypts the file as it’s read from flash storage. All wrapped file key handling occurs in the Secure Enclave; the file key is never directly exposed to the Intel CPU. At boot time, the Secure Enclave negotiates an ephemeral key with the AES engine. When the Secure Enclave unwraps a file’s keys, they are rewrapped with the ephemeral key and sent back to the application processor.
The metadata of all files in the data volume file system are encrypted with a random volume key, which is created when iOS and iPadOS are first installed or when the device is wiped by a user. This key is encrypted and wrapped by a key wrapping key that is known only to the Secure Enclave for long term storage. The key wrapping key changes every time a user erases their device. On A9 (and newer) SoCs, Secure Enclave relies upon entropy, backed by anti-replay nonce, to achieve effaceability and to protect its key wrapping key, among other assets.
Just like per-file or per-extent keys, the metadata key of the data volume is never directly exposed to the application processor; the Secure Enclave provides an ephemeral, per-boot version instead. When stored, the encrypted file system key is additionally wrapped by an “effaceable key” stored in Effaceable Storage. This key doesn’t provide additional confidentiality of data. Instead, it’s designed to be quickly erased on demand (by the user with the “Erase All Content and Settings” option, or by a user or administrator issuing a remote wipe command from a mobile device management (MDM) solution, Microsoft Exchange ActiveSync, or iCloud). Erasing the key in this manner renders all files cryptographically inaccessible.
The contents of a file may be encrypted with one or more per-file (or per-extent) keys that are wrapped with a class key and stored in a file’s metadata, which in turn is encrypted with the file system key. The class key is protected with the hardware UID and, for some classes, the user’s passcode. This hierarchy provides both flexibility and performance. For example, changing a file’s class only requires rewrapping its per-file key, and a change of passcode just rewraps the class key.