Does File-Based Encryption offer comparable security to Full-Disk Encryption on Android?
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.
Yes, File-Based Encryption offers a good security and as everything it got also some advantages and disadvantages. But let's start at the beginning. What is the main difference between this two methods?
File-Based Encryption
At a File-Based Encryption only Files are encrypted with different keys. So say every file got his own "password". There are two types of storage within this type of encryption:
- Credential Encrypted Storage: Which is only available if the user enters his credentials
- Device Encrypted Storage: Which is available before and after the boot. That's the space where the alarm and similar things are saved that you mentioned. This are accessible with Direct boot.
This two storage types offers some benefits:
- No storage allocation necessary
- Small changes on the storage if you change one file (So you don't need to change a whole container just a file)
- Fine grained access rights are possible
But also some drawbacks:
- Metadata isn't fully encrypted
- Data is dependent on the filesystem used
Full-Disk Encryption
At this type of encryption you encrypt a whole space. So you can unlock it just by using the right key. But also this got some advantages which I need to mention:
- Metadata is fully encrypted
- The content in this container could be random and don't need to fit the used filesystem
- Integration into the Operating System may get you some performance benefits
- You are not able to "forget" a file. If it's inside this container it's encrypted
But also at this encryption you got some disadvantages:
- You cannot use any program before a boot (like alarms or some similar things) (Only if it's inside the encrypted place)
- If you change one file you change the whole container
- You need to allocate the whole space
Summary
So as you can see both types of encryption offers some advantages and disadvantages. I would say the best improvement at File-Based Encryption will be that you are able to encrypt every file with a different key. So some can remain encrypted and whilst others are decrypted and in use. This will be a benefit for the usability and also security. The biggest drawback I can see will be that metadata isn't fully encrypted. This could be security problem because some metadata give very much information about a file.
Note: At Android 9 they also introduced Metadata encryption which cuts the drawback out. So after this version I cannot really see any drawbacks regarding security anymore.
In the end you need to think about it on your own and go through the arguments of this encryptions.