“Had San Bernardino shooter Syed Rizwan Farook used an Android phone, investigators would have had a better chance at accessing the data”, says Jack Nicas in his article in The Wall Street Journal. Indeed, the stats suggest that only 10 per cent of the world’s 1.4 billion Android phones are encrypted, compared with 95 per cent of Apple’s iPhones. Of those encrypted, a major number are using Nexus smartphones that have encryption enforced by default.

What is the reason behind this low encryption adoption rate among Android users? Let’s first have a look at how encryption is enforced by two major mobile OS manufacturers, then look at how it’s implemented by either company.

Android 5.0: Encryption Is Enforced… or Not?

With the release of Android 5 ‘Lollipop’, Google had plans to enforce full-disk encryption on all devices released with this version of Android. (Devices upgrading from older versions of Android would be exempt). Motorola-built Nexus 6 was the first smartphone released with Android 5 that not only had encryption enabled but offered no possibility for end users to disable it (not unless they used a third-party kernel).

What have resulted was a dramatic drop of performance followed by vastly reduced battery life. ARS Technica published the following benchmark:

(source: ARS Tecnnica)

Compared to similarly specced Moto X 2014 manufactured by the same company, the new Nexus had a dramatic drop of sequential read speeds. Being 8 times slower compared to its non-encrypted sibling can surely be attributed to encryption.

This claim was verified by another company. AnandTech published the following benchmarks:

Performed on the same device, this test clearly demonstrates how severe the penalty was on the Nexus 6 once encryption was activated. No doubt this has become a reason for Google to quietly back away from encrypting new Lollipop devices by default (ARS Technica).

Compare that to sequential read performance of the ancient iPhone 5S (which has its user data partition encrypted straight out of the box), and you start wondering if Google is maybe doing it wrong:

(source)

Android 5.0 Encryption: No Hardware Acceleration

So what happened, exactly, to cause such a dramatic drop in performance? Let’s look at the Snapdragon 805 SoC that was used to build the Nexus 6.

While Apple used a 64-bit ARMv8 design in iPhone 5S, Qualcomm was struggling to build a 64-bit CPU at the time. Back in 2014, Snapdragon 805 was the company’s top-tier CPU with four custom 32-bit Krait cores. As a result, Qualcomm had to offer encryption hardware acceleration for Snapdragon 805 in the form of crypto QCE. Apparently, something went wrong when merging crypto QCE drivers into Android 5.0 AOSP, and so Google chose to disable encryption hardware acceleration altogether at the time they launched Android 5.0 and the Nexus 6.

Android 5.1: Finally, Hardware-Accelerated Disk Encryption Is There! Or Not.

Apparently, the situation around Android 5.0 was temporary. Google were up to something. Indeed, in Android 5.1, Google added support for hardware-accelerated disk encryption.
“In order to improve performance without sacrificing device security Android 5.1 integrated support for hardware-accelerated disk encryption on devices that provide dedicated cryptographic hardware, such as the Nexus 6.” (source)

Unfortunately, this feature ended up disabled in Android on Nexus 6 because of ongoing stability problems.

So what exactly was going on? Android implements full-disk encryption, and allows encryption acceleration with a crypto API driver that must be compiled into the kernel. The driver takes advantage of the phone’s encryption acceleration hardware such as the cryptographic module built into Snapdragon 805. Once utilized, this allows encryption to be performed on a dedicated unit with low power consumption instead of the main CPU. This can both improve disk access times and reduce battery consumption (more on that later). Hardware-accelerated full-disk encryption is many times faster compared to software-based implementations, and takes significantly smaller toll on the phone’s battery. Unfortunately, hardware acceleration using the dedicated Qualcomm module had to be disabled in the release version of Android 5.1 due to some major stability problems on the Nexus 6.

Apparently, Google failed to properly implement hardware-accelerated encryption support in Nexus 6. The Nexus 6 was about to showcase the benefits of full-disk encryption to OEMs building their handsets. No wonder the OEMs were not impressed, and Google had to lift the requirement for OEMs to release Android 5 devices with FDE enabled out of the box.

