it will be finished ...
... Real Soon Now.
Looking at the storage encryption Google has implemented in Android Nougat (7.0) through the metaphor of the glass that's either half full or half empty, cryptography expert Matthew Green sees Google's glass as all but drained. In a blog post last week, Green, assistant professor of computer science at Johns Hopkins University …
The underlying OS has had encryption for ages.
Ecryptfs just works (TM). The only thing needed is for Google to port/integrate the utilities into Android. That is not rocket science.
If you integrate it into the android security model you also can do some extremely nifty things like "encrypt storage per application", etc.
The only problem I see with it is that it is fairly well written and not that easy to backdoor. So probably "Do No Evil" is the issue here.
Google's problem is not the encryption per se but the ability to discard most encryption keys from memory when the phone is locked, while still keeping a working system (including background applications, notifications and so on).
Full disk encryption is easy but somewhat insecure: in order to keep a working system the (single) encryption key has to stay in memory at all times, which is prone to attacks.
Introduce per-file encryption, where each file gets its own key. In theory you can selectively discard unused encryption keys from memory when the phone gets locked in order to reduce the attack surface. The difficulty (and missing corresponding code) seems to be determining which keys you can safely discard and which ones you have to keep because you need them for background services.
Ecryptfs and the like are not designed to solve this kind of problem.
Full disk encryption is easy but somewhat insecure: in order to keep a working system the (single) encryption key has to stay in memory at all times, which is prone to attacks.
... unless you have a secure (hardware) place to keep the encryption key(s), where rogue software can't get at it/them. This, as I understand it, is what Apple, do ... but I don't see much prospect of getting bargain-basement Android handset manufacturers to do it (well or at all).
I agree with those posters emphasising Plausibly Deniable encryption, i.e. the ability not only to encrypt important data but to hide it too, and do so in such a way that its very existence is debatable.
Phones are the most portable, losable, stealable items and likely to cross frontiers into intrusive spying regimes like China, Russia, USA and UK.
PD is the only game in town.
Your government doesn't want you to know this but there's functionality in recent Samsung Note devices that they are unhappu about and don't want you to know about. This is evidenced by the many punitive government level legal attacks that are currently targetting Samsung's mobile phone division.
The galaxy note self-destruct feature is nothing more than a highly sophisticated security feature designed for the peace of mind of galaxy note users who want to keep their data safe. In the event of a detected data breach attempt the device triggers a burnout mode that wipes the data on the device so thoroughly that after which no agency, government or otherwise, will be able to retrieve your data.
If you look at the source code in full, the function returns 'true' by default, meaning that someone calling the function, but not aware of the "to do", will be under the impression that the user key is locked, when in fact the function has done precisely nothing.
I would have thought that at least returning 'false' in the e4crypt_is_native() branch would have been sensible.
This post has been deleted by its author
It'll probably take a few years until it's implemented correctly, if ever.
Until then maybe a simple workaround would do:
So, when you have a phone protected with full disk encryption, the key is stored in the memory. Assuming the screen is locked reliably, the only way to get the key is to get it directly from memory, by hardware means. There are many phone models available, each needs a custom approach to get to memory. There also have to be a competent person available that will perform the attack. This requires time.
So it's important to limit the time when the attacker can access keys. The first thing he would do is to connect a phone to a charger to buy time, because when a phone is turned off, memory content disappears.
So the simple solution would be to have a daemon with root privileges (unstoppable by a user) that monitors the battery state. If someone connects a charger, a timer starts and he has e.g. 15 seconds to enter a password, otherwise the phone goes off. There could be additional timer that requires the user to re-authenticate every e.g. 12 hours, otherwise the phone goes off again. For additional security there could be yet another timer that requires you to enter the password e.g. every 30 minutes, otherwise the screen is locked (whatever you do).
This might raise the bar for Direct Memory Access attacks, because there would need to be a qualified personnel available able to dump a particular phone's memory within hours.
It will of course decrease the comfort of using a phone, so everyone has to chose what he/she values more.
This approach would be useful for iPhones too, because seriously: do you trust closed source crypto black box?
This is not the only mess-up. They also managed to lose SECP384r1 support from the TLS stack used by the apps. Firefox and Chrome have their own stacks, they are not affected. But the mail client is a biggie, in 7.0 it can no longer talk to imap and smtp servers using nicely strong ecc crypto. This leaves me with the option of either turning down encryption for all users (yeah, right), maintaining duplicate service just for android 7.0 clients (expensive), or deciding not to support android 7.0 clients.
Hooray!