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.
Interested in knowing more details as well.
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.
+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.
+Cristian Colocho I agree, Chrome OS has been using this same method for years. Which would mean like Chrome OS "The system does not protect against root file system tampering by a dedicated attacker."
+Josh Armour, if you know where to look to learn more about the changes in Android 5.0 disk encryption: interested!
I edited the first post and added a screenshot from Nexus 7 2013 asking you before encryption, while no password or PIN has been set.
May be this will help – http://nelenkov.blogspot.sk/2014/10/revisiting-android-disk-encryption.html by +Nikolay Elenkov
+Dimitar Zlatarev thanks, let us know what you think of what you read 😉
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."
+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.
Is it normal to get double boot animation and slow boot with phone encryption? N5 on Dev preview +François Simond
+Alessandro Landra I would say that it doesn't boot particularly fast here but there's no double animation
I get first bootanimation until code for encryption than second bootanimation (of android L like the first one) for turning on the phone +François Simond
+Alessandro Landra okay yeah that's what's expected.
I get a single one as I'm at home and disabled lock screen entirely for now.
It also doesn't ask anything while booting, which is the aspect that troubles me.
+François Simond than is the phone encrypted with the old code also if removed? It seems useless, you could always copy de-crypted files with phone on…
+François Simond check this out github.com/PkmX/lcamera/
+Boris Michael Valdez wow I didn't expect to see Scala code.
But thanks I have everything I need already 😊
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.
+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.
+tobby o and which kind of security does provide data that's encrypted by default, also by default decrypted without the need of any authorization or password.
+François Simond the primary purpose of default encryption is not Security, but simplicity. If you want security, add a password.
+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.
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.
+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.
+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.
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.
+François Simond What's the encryption overhead like? Any noticeable increase in CPU usage and battery consumption?
+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.
what is smart lock ?
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 🙂
+Hai Bison a bad guy would enable encryption (that was requiring a password) before that already: no change beside the communication on this aspect
Hi +François Simond! I was wondering if you could direct me to some articles about what encryption is and how it works? I'm a total noob on this but I'd like to learn about the subject..