android encryption

[mikedt]

thanks for your comments, andy. ...

that is one of the reasons why i began this thread ...

the government for some reason has a disproportionate interest in ios encryption ...

http://www.wsj.com/articles/justice...t-data-from-about-12-other-iphones-1456202213

why isn't the government interested similarly in android phones?

Probably because most Android devices out there are not encrypted by default, Apple devices are. But I believe that Marshmallow 6.0 does change that.

 

[fields12]

good point;

once the precedent sets for the big gorilla apple ... the rest of the smaller dominoes will fall ....

 

[codesplice]

2. encryption only applies when the phone is physically "off?" ... and hence, decryption only applies when the phone is physically turned "on" from physical "off?" hence, i am not sure whether the phone data is even encrypted during the time when the device has power "on," but when it reverts to "screen lock?"

I don't believe that it's an "all on" or "all off" kind of thing. Data is decrypted on the fly as it is accessed. If the phone is on, only the data currently stored in the device's RAM is not encrypted - all of the "at rest" data on the phone's internal storage remains fully encrypted. That's why you typically see a small I/O performance hit when encryption is enabled - the kernel takes a little bit more time to decrypt data as it is accessed.

 

[fields12]

that's a good point, codesplice ...

this is "above my pay grade," but if:

a. i request the device to access my contacts list;

b. and my contacts list along with all of the rest of my data is at rest and encrypted;

c. does not the device processor, in that event, need to decrypt the entire hard drive or decrypt all of the encrypted data first; and then second, after decryption, look for and retrieve and place into RAM ... the contact list?

d. in other words, if all of the data on my device is jumbled by encryption, how can the processor know where the requested data to retrieve is located, without decrypting all of the data first?

 

[codesplice]

That's a very good question, and the short answer is I don't fully know. I did some digging, and what I found (specific to Android 5.x / Lollipop, rather than Android 6.0 / Marshmallow on my encrypted 6P) has me kind of second-guessing my statement.

Some interesting bits from Google's Full Disk Encryption AOSP page (again, written for Lollipop) :

Full disk encryption is the process of encoding all user data on an Android device using an encrypted key. Once a device is encrypted, all user-created data is automatically encrypted before committing it to disk and all reads automatically decrypt data before returning it to the calling process.

That last bit kind of makes it sounds like it supports my "decrypt on the fly" statement.

But...

Starting an encrypted device without default encryption
This is what happens when you boot up an encrypted device that has a set password. The device’s password can be a pin, pattern, or password.

1. Detect encrypted device with a password
   Detect that the Android device is encrypted because the flag ro.crypto.state = "encrypted"
   
   vold sets vold.decrypt to trigger_restart_min_framework because /data is encrypted with a password.
   
   
2. Mount tmpfs
   init sets five properties to save the initial mount options given for /data with parameters passed frominit.rc. vold uses these properties to set up the crypto mapping:
   1. ro.crypto.fs_type
   2. ro.crypto.fs_real_blkdev
   3. ro.crypto.fs_mnt_point
   4. ro.crypto.fs_options
   5. ro.crypto.fs_flags (ASCII 8-digit hex number preceded by 0x)
3. Start framework to prompt for password
   The framework starts up and sees that vold.decrypt is set to trigger_restart_min_framework. This tells the framework that it is booting on a tmpfs /data disk and it needs to get the user password.
   
   First, however, it needs to make sure that the disk was properly encrypted. It sends the command cryptfs cryptocomplete to vold. vold returns 0 if encryption was completed successfully, -1 on internal error, or -2 if encryption was not completed successfully. vold determines this by looking in the crypto metadata for theCRYPTO_ENCRYPTION_IN_PROGRESS flag. If it's set, the encryption process was interrupted, and there is no usable data on the device. If vold returns an error, the UI should display a message to the user to reboot and factory reset the device, and give the user a button to press to do so.
   
   
4. Decrypt data with password
   Once cryptfs cryptocomplete is successful, the framework displays a UI asking for the disk password. The UI checks the password by sending the command cryptfs checkpw to vold. If the password is correct (which is determined by successfully mounting the decrypted /data at a temporary location, then unmounting it),vold saves the name of the decrypted block device in the property ro.crypto.fs_crypto_blkdev and returns status 0 to the UI. If the password is incorrect, it returns -1 to the UI.
   
   
5. Stop framework
   The UI puts up a crypto boot graphic and then calls vold with the command cryptfs restart. vold sets the property vold.decrypt to trigger_reset_main, which causes init.rc to do class_reset main. This stops all services in the main class, which allows the tmpfs /data to be unmounted.
   
   
