Projects at my work usually require data encryption. Therefore I faced multiple times with question like “how safe is built-in iOS encryption?”. I had those concerns about Jailbreak, passcode, setting a proper protection class etc. I managed to do some research and decided to share my conclusions based on Apple’s document iOS Security for iOS 11. This is just a short overview of data protection to give you a general idea.
All below is based on knowledge coming from the document and my personal interpretation. Therefore before applying this to your solution, please read the document carefully.
Files are always encrypted on flash memory (local storage)
First of all, files on local storage are never decrypted (even without any additional protection set).
If a file isn’t assigned a Data Protection class, it is still
stored in encrypted form (as is all data on an iOS device).
However, by enabling Data Protection we get one more level of security which generates an encryption key for each protected file. No matter which protection class we pick, the file will remain encrypted all the time on local storage.
How it works that we get decrypted data within the application?
Every iOS device has a dedicated AES-256 crypto engine built into the
DMA path between the flash storage and main system memory, making
file encryption highly efficient.
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, then supplied to the hardware AES engine, which decrypts the file
as it is read from flash memory. All wrapped file key handling occurs
in the Secure Enclave; the file key is never directly exposed to the
application processor.
Therefore, all decryption happens on the fly and files are still protected on flash memory.
NSFileProtectionCompleteUntilFirstUserAuthentication
I’m not going to go into details for each protection class, however I would like to clarify this one. As I mentioned above, files are protected all the time, so what happens if we use class NSFileProtectionCompleteUntilFirstUserAuthentication? The answer is here:
The class key is protected with a key derived from the user passcode and the device UID. 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.
Only our application can access the file, but the job is done here by Crypto Engine which has access to our File Key in memory (even if the device is locked) and decrypts data from flash memory to system memory.
Hardware security
It’s worth to mention that hardware is also protected and even if you move flash storage to another device, it won’t be possible to get its data.
The UID allows data to be cryptographically tied to a particular device.
For example, the key hierarchy protecting the file system includes the
UID, so if the memory chips are physically moved from one device to
another, the files are inaccessible. The UID isn’t related to any other
identifier on the device.
Jailbreak concerns
Fortunately if we assume that hacker won’t get unlocked iPhone, Jailbreak is not possible from the lock screen.
Data Protection mechanism uses passcode and hardware key to decrypt files, therefore hacker would have to crack your passcode to get data which is also protected by counting of attemps.
Background mode
For applications which use background mode NSFileProtectionCompleteUntilFirstUserAuthentication should be enough. Apple mentiones that in section related with KeyChain access (which is quite similar):
Apps that utilize background refresh services can use
kSecAttrAccessibleAfterFirstUnlock for Keychain items that need to
be accessed during background updates.
