How many Android handsets are encrypted, and how much protection does Android encryption actually provide? With Android Nougat accounting for roughly 7% of the market, the chance of not being adequately protected is still high for an average Android user.
Android Central published an article titled More Android phones are using encryption and lock screen security than ever before. The author, Andrew Martonik, says: “For devices running Android Nougat, roughly 80% of users are running them fully encrypted. At the same time, about 70% of Nougat devices are using a secure lock screen of some form.”
This information is available directly from Google who shared some security metrics at Google I/O 2017.
“That 80% encryption number isn’t amazingly surprising when you remember that Nougat has full-device encryption turned on by default”, continues Andrew Martonik, “but that number also includes devices that were upgraded from Marshmallow, which didn’t have default encryption. Devices running on Marshmallow have a device encryption rate of just 25%, though, so this is a massive improvement. And the best part about Google’s insistence on default encryption is that eventually older devices will be replaced by those running Nougat or later out of the box, meaning this encryption rate could get very close to 100%.”
So how many Android handsets out there are actually encrypted? Assuming that 0.25 (25%) of Android 6 handsets use encryption, and 0.8 (80%) of Android 7 phones are encrypted, it will be possible to calculate the number of encrypted handsets out of the total number of Android devices.
Let’s have a look at the current Android version distribution chart:
Google does not specify how many Android 5.x handsets are encrypted, but we assume that this number is very low since there were no requirements to encrypt such devices out of the box. While we don’t know for sure, Ars Technica had an excellent write-up on those older versions of Android “Why are so few Android phones encrypted, and should you encrypt yours?” Back then, their conclusion was that encryption in Android was too much of a performance hit to be voluntarily enabled by an average user.
So, considering the above statistics, we can tell that 13.4% of Android devices (Android 6 and 7) are definitely encrypted, plus an unknown number of Android 5.x handsets whose users may have enabled the optional encryption.
What exactly does that mean for the mobile forensic specialist? One can still chip-off an Android handset even if it runs the latest version of Android, and still get a good chance of being able to extract information.
Since Android 6.0 Marshmallow, Google requires manufacturers to enforce encryption in all new devices. This requirement only applies to devices shipped with Android 6.0 from the factory. In other words, if you received Android 6 as an OTA update, there will be no forced encryption for you (but you’ll be able to encrypt your phone from the settings). As an example, LG G Flex 2 was released with Android 5.0 and received the Marshmallow update a year and a half later. As a result, LG G Flex 2 does not have encryption enforced. On the other hand, Samsung Galaxy S7 was released with Android 6 on board, and it has forced encryption out of the box.
Similar logic applies to Android 7 handsets, although there are significantly more devices running Nougat that were updated from Android 6 (and thus already encrypted) rather than getting an update from Android 5.x (and not receiving forced encryption as a result).
We all know how Apple’s iOS encryption works. Full-disk block-level encryption with unique encryption keys for each data block, and an extra encryption layer for the Keychain (a system-wide secure storage database that keeps the most sensitive information such as Web forms and passwords, credit card information, authentication tokens etc.) The full-disk encryption in iOS protects the data securely. The user must authenticate with a passcode (if enabled) every time the device reboots in order to decrypt the data partition; the decryption key is not stored anywhere in the device, and is instead calculated dynamically based on information stored in the Secure Enclave as well as the passcode itself.
Android does not offer anything that can approach iOS in terms of encryption. Instead, Android employs a straightforward block-level encryption of the data partition. Pre-Lollipop devices were using the old insecure encryption scheme that was relatively easy to break. Since Android 5.0, Google switched to new full-disk encryption that became significantly more secure.
By default, the decryption key is stored in the hardware-backed storage using Trusted Execution Environment’s (TEE) signing capability (such as in a TrustZone). The data partition is decrypted with that key automatically once the device reboots. While this may sound lame (what’s the purpose of encryption anyway if the data can be decrypted without user interaction?), bear in mind that extracting the decryption key via chip-off or any other low-level method is not possible, so if you do a chip-off you won’t get the decryption key and won’t be able to decrypt the data.
Users who require additional security can activate boot-level protection by setting the requirement of typing a passcode or password in order to allow the device to continue booting. In this case, the encryption key is created dynamically based on user input as well as device data. There is no official data about the number of users who enabled this feature. Our guess is it is not a lot.
Android 7 introduced a new file-based encryption scheme. Little is known about it other than official information. Very few handsets implement this encryption scheme (mostly Nexus and Pixel devices); there is no obvious way to enable it. Users who manage to enable file-based encryption must perform a factory data reset. All this means that file-level encryption is rare as hen’s teeth. We haven’t seen any mentions of file-based encryption in Android O.
The obvious way to extract information from an unencrypted but locked Android handset would be via the chip-off process. However, there are easier methods available for many devices.
The majority of Android handsets using a Qualcomm SoC have one or more emergency programming (EDL) modes such as 9006 and 9008. The different modes (as well as the different implementations of the lower-level 9008 mode) may allow for either mounting the phone’s eMMC/UFS partitions directly or accessing the storage in low level using the phone’s regular micro USB or USB Type C port. In order to make use of the 9006, experts only need a Qualcomm driver and experience in switching the device to that mode. The 9008 is more difficult as it requires specialized drivers and programmer code; it may also require a special service cable (“deep flash cable”) in order to switch the device into that mode.
LG smartphones feature their own software maintenance mode; a few forensic tools can make use of it to easily pull information from the flash drive. Samsung Exynos-based phones also have service modes that some forensic tools can exploit. MediaTek is known for its two-way emergency download mode that works on the majority of MTK-based phones. All this allows experts extracting information from Android devices relatively easily. With no encryption, it’s almost too easy to access data in Android devices.
More information: