Full Disk Encryption (FDE) systems (like Truecrypt, BitLocker and FileVault) encrypt disks at the level of disk sectors. This is an all-or-nothing approach, since the encryption drivers won’t necessarily have any idea what files those sectors represent. At the same time, FDE is popular — mainly because it’s extremely easy to implement. While this could be excellent for PCs, for phones another approach may be necessary as I will explain below.
File-based Encryption (FBE) systems (like EncFS and eCryptFS) encrypt individual files. This approach requires changes to the filesystem itself, but has the benefit of allowing fine grained access controls where individual files are encrypted using different keys.
The main problem with smartphone is that users are never encouraged to shut down their device. In practice this means that — after you enter a password once after boot — normal users spend their whole day storing all their cryptographic keys in RAM. Since phone batteries live for a day or more (a long time compared to laptops) encryption doesn’t really offer much to protect you against an attacker who gets their hands on your phone during this time.
Of course, users do lock their smartphones. In principle, a clever implementation could evict sensitive cryptographic keys from RAM when the device locks, then re-derive them the next time the user logs in. Unfortunately, Android doesn’t do this — for the very simple reason that Android users want their phones to actually work. Without cryptographic keys in RAM, an FDE system loses access to everything on the storage drive. In practice this turns it into a brick.
For this very excellent reason, once you boot an Android FDE phone it will never evict its cryptographic keys from RAM. And this is clearly not good.
Starting with iOS 4, Apple included a “data protection” feature to encrypt all data stored a device. But unlike Android, Apple doesn’t use the full-disk encryption paradigm. Instead, they employ a file-based encryption approach that individually encrypts each file on the device.
In the Apple system, the contents of each file is encrypted under a unique per-file key (metadata is encrypted separately). The file key is in turn encrypted with one of several “class keys” that are derived from the user password and some hardware secrets embedded in the processor.
In order to secure things regarding keys, some security special measures have been implemented. If the high security protection class is used, files encrypted with this class key can only be accessed when the device is powered up and unlocked. To ensure this, the class key is evicted from RAM a few seconds after the device locks. This is desirable. In the case of medium security option, the encrypted files are protected until the user first logs in (after a reboot), and the key remains in memory. On low security, the files are accessible even when the device has been rebooted, and the user has not yet logged in.
As conclusion, for mobile phones, there is a relatively safe FBE option and it's up to the user to actually use it.
Read a little more about it here.
