macOS Sonoma 14.4 and 14.4.1 updates prompted some to use a new Recovery Key for FileVault, making us wonder how secure its keys are. In addition, recent publicity given to the GoFetch vulnerability in Apple silicon chips has raised concerns that FileVault’s encryption could be broken. This article explains how FileVault works, with respect to its encryption keys and passwords, and considers whether its protection is any weaker.

Standard encryption

As far as FileVault encryption is concerned, there are two types of Mac: Intel models without a T2 chip perform software encryption, while those with T2 or Apple silicon chips do it in hardware, so long as the volume(s) being encrypted are on its internal SSD. All FileVault encryption performed on external storage is run in software, because of the way that hardware encryption is implemented.

The internal SSD in T2 and Apple silicon Macs is connected directly to its Secure Enclave, which performs its encryption and decryption using keys generated and stored within the Secure Enclave. Keys and processes involved are shown in the diagram below, which is loosely based on that given in the Apple Platform Security Guide.

All volumes on the internal SSD that are encrypted have a Volume Encryption Key (VEK), protected by two internal keys, one the unique hardware UID from the Secure Enclave, the other from xART and intended to protect from replay attacks. The VEK isn’t exposed outside the Secure Enclave, nor is it handled by CPU cores.

FileVault enabled

When a user enables FileVault, a third key becomes involved in protecting the VEK, the Key Encryption Key (KEK), protected by the User Password and the hardware UID. This explains how no decryption and re-encryption is required when changing the User Password, or when enabling or disabling FileVault. Changes to the KEK affect access to the VEK, but don’t change the VEK at all.

When FileVault is turned on, the User Password is handled by the CPU cores, but neither the KEK nor VEK generated inside the Secure Enclave are exposed to the CPU cores or the rest of the chip.

Recovery

Apple doesn’t provide details of how recovery is performed, but the user is given two options: either they take custody of a Recovery Key provided at the time that FileVault is turned on, or they have the process performed through their iCloud account, protected by their Apple ID and password. These are mutually exclusive, and the user can’t opt for both.

In both cases, recovery must enable the Secure Enclave to generate the KEK so that the VEK can be unwrapped and used for encryption and decryption. The only way to validate a Recovery Key is using the fdesetup validaterecovery command, which is also presumably handled inside the Secure Enclave. There is no means of validating iCloud recovery, other than by trying it in practice, which isn’t recommended unless you have good reason to do so.

As Recovery Keys contain six blocks of four characters, each a capital letter or digit, guessing is out of the question even if the Secure Enclave were to tolerate an unlimited number of attempts.

GoFetch vulnerability

Throughout their accounts of this recently discovered vulnerability in Apple silicon chips, its authors have emphasised how this depends on encryption and decryption taking place on the Performance cores of M-series chips, and have pointed out that the data memory-dependent prefetchers required aren’t used by Efficiency cores. Their paper doesn’t mention the Secure Enclave Processor (SEP), only encryption being performed on CPU cores, not in the Secure Enclave by the SEP.

There is thus no evidence that FileVault encryption or decryption, which is performed in hardware in any case, is vulnerable to GoFetch.

Software encryption

FileVault, when enabled on external storage in all Macs, or on all storage in Intel Macs without a T2 chip, cannot use Secure Enclave encryption hardware, and therefore relies on software encryption performed outside the Secure Enclave. This is also true for APFS encrypted volumes. When that encryption is performed, that would take place on either P or E cores in the CPU; in the former, it could thus be vulnerable to GoFetch, were it to be used in an effective exploit.

Summary

• Macs with a T2 or Apple silicon chip perform FileVault encryption on volumes on their internal SSDs in their Secure Enclave.
• All encryption on external storage, and that on internal storage of Intel Macs without a T2 chip, is performed in software, and not by the hardware of the Secure Enclave.
• In T2 and Apple silicon Macs, turning FileVault on provides additional protection for its encryption key (VEK), but doesn’t change that key.
• All keys used in FileVault for internal SSDs of T2 and Apple silicon Macs are fully protected within the Secure Enclave.
• They can be recovered either by using a Recovery Key provided to the user, or via iCloud, but not by both.
• Software encryption, including FileVault, for external storage of Apple silicon Macs may be vulnerable to GoFetch, but there’s no evidence that could affect FileVault encryption performed in the Secure Enclave.
• For T2 and Apple silicon Macs, FileVault is most secure on internal SSDs.