Data Protection classes
When a new file is created on devices supporting Data Protection, it’s assigned a class by the app that creates it. Each class uses different policies to determine when the data is accessible. The basic classes and policies are described in the following sections. Apple silicon–based Mac computers don’t support Class D: No Protection, and a security boundary is established around logging in and out (not locking or unlocking as on iPhone and iPad).
Class | Protection type |
|---|---|
Class A: Complete Protection | NSFileProtectionComplete |
Class B: Protected Unless Open | NSFileProtectionCompleteUnlessOpen |
Class C: Protected Until First User Authentication Note: macOS uses a volume key to recreate FileVault protection characteristics. | NSFileProtectionCompleteUntilFirstUserAuthentication |
Class D: No Protection Note: Not supported in macOS. | NSFileProtectionNone |
Complete Protection
NSFileProtectionComplete: The class key is protected with a key derived from the user passcode or password and the device UID. Shortly after the user locks a device (10 seconds, if the Require Password setting is Immediately), the decrypted class key is discarded, rendering all data in this class inaccessible until the user enters the passcode again or unlocks (logs in to) the device using Face ID or Touch ID.
In macOS, shortly after the last user is logged out, the decrypted class key is discarded, rendering all data in this class inaccessible until a user enters the passcode again or logs in to the device using Touch ID.
Protected Unless Open
NSFileProtectionCompleteUnlessOpen: Some files may need to be written while the device is locked or the user is logged out. A good example of this is a mail attachment downloading in the background. This behaviour is achieved by using asymmetric elliptic curve cryptography (ECDH over Curve25519). The usual per-file key is protected by a key derived using One-Pass Diffie-Hellman Key Agreement as described in NIST SP 800-56A.
The ephemeral public key for the Agreement is stored alongside the wrapped per-file key. The KDF is Concatenation Key Derivation Function (Approved Alternative 1) as described in 5.8.1 of NIST SP 800-56A. AlgorithmID is omitted. PartyUInfo and PartyVInfo are the ephemeral and static public keys, respectively. SHA256 is used as the hashing function. As soon as the file is closed, the per-file key is wiped from memory. To open the file again, the shared secret is re-created using the Protected Unless Open class’s private key and the file’s ephemeral public key, which are used to unwrap the per-file key that is then used to decrypt the file.
In macOS, the private part of NSFileProtectionCompleteUnlessOpen is accessible as long as any users on the system are logged in or are authenticated.
Protected Until First User Authentication
NSFileProtectionCompleteUntilFirstUserAuthentication: This class behaves in the same way as Complete Protection, except that the decrypted class key isn’t removed from memory when the device is locked or the user logged out. The protection in this class has similar properties to desktop full-volume encryption and protects data from attacks that involve a reboot. This is the default class for all third-party app data not otherwise assigned to a Data Protection class.
In macOS, this class utilises a volume key that is accessible as long as the volume is mounted, and acts just like FileVault.
No Protection
NSFileProtectionNone: This class key is protected only with the UID and is kept in Effaceable Storage. Since all the keys needed to decrypt files in this class are stored on the device, the encryption only affords the benefit of fast remote wipe. If a file isn’t assigned a Data Protection class, it is still stored in encrypted form (as is all data on an iOS and iPadOS device).
This isn’t supported in macOS.
Note: In macOS, for volumes that don’t correspond to a booted operating system, all data protection classes are accessible as long as the volume is mounted. The default data protection class is NSFileProtectionCompleteUntilFirstUserAuthentication. Per-extent key functionality is available to both Rosetta 2 and native apps.