Hector Martin

I understand the trade-offs Apple is making with their more complex security implementation (and Android is moving in that direction with file-based crypto) but I'd rather have a much simpler to analyze FDE approach.

The problem with FDE iirc was that for the phone to operate, keys must be in memory (so that binaries can be decrypted). The file based approach allow cleartext keys for non-essential files to be wiped from memory when the device is locked and to be encrypted with the passcode*

The OS is not encrypted, so the phone can boot and you can make emergency calls. However, to unlock the data partition (and thus boot the rest of the Android framework including all your user data) you need to type in your passphrase. This is a trade-off I'm willing to make.

Sure, but the key of the data partition is still in memory once you typed your passphrase at boot, right?

Yes. Ideally you'd want *both* schemes at once, but Google seems to think they can get fine grained data partitioning right (they can't) and thus forgo proper passphrase-controlled FDE when they use file-based encryption instead.

The reason why I prefer FDE is that runtime attacks are much more fragile - one misstep by the attacker and they're locked out, and the attack surface is smaller (physical attacks are very impractical if you can't shut the phone down); you have to get in through background SW.

Don't know about Android's security model but can't really see a significant upside vs using the passphrase as a passcode and relying on biometrics not to have to type it too often. I guess different security models?

The upside is it's FDE, which means *all* user data is encrypted. Both iOS and Android in FBE mode expose some user data not bound to a passphrase, and then you have to trust that *every single app developer* got it right and isn't accidentally leaking important secrets.