back to article Inside Android's source code... // TODO – Finish file encryption later

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 …

  1. Anonymous Coward
    Devil

    it will be finished ...

    ... Real Soon Now.

    1. Voland's right hand Silver badge

      Re: it will be finished ...

      Neah... It is in beta.

  2. Anonymous Coward
    Anonymous Coward

    FWIW, I don't rely on Google to do my security. EDS is far better in that regard. I seriously doubt that Google is going to adf hidden, deniable partitions any time soon.

    Yep, still lacking the tin foil hat icon.

    1. Geoffrey W

      A tin foil hat icon won't help anyone. You need the real thing.

  3. Kevin McMurtrie Silver badge

    Probably not motivated

    The Chinese phone makers are turning on full disk encryption to make Google happy but they don't support changing the default encryption key.

  4. Voland's right hand Silver badge
    Devil

    No idea what is Google's problem

    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.

    1. Anonymous Coward
      Anonymous Coward

      Re: No idea what is Google's problem

      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.

      1. dajames

        Re: No idea what is Google's 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).

  5. Milton

    Plausible Deniability

    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.

  6. Nick Kew
    Coat

    On fire?

    Hmmm, so when Samsung Galaxy 7 phones catch fire, is it in fact Google's pants, rather than those batteries that originally got the blame?

    I'll get me coat (and un-burned pants).

    1. Nick Ryan Silver badge
      Black Helicopters

      Re: On fire?

      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.

  7. Mark 110
    Joke

    Open source

    Maybe Apple could just open source their implementation for Google to port . . .

    1. PassiveSmoking

      Re: Open source

      If it's in Darwin then it might already be open source. I'd have to check though. (People seem to forget that Apple's OSX family of which iPhone OS is a part is partially open source)

  8. jms222

    Just that feature ?

    Can't we just confirm Android is half-baked and do away with the rest of the sentence ?

    1. DropBear

      Re: Just that feature ?

      Every software in existence is perpetually half-baked to some degree. Your point...?

  9. Electron Shepherd

    It's actually worse

    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.

    1. This post has been deleted by its author

    2. Anonymous Coward
      Anonymous Coward

      Re: It's actually worse

      The default is to return true, because if it reaches that point there hasn't been an error.

      False means an error has occurred.

      It's an incomplete implementation, not an error.

      1. asdf

        Re: It's actually worse

        >It's an incomplete implementation, not an error.

        It is nearly 2017 so for a handset its a frigging error unless your business is selling users privacy to the highest bidder in which case its nothing but a cost to put off as long as possible.

  10. cowardhoward

    Simple solution

    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?

  11. EnviableOne
    Coat

    if Google locked everyone down to propriety hardware configuration, they would have done this 3 years before apple, the problem is they have to abstract everything to get it to work on the multitude of devices and there for have less control over the hardware operations.

  12. Hotears

    Not the only encryption TODO in 7.0

    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!

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like