5 ms·

Android Encryption Demystified

40 points by sashk 9y ago

sofaofthedamned 9y ago
I can't quite understand why Elcomsoft are still going. 1. They're being stiffed by Google and Apple upping their security game, hence the amount of complaints on this blog in the comments 2. Their users all seem dodgy as fuck, it's not even funny. 3. Passwords and 2fa are making their brute force methods completely outdated Why haven't they shut down yet?
- problems 9y ago
  Because governments and forensic companies buy their tools. "Completely outdated" you may say - but most people still don't use these things. Most people won't go out of their way to take anything more than the most basic security measures. So that's good enough most of the time for forensic purposes. Apple's "secure by default" concept sounds like the best practice in theory, but their backups and account tying of devices make it so that there's easy attack vectors for tools like this. In order to fully take advantage, you'd have to have never taken a backup of your iOS device and have all iCloud features disabled. Most people don't do that, most people would rather get their data back if they forget their password than keep them private in an extreme situation - for most people that probably makes sense.
- bobsam 9y ago
  3. Passwords and 2fa are making their brute force methods completely outdated Just because you enabled 2fa doesn't mean you're safe. Apples 2fa was easily bypassed using iCloud restore.
- retox 9y ago
  They also played a leading role in all the celebrity phone leaks but I've yet to see it reported on.
mnm1 9y ago
How does it work with a pattern lock? Is the pattern used to calculate the encryption key?
- Johnnynator 9y ago
  AFAIK the pattern just gets translated into a pin
- darklajid 9y ago
  Careful with that! I updated a Nexus 7 (flo) recently to Lineage OS, set a pattern lock (using one of the larger or the largest grid - mostly Just Because™). Enabled encryption. Tablet rebooted and asked for my input to decrypt, presenting a 3x3 grid.. :-) Wasn't a big deal for me, since I just tried to revive that thing anyway. But that seems like a bad idea..
gambiting 9y ago
My problem is that I had full encryption enabled on Marshmallow, upgraded to nougat and my system settings say that encryption is enabled even though I strongly suspect it isn't - my phone used to ask me for pin before booting up, but now it doesn't, so I suspect the encryption was removed while upgrading but the system settings are showing the old value for whatever reason. And I can't really wipe my entire phone just to re-enable the encryption, it's a lot of work to set up all apps again. Xperia Z5. My point is that android encryption has problems if you can just lose the encryption between os version upgrades.
- izacus 9y ago
  Since Android 7.0 the OS can boot without the encryption key just like Android. Absolutely nothing was removed.
  - gambiting 9y ago
    Huh. Well, it would be nice if it was announced in some way, I genuinely though about wiping my phone because of this.
    - izacus 9y ago
      It was - for people that cared about implementation details. Look for articles about so called Direct Boot.
- johnnydoe9 9y ago
  Pretty sure they call it quick boot or something, the earlier behaviour was that you wouldn't be able to lock the screen and it'll be in full brightness until you enter the pin, this was not cool with anyone so they made it this way.
  - izacus 9y ago
    The point is that some services can start before the user data decrypts - for example an alarm clock. The apps can opt in too and get separate store encrypted with device key ( and not user key) before the user unlocks the data partition.
astrobase_go 9y ago
this is one the only articles i've ever read where "honking" is used in a serious capacity as an adjective.
ickwabe 9y ago
I think this session from I/O 2017 provides a better overview in some regards. Admittedly it's brief on details but the overview is helpful. https://www.youtube.com/watch?v=C9_ytg6MUP0 https://www.youtube.com/watch?v=C9_ytg6MUP0
strcat 9y ago
There are some inaccuracies and misleading information here: - Encryption keys are derived from various inputs including the user credentials, not stored in the TEE. The TEE is involved in key derivation and is really supposed to use a hardware-bound key not directly accessible to software including itself but it's an implementation detail that varies by device. - Pixel phones ship with file-based encryption. It's not an option. A phone either uses FDE or FBE. If it uses FBE, then it supports Direct Boot (partial functionally before the user credentials for encryption are enabled via device-encrypted storage class) and per-profile encryption keys. It enables a bunch of possible improvements like authenticated encryption down the road, but isn't much of a security improvement itself. Nexus 5X and 6P only offered a partial implementation as preview for developers tucked away in the hidden developer options, not a user-facing option. - Credential-based encryption is enabled by default when setting a lockscreen method. - Android has a Keystore, that's not exclusive to iOS. - Android doesn't use ECB even though it's implied that only iOS uses unique keys per block. Android does too. There's some more, but I don't have time to go through and nitpick. It's clearly written based on interpreting other people's blog posts, etc. rather than direct knowledge of how it works or even reading the documentation. It doesn't even sound like they have experience using an Android device based on some statements they make. The post totally misses out on things like key derivation and which data is kept at rest. The article misses the real remaining iOS encryption advantages (FBE data classes that Android hasn't added yet and more of the key derivation work is hardware-bound) and just tries to make it sound good by stating things that are not unique to iOS.