Android 6.0: Full-Disk Encryption to Be Enforced Out Of the Box on 64-bit Hardware

Following the failure to properly implement full-disk encryption on 32-bit systems in Android 5 and 5.1, Google continues its journey. At this time, the company wants OEMs who make devices that run Android 6 out of the box to enable full-disk encryption by default.

Did Google manage to work out the bugs with dedicated encryption hardware found in their 2014 flagship, the Nexus 6? Nope. Instead, they decided to use a workaround.
The ARMv8 specifications offer a set of commands to implement AES acceleration on the CPU. These instructions are available in all 64-bit ARM CPU’s including the extremely popular mid-range Snapdragon 410 SoC. While not a proper replacement for a dedicated encryption module (according to Qualcomm itself), these instructions provide so-called “software acceleration”, which is, well, better than nothing. Software-“accelerated” encryption offers access speeds that are “only” two times slower compared to unencrypted performance. (For comparison, Apple’s iPhone 5S relying on Secure Enclave and a dedicated encryption chip has zero encryption performance penalty).

In addition to that, dedicated encryption acceleration hardware is available in some systems (such as Snapdragon 810). If a dedicated encryption module is available, it (theoretically) has a higher priority compared to software-based implementations. Unfortunately, Google does not seem to have a grip on that. Both the Nexus 5x and Nexus 6P only come with “software acceleration” provided by the ARMv8 specification instead of utilizing the dedicated cryptography acceleration module built into Snapdragon 810 (source).

So how does that work in real life? ARS Technica made the following test:

(source)

As you can see, the Moto E (2015) using an ARMv8 CPU (Snapdragon 410 in fact) is “only” two times slower when reading encrypted data, while the ARMv7-based Moto G (2014) without built-in encryption acceleration is 4 times slower to read encrypted data compared to unencrypted performance.

Why is this “software acceleration” better than the proper implementation? Because Google’s Dave Burke, Engineering lead said so:

“Encryption is software accelerated. Specifically the ARMv8 as part of 64-bit support has a number of instructions that provides better performance than the AES hardware options on the SoC.”

Why do we believe it’s a load of crap? Because using and researching both major systems, iOS and Android, allows making observations and drawing conclusions. Apple’s encryption implementation is exemplary. A dedicated, low-power chip handles encrypted I/O without waking up the main power-hungry CPU. On the contrary, “software-accelerated” encryption wakes up the main CPU cores every time the phone needs to read or write a bit of data onto the encrypted disk. These constant wakeups drain the phone’s battery extremely fast compared to using the same device without encryption. Activating encryption on an Android smartphone is just shooting oneself in the foot. Reduced performance and battery life will follow.

This is the reason why Android users are not enthusiastic about full-disk encryption as opposed to 95 per cent iOS users who are happy with it. This, and not the fact that Apple mandates FDE on all devices since iPhone 3GS.

Update 21-03-2016: Android 7 to the Rescue?

Last week, Google released the first preview of Android 7. In our lab, we ran encryption performance analysis on two Nexus 6 devices: one running Android 6.0.1 with a custom kernel (ElementalX; encryption disabled), another one running the first Android N preview (encrypted). We tested both sequential and random read and write speed, and received the following results:

(We no longer have a Nexus 6 running Android 5.0, hence no 256K RR or 256K RS readings for this OS).

As can be seen, Google significantly improved FDE performance on Nexus 6 since introduction (from 25.36 MB/s in Android 5.0 to 39.34 MB/s in Android 7.0, both running full stock OS). In the days of Android 5.0, encrypted sequential read performance was 8 times slower than unencrypted reads. Today, it’s ‘only’ 3 times slower compared to unencrypted reads. It’s still nothing to be proud of when comparing with 2013’s iPhone 5S who’s encryption does not appear to have any significant performance impact.