6. Mount /data
   vold then mounts the decrypted real /data partition and prepares the new partition (which may never have been prepared if it was encrypted with the wipe option, which is not supported on first release). It sets the property vold.post_fs_data_done to 0 and then sets vold.decrypt to trigger_post_fs_data. This causesinit.rc to run its post-fs-data commands. They will create any necessary directories or links and then setvold.post_fs_data_done to 1. Once vold sees the 1 in that property, it sets the property vold.decrypt totrigger_restart_framework. This causes init.rc to start services in class main again and also start services in class late_start for the first time since boot.
   
   
7. Start full framework
   Now the framework boots all its services using the decrypted /data filesystem, and the system is ready for use.

So that makes it sound like it is decrypting the whole shebang at once. :-/

And that kind of falls in line with what I remembered on pre-Marshmallow devices. There would be a false boot which loaded just enough of the framework to prompt for the pin/pattern/password before decrypting /data and continuing the boot.

With Marshmallow, though, there doesn't seem to be that false boot - it boots straight to the main lockscreen. Enter my PIN/pattern/password and I'm instantly in. I haven't yet found a good resource to explain how/why that might have changed.

I'll try and do some more reading today if I have time to make both of us smarter.

 

[fields12]

thanks for your informative research and comments.

once i encrypted my android 5.1.1. device, i no longer had the option of using a pattern, but rather only a password to unlock the screen. ... i think that "encryption" once enabled, and "lock screen" features, merge.

 

[codesplice]

thanks for your informative research and comments.

once i encrypted my android 5.1.1. device, i no longer had the option of using a pattern, but rather only a password to unlock the screen.

That's interesting. What device?

What we’ve added for Android 5.0

• Added support for patterns and encryption without a password.

 

[fields12]

lg k7

 

[fields12]

2/23/16 test results of encryption on android 5.1.1., lg k7 device.

1. begin test with device "on," "screen off."

2. tap twice and screen illuminates with normal screen lock message: "enter password."

3. enter wrong password approximately ten times, and screen message appears: "wrong password entered five times, try again in 30 seconds;"

4. after 30 seconds; enter wrong password approximately twenty times, and screen message appears: "wrong password entered ten times, try again in 30 seconds;"

5. after 30 seconds; enter wrong password approximately thirty times and screen message appears: "wrong password entered twenty times, try again in 30 seconds.

6. after 30 seconds, enter wrong password again a few times and new screen message appears: "account unlock; to unlock, sign in with google account."

7. enter wrong google account, and screen locks with message "6."

8. turn off power to phone; and turn power back on; the normal message appears: "type password to decrypt storage; 30/30 attempts remaining."

9. enter wrong password 29 times; and new message appears: "Final attempt. if you do not enter the correct password your phone will automatically factory data reset, and all files will be erased."

10. enter wrong password again; and the factory reset begins.

11. midway through "10" however, new message arrives "This device was reset. To continue sign in with google account that was previously synced on this device." ....

12. attempt entry of different account; unsuccessful.

13. enter correct google account email, and reset accomplishes successfully, albeit with no user data surviving from prior usage.

14. it appears that android 5.1.1., and lg k7 has a fairly robust encryption system in place at the moment and somewhat comparable with the apple alleged "gold standard."

15. for this user anyhow, it appears more than enough ....; whether it will survive the coming legal challenge, no one knows.

 

[RazzMaTazz]

Fields12: Wow! Thanks for doing this and posting the results! Great to know!

It's good to know that I could put a password-lock on my phone and thwart potential evildoers who might steal my phone or find my lost phone. I'd consider implementing a password if I traveled abroad.

It's nice that if you backup your data to the (Gmail/Hotmail, etc.) cloud(s), as most of us do, you could quickly restore any data.

However, if one has a cloud-backup then the cloud account is subject to attack by evildoers through (in many cases) a relatively simple dictionary password attack on the specific account, or a general attack on the cloud servers. (Though I'd say that's only a concern for those who are paranoid about governments or terrorists getting their personal information, but not paranoid about giving their personal information to corporations like Google, Microsoft, Facebook, Yahoo, et al).

Did your SD-card get wiped? (I assume just the internal storage is wiped, thereby leaving SD-card-based music files, playlists, and selfies dangerously exposed to terrorists.)

 

[fields12]

you're quite welcome.

i was happy to see the results also.

* * *

one parameter of the test that i missed, i have now performed after the reset; and that is:

1. turn off phone;

2. turn on phone;

3. message appears: "type password to decrypt storage. 30/30 attempts."

4. enter wrong password ten times; and new message appears "type password to decrypt storage 20/30 attempts remaining."

5. turn off phone to gain or regain 30 attempts at decryption,

6. turn power back onto phone and new message arrives: "type password to decrypt storage. 20/30 attempts remaining.

7. so, powering off the device does not restore 30 attempts at password decryption.


* * *

I do not have an sd card.


* * *

i do not use, and I have turned off back up and cloud storage ... both on the android operating system; and in the google account.

 

[codesplice]

Thanks for the thorough testing, @fields12!

 

[fields12]

you're quite welcome.

i am happy to see that android has excellent encryption for myself and 99.9 percent? of android users whose data will not subject them to nsa scrutiny.

 

[scary alien]

@codesplice, I think the text you quoted:

Full disk encryption is the process of encoding all user data on an Android device using an encrypted key.

contains the significant part regarding how to know where/how to retrieve the data (i.e., there might be un-encrypted meta data pointing to the user data).

Although it's likely much simpler that this: some encryption key is used to encrypt/decrypt the data at the highest (lowest? I might have that backwards ) necessary point in the access chain.

Don't know for sure, though .

~ ~ ~

Also, FYI, rooted devices (or rather ones with unlocked bootloaders) do allow (or provide a way, at least ) of not being forced to encrypt a device. That's why I like the Nexus line . A minority of devices overall, to be sure .

Very interesting discussion / thread--our esteemed and good friend @EarlyMon should weigh-in on all of this...

Cheers!

 

[psionandy]

That Security now podcast I mentioned before, has a text based transcript..

Their in depth look at IOS can be found at

https://www.grc.com/sn/sn-446-notes.pdf
https://www.grc.com/sn/sn-447-notes.pdf
https://www.grc.com/sn/sn-448-notes.pdf


and if you're interested in Computer security and Privacy.. then you should listen to the podcast which can be found at
https://twit.tv/shows/security-now

 

[scary alien]

^^^ Steve Gibson rules!

I forgot about that guy (anyone remember wizmo? )...can't wait to read those PDFs!

Thanks, @psionandy!

 

[fields12]

razzmatazz;

you previously inquired about what happened to my sd card stored files on reset; and i responded i did not have an sd card.

i have a lot to learn about mobile phones.

i now have learned that i do have an sd card; and that i previously confused "microSD card" with "SD card."

when i performed the factory reset, or more precisely when lg/android performed the factory reset, .... i discovered newly downloaded applications (firefox, speed test, evernote) now residing on the sd card.

i assumed all mobile phone applications including operating system and others resided on a single "hard disk," like a personal computer, but apparently, smartphones enjoy a variety of "hard drives."

when the factory reset occurred, the previously downloaded speed test application disappeared, so i assume that the factory reset ... wiped the sd card .... along with other hard drives containing user data.

i also am not sure what user data means, since segregating emails, for example, from email application .... seems difficult to achieve.

 

[codesplice]

With Marshmallow, though, there doesn't seem to be that false boot - it boots straight to the main lockscreen. Enter my PIN/pattern/password and I'm instantly in. I haven't yet found a good resource to explain how/why that might have changed.

I'll try and do some more reading today if I have time to make both of us smarter.

Turns out I'm a dummy.

At Settings > Security > Screen lock:

A clue! So I went and disabled all my Accessibility-having apps (Tasker, Anticipate, Dashlane, Clip Stack, Inputting+, AutoMate... wow I've got a lot of those), and hopped back in to the same menu.

I tapped on my existing lock screen method (Pattern) and found this option:

Enabled that and rebooted. ~15 seconds later:

So the encryption in Marshmallow works pretty much the same as it did in Lollipop - except now the user has the option to disable the requirement to enter their passcode before the OS boots fully. I'm guessing that means that the encryption process uses the default password to unlock the master encryption key and allow the OS to boot unless that "require XXX to start device" option is configured.

Good to know - though a bit aggravating that I can't have a fully-protected securely-encrypted device while still having the convenience of those accessibility-enabled apps. Oh well. There's pretty much always a tradeoff between security and convenience.

PS: Thanks to @EarlyMon for talking it through with me!

 

[scary alien]

Ah, thanks, @codesplice--I get that pattern confirmation prompt when I boot-up--it must be a default setting since I don't believe I enabled it initially.