40 points by sashk 9y ago

I can't quite understand why Elcomsoft are still going. 1. They're being stiffed by Google and Apple upping their security game, hence the amount of complaints on this blog in the comments 2. Their users all seem dodgy as fuck, it's not even funny. 3. Passwords and 2fa are making their brute force methods completely outdated Why haven't they shut down yet?

problems 9y ago
Because governments and forensic companies buy their tools. "Completely outdated" you may say - but most people still don't use these things. Most people won't go out of their way to take anything more than the most basic security measures. So that's good enough most of the time for forensic purposes. Apple's "secure by default" concept sounds like the best practice in theory, but their backups and account tying of devices make it so that there's easy attack vectors for tools like this. In order to fully take advantage, you'd have to have never taken a backup of your iOS device and have all iCloud features disabled. Most people don't do that, most people would rather get their data back if they forget their password than keep them private in an extreme situation - for most people that probably makes sense.
bobsam 9y ago
3. Passwords and 2fa are making their brute force methods completely outdated Just because you enabled 2fa doesn't mean you're safe. Apples 2fa was easily bypassed using iCloud restore.
retox 9y ago
They also played a leading role in all the celebrity phone leaks but I've yet to see it reported on.

mnm1 9y ago

How does it work with a pattern lock? Is the pattern used to calculate the encryption key?

Johnnynator 9y ago
AFAIK the pattern just gets translated into a pin
darklajid 9y ago
Careful with that! I updated a Nexus 7 (flo) recently to Lineage OS, set a pattern lock (using one of the larger or the largest grid - mostly Just Because™). Enabled encryption. Tablet rebooted and asked for my input to decrypt, presenting a 3x3 grid.. :-) Wasn't a big deal for me, since I just tried to revive that thing anyway. But that seems like a bad idea..

gambiting 9y ago

My problem is that I had full encryption enabled on Marshmallow, upgraded to nougat and my system settings say that encryption is enabled even though I strongly suspect it isn't - my phone used to ask me for pin before booting up, but now it doesn't, so I suspect the encryption was removed while upgrading but the system settings are showing the old value for whatever reason. And I can't really wipe my entire phone just to re-enable the encryption, it's a lot of work to set up all apps again. Xperia Z5. My point is that android encryption has problems if you can just lose the encryption between os version upgrades.

izacus 9y ago
Since Android 7.0 the OS can boot without the encryption key just like Android. Absolutely nothing was removed.
- gambiting 9y ago
  Huh. Well, it would be nice if it was announced in some way, I genuinely though about wiping my phone because of this.
  - izacus 9y ago
    It was - for people that cared about implementation details. Look for articles about so called Direct Boot.
johnnydoe9 9y ago
Pretty sure they call it quick boot or something, the earlier behaviour was that you wouldn't be able to lock the screen and it'll be in full brightness until you enter the pin, this was not cool with anyone so they made it this way.
- izacus 9y ago
  The point is that some services can start before the user data decrypts - for example an alarm clock. The apps can opt in too and get separate store encrypted with device key ( and not user key) before the user unlocks the data partition.

astrobase_go 9y ago

this is one the only articles i've ever read where "honking" is used in a serious capacity as an adjective.

ickwabe 9y ago

I think this session from I/O 2017 provides a better overview in some regards. Admittedly it's brief on details but the overview is helpful. https://www.youtube.com/watch?v=C9_ytg6MUP0 https://www.youtube.com/watch?v=C9_ytg6MUP0

strcat 9y ago

There are some inaccuracies and misleading information here: - Encryption keys are derived from various inputs including the user credentials, not stored in the TEE. The TEE is involved in key derivation and is really supposed to use a hardware-bound key not directly accessible to software including itself but it's an implementation detail that varies by device. - Pixel phones ship with file-based encryption. It's not an option. A phone either uses FDE or FBE. If it uses FBE, then it supports Direct Boot (partial functionally before the user credentials for encryption are enabled via device-encrypted storage class) and per-profile encryption keys. It enables a bunch of possible improvements like authenticated encryption down the road, but isn't much of a security improvement itself. Nexus 5X and 6P only offered a partial implementation as preview for developers tucked away in the hidden developer options, not a user-facing option. - Credential-based encryption is enabled by default when setting a lockscreen method. - Android has a Keystore, that's not exclusive to iOS. - Android doesn't use ECB even though it's implied that only iOS uses unique keys per block. Android does too. There's some more, but I don't have time to go through and nitpick. It's clearly written based on interpreting other people's blog posts, etc. rather than direct knowledge of how it works or even reading the documentation. It doesn't even sound like they have experience using an Android device based on some statements they make. The post totally misses out on things like key derivation and which data is kept at rest. The article misses the real remaining iOS encryption advantages (FBE data classes that Android hasn't added yet and more of the key derivation work is hardware-bound) and just tries to make it sound good by stating things that are not unique to iOS.