How keys are used in FileVault and encryption
We rely on FileVault and APFS to protect our secrets by encrypting the volumes containing our documents and data. How they do that is a mystery to many, and raises important questions such as the role our passwords play, and how recovery keys work. This article attempts to demystify them.
Naïve encryption
A simple scheme to encrypt a disk or volume might be to take the user password, somehow turn it into a key suitable for the encryption method to be used, and employ that to encrypt and decrypt the data as it’s transferred between disk storage and memory.
There are lots of weaknesses and difficulties with that. Even using a ‘robust’ user password, it’s not going to be memorable, sufficiently long or hard to crack, and there’s no scope for recovery if that password is lost or forgotten.
FileVault base encryption
In Macs with T2 or Apple silicon chips when FileVault is disabled, everything in the Data volume stored on their internal SSD is still encrypted, but without any user password. This is performed in the Secure Enclave, which both handles the keys and performs the encryption/decryption. That ensures the keys used never leave the Secure Enclave, so are as well-protected as possible.
Generating the key used to encrypt the volume, the Volume Encryption Key or VEK, requires two huge numbers, a hardware key unique to that Mac, and the xART key generated by the Secure Enclave as a random number. The former ties the encryption to that Mac, and the latter ensures that an intruder can’t repeat generation of the same VEK even if it does know the hardware key. When you use Erase All Content and Settings (EACAS), the VEK is securely erased, rendering the encrypted data inaccessible, and there’s no means to either recover or recreate it.
This scheme lets the Mac automatically unlock decryption, but doesn’t put that in the control of the user, who therefore needs to enable FileVault to get full protection.
FileVault full encryption
Rather than trying to incorporate a user password or other key into the VEK, like many other encryption systems FileVault does this by encrypting the VEK using a Key Encryption Key or KEK, a process known as wrapping.
When you enter your FileVault password, that’s passed to the Secure Enclave, where it’s combined with the hardware key to generate the KEK, and that’s then used together with hardware and xART keys to decrypt or unwrap the VEK used for decryption/encryption.
This has several important benefits. As the KEK can be changed without producing a new VEK, the user password can be changed without the contents of the protected volume having to be fully decrypted and encrypted again. It’s also possible to generate multiple KEKs to support the use of recovery keys that can be used to unlock the VEK when the user’s password is lost or forgotten. Institutional keys can be created to unlock multiple KEKs and VEKs where an organisation might need access to protected storage in multiple Macs.
APFS encryption
True FileVault requires all keys to be stored in the Secure Enclave, and never released outside it. Intel Macs without T2 chips, and other protected volumes such as those on external storage can’t use that, and in the case of removable storage need an alternative that stays on the disk. For that, APFS uses the AES Key Wrap Specification in RFC 3394, using a secret such as a password to maintain confidentiality of every key.
APFS also uses separate VEKs and KEKs, so enabling the use of multiple KEKs for a single VEK, and the potential to change a KEK without having to decrypt and re-encrypt the whole volume, as in FileVault. In APFS, VEKs and KEKs are stored in and accessed from Keybags associated with both containers and volumes. The Container Keybag contains wrapped VEKs for each encrypted volume within that container, together with the location of each encrypted volume’s keybag. The Volume Keybag contains one or more wrapped KEKs for that volume, and an optional passphrase hint. These are shown in the diagram below.
Apple’s documentation refers to several secrets that can be used to wrap a KEK, including a user password, an individual recovery key, an institutional recovery key, and an unspecified mechanism implemented through iCloud. Currently, for normal software encryption in APFS, only two of those appear accessible: a user password is supported in both Disk Utility and diskutil
‘s apfs
verb, while diskutil
also supports use of an institutional recovery key through its -recoverykeychain
options. Individual and iCloud recovery keys only appear available when using FileVault, in this case implemented in software, either on Intel Macs without a T2 chip, or on all Macs when encrypting an external volume.
Because keybags are stored on the disk containing the encrypted volume, if the disk is connected to another Mac, when macOS tries to mount that volume, the user will be prompted to enter its password, and can then gain access to its contents. When FileVault is used to protect a Data volume on the internal SSD of a T2 or Apple silicon Mac, that volume can only be unlocked through the Secure Enclave of that Mac, and it isn’t possible to unlock it from another Mac (that’s also true when FileVault hasn’t been enabled on that volume).