I've got some questions about Android devices that are encrypted using the option under "Security" in the settings.
I am currently under the impression that:
A. The encryption option encrypts certain information on the device, including app data, internal "SD card" partitions, and the apps themselves.
B. During the booting process, the device checks whether the data is encrypted, and, if it is, starts a temporary "framework" that prompts the user for the password and then attempts to unlock the encryption keys for the partition using the password. If successful, the real "framework" is loaded and the phone boots normally. An emergency dialer of some sort is also included.
Now, the problem is that I am not sure about several things.
1. Exactly what information on the device is encrypted?
2. What runs during the "temporary framework" stage? If third party apps are fully encrypted and inaccessible before the user enters his password, then those apps clearly cannot run in this phase. What about system apps? What about Google Play services?
3. Can the user usually customize the "temporary framework" screen (e.g., by adding lock text, owner information, etc?).
4. Can encrypted devices receive system software updates "over the air" or via other means?
5. Why is a factory data reset the only way to "undo" device encryption? The encryption process itself demonstrates that the system can get write permissions to all of the relevant partitions, so why can't the process simply be run "in reverse" (given, of course, the correct password)?
6. How severe are the performance and battery life impacts of device encryption?
7. Can the phone receive phone calls or text messages while it is in the "temporary framework"?
8. Does the "temporary framework" emergency dialer allow the user to call user-specified ICE phone numbers in addition to 911?
The way I view it, people who steal or find phones or tablets can be classified by intention into three different categories:
I. These are the honest people who find misplaced phones/tablets and actually want to return them.
II. These people steal mobile devices or find lost ones and are interested only in turning the devices into quick cash.
III. These people steal mobile devices and intend to extract as much information as possible.
Encryption is probably the best available way to defend against the class III attacker. Barring lousy passwords, FROST, and other similar techniques/software, an encrypted device should keep these attackers out.
However, let's say that the phone is lost in one of the following states:
- The device is powered off
- The device has a very low battery
- The device was already in the "temporary framework" (e.g., while the user was entering his password)
- The device is dropped, causing the battery to fall out
Now, if an honest person (class I) finds the device and decides to recharge or reboot it in hopes of finding the proper owner, he/she will be stuck at the "temporary framework". If the user cannot customize the encrypted device password prompt and no lost device tracking apps can run, then the finder cannot return the device without contacting the carrier. Additionally, the device owner cannot track it via GPS.
The newly announced Android Device Manager is the reason why I asked about system apps and Google Play Services above. If it is allowed to run while the device is prompting for an encryption password, then it will have an advantage over third party solutions.