> Android has included full disk encryption (FDE) support since version 3.0, but versions prior to 4.4 used a fairly easy to bruteforce key derivation function (PBKDF2 with 2000 iterations). Additionally, because the disk encryption password is the same as the lockscreen one, most users tend to use simple PINs or passwords (unless a device administrator enforces password complexity rules), which further facilitates bruteforcing. Android 4.4 replaced the disk encryption KDF with scrypt, which is much harder to crack and cannot be implemented efficiently on off-the-shelf GPU hardware. In addition to enabling FDE out of the box, Android L is expected to include hardware protection for disk encryption keys, as well as hardware acceleration for encrypted disk access. These two features should make FDE on Android both more secure and much faster.

In iOS, encryption is not performed at the block layer but at the filesystem level, and some files are encrypted with hardware-derived keys (thanks to a unique 256-bit AES key burned into the processor), allowing the OS to be booted normally, but not having access to certain files until the user enters his/her passcode (full details here [2]). Even if you don't immediately enter the passcode after boot, the phone is still in a somewhat functional state.

I'm glad that Android is taking steps to at least implement by-default disk encryption by relying on a hardware-backed key store.

[1] https://source.android.com/devices/tech/encryption/android_c...

[2] https://www.apple.com/privacy/docs/iOS_Security_Guide_Sept_2...

But that's a big ask not just for the obvious reason, but also because the Nexus 5 is the first phone I've ever owned which demands that I unlock it first before I can access the UI to cancel an alarm.

And even then, it's a game of chance (especially when the phone is upside down while you're asleep) whether your swipe is in the correct direction (apparently UI designs actually removed the visual cues which would normally guide the user toward the correct action).

Not fully correct. In iOS8, the scope of DP (data protection) was enhanced to cover additional data with specific respect to the builtin Apple applications (SMS, photos, call logs, etc.). DP, since its introduction in iOS4, has always used the user's passcode as part of the encryption secret, and there are APIs available to create files and/or keychain items with data protection on.

Notice that there is an interaction between the multitasking/background system and data protection, as applications running background services will need access to a (part of) filesystem and (part of) keychain to operate. This is why the APIs have a very granular set of ACLs.

With Android-L moving key material to trusted execution environments, expect interesting attacks on those. I am curious about state-mandated security holes in TEEs as well, since it's much easier to hide backdoors in chips than in publically reviewable software (I would much prefer to see a dedicated security processor than a "secure mode" of what is essentially the whole SOC).

At least CM11 allows a dedicated FDE password though - Google is really doing its users a disservice by not implementing this in stock Android.

They have _very_ different security properties. Offline brute forcing the unlock passcode is far harder (presumably it's stored in the encrypted fs), so a shorter code is fine. Offline brute forcing of the encryption key passphrase is much easier (as TFA explains), but I'm never going to use a 'good' passphrase there, as it would be far too annoying to have to type it every time I unlock the phone...

Do you mean a firing alarm, or a pending alarm? One can cancel a firing alarm just by swiping, no passcode needed.

I would prefer to have to enter my code in order to cancel a pending alarm. Otherwise I can imagine practical jokers cancelling an alarm if they have the chance.