Large change in how disk encryption is done in Android 5.0 Lollipop preview

In previous versions of Android, encrypting your phone aka encrypting the /data partition meant that you had to keep using a PIN or password, that would serve both as:
– decryption key to enter during the device boot (that is a component to decrypting the disk decryption key? need confirmation on that)
– lockscreen PIN or password

As you can see in the attached captures, the behavior is entirely different in Android 5.0 Lollipop (here on on Nexus 5).
The first capture show what you see after encrypting your phone after entering a PIN for the screen lock.
Just like before, during boot, the PIN will be asked during boot and to unlock the device.

But now, as you can see in the second capture, you can switch back your screen security to Swipe, or even None.
Then, no password will be asked during boot or in the lock screen.
Yet your data partition is still encrypted.

Question: Where is the disk decryption key stored, and how is it protected?

I look forward to learn that exactly, hopefully a security researcher will take a look at how this new implementation functions, and if it actually provide any security benefit after you revert Screen security to a PIN to Swipe or None.

A question to you, as all my 5.0 devices are already encrypted: can you also now trigger disk encryption without enabling a Screen security first?

Edit:
Yes, you can now indeed encrypt a tablet with Screen lock being set to Swipe or None.

#supercurioBlog #encryption

 

In Album Android 5.0 Preview encryption

Source post on Google+

Published by

François Simond

Mobile engineer & analyst specialized in, display, camera color calibration, audio tuning

32 thoughts on “Large change in how disk encryption is done in Android 5.0 Lollipop preview”

  1. Maybe it uses your Google credentials for authentication? That'd be how Chrome OS works. User data is either protected by your google password or one you can set yourself, and when you change your google password you have to enter in the old one and it destroys and rebuilds the encrypted user data with the new one.

  2. +Cristian Colocho my point is if the decryption key for /data partition is stored on disk, and apparently can be read without effort and used as-is when screen lock is set to None or Swipe, your data might be encrypted but it provides no security whatsoever.
    If so, there should be a big warning when reverting from PIN or Password to Swipe or None.

    Based on how it function I suppose that when you do so, it rewrites the /data partition decryption key in clear instead of encrypted by the PIN or password.

  3. Well i think the relevant part here is :
    "While no definitive details are available, it is fairly certain that (at least on high-end devices), Android's disk encryption key(s) will have some hardware protection in Android L. Assuming that the implementation is similar to that of the hardware-backed credential store, disk encryption keys should be encrypted by an unextractable key encryption key stored in the SoC, so obtaining a copy of the crypto footer and the encrypted userdata partition, and bruteforcing the lockscreen passphrase should no longer be sufficient to decrypt disk contents."

  4. +Dimitar Zlatarev Okay I read the whole document, it's good stuff 🙂 thanks +Nikolay Elenkov
    So yes the key is not derived from the usually short PIN or screen lock password (that becomes a pain to enter if too long) which is great.
    However I'm still confused about the behavior and especially the sense of false security when using encryption with no PIN or password.
    I think there is dire need to be much better explanation when enabling encryption that what's currently in the preview, see the attached screenshot, it's really bad: as uninformative as it gets.

  5. I'm starting to understand why Google may be heading in this direction.
    – Devices will be encrypted by default
    – No need to turn Encryption on/off
    – A "default" decryption key created from a hardware identifier like the IMEI is used to decrypt at boot.
    – If the owner uses a PIN or Password to unlock, then that will be used to create the key.

    I believe this is close to what Apple does with iOS. The end user doesn't need to understand encryption.

  6. +François Simond It seems like the only protection you get is if you cannot boot the device, you can't extract data because it's encrypted (while off). Of course if you can boot the device and you don't have a Pin or Password set, then there is no protection.

    Also, data wipes should be quicker (and more secure) as you only need to throw away the encryption key.

  7. +tobby o I agree, but the way it's presented right now, with both the FBI and NSA acting like this is the end of the world and those solutions will make people's data secure for real make me question what's really happening.

    Google is trying to make people believe that their data is secure by default, and if the final build behavior is the same as this preview, this would be complete bulshit and disinformation.

    The main difference is that thanks to the Touch ID, most people don't need to type a password, while most Android Lollipop users will still chose swipe unlock instead if a pin or password, leaving their data without any kind of protection despite encrypted on disk.

  8. Sorry +François Simond I don't understand you're argument.

    No password = Not secure

    Another benefit of encryption is it will be almost impossible to recover any data after a factory reset or remote wipe. A lot of people are concerned about this when getting rid of their devices.

  9. +tobby o see the 3rd screenshot attached.
    It mentions encrypting personal data while there's no password nor PIN, but but that it doesn't provide any security benefit.

    During a factory reset, devices trim the flash storage for a few years, it's not like it was a HDD 😉
    you would need a custom EMMC controller firmware or custom controller to be able to read some data back (if lucky) after a trim.

  10. +tobby o what I find questionable is Google communication: to respond quickly to Apple, they announced "yes encryption we have that too"
    But thing is that for most people it will be ineffective and only give a sense of false security, which is actually worse.
    Unless they make things differently and clear.

  11. I hoped it wouldn't come down to this, but it doesn't take a genius to understand that if you don't lock your phone, anyone can pick it up and access everything.

    One analogy would be an alarm system is useless unless it is "armed."

    In future encryption won't be mentioned at all, we are in a transition phase.

  12. +tobby o well I'm thinking about the typical user who doesn't think about security, and doesn't know where to look for information either.
    The 5.0 preview doesn't encrypt by default, and you're not encrypted either after a factory reset.

    But to get results for instance and also provide the minimum amount of education, it might be useful to encourage the user during the initial setup at first boot to activate a security mode and enable either a pattern, PIN+Face or Password+face
    If this doesn't happen, "encryption by default" that seem to upset both the FBI and NSA would only be a PR move for the vast majority of users.

  13. What I understand from +tobby o is by default all data is stoted encrypted. For example this text "abc" can be stored as "xyz", not as itself "abc". And that is what Google promises with Lollipop.

    However most users just buy the device and use it straight away. When they need protection, they set a password, and done.

    And anyone who can buy an Android device knows the fact that if they can start/open their device without having to enter a password, then someone else can do so. They just don't think that if someone else who doesn't own their device will be asked for a password if they start/open the device (which is not protected by a password). I think if they're smart enough to buy a device, they can understand that logic.

    So, FBI and NSA are worried, because a bad guy will pick up a device with Android Lollipop, not Gingerbread. And their worst dream is that bad guy… sets up a password.

    That's my point, +François Simond 🙂

Leave a Reply to François Simond (supercurio) Cancel reply