Disk Encryption: The Good and The Slow

In a world where personal information is not so personal, entire bank accounts are linked to our smartphones, and surveillance and cyber-crime are at an all time high, security is one of the majority aspects of the technology sphere.

Simple screen locks in the form of PINs and patterns have been around for a long time, but only recently, with the launch of Android Honeycomb, did full disk encryption make an appearance on Android. Encrypting and decrypting user data on the fly, i.e., during read and write operations, boosted device security considerably, based on a device master key.

Prior to Android Lollipop, the aforementioned master key was based on the user’s password only, opening it up to a host of vulnerabilities through external tools like ADB. However, Lollipop carries out full disk encryption at the kernel level, using a 128bit AES key generated at first boot, which works in tandem with hardware-backed authentication like TrustZone, ridding it of the ADB vulnerability.

Hardware vs Software Encryption

Disk encryption can be done at two different levels, namely, at the software level or at the hardware level. Software encryption uses the CPU to encrypt and decrypt data, either using a random key unlocked by the user’s password, or by using the password itself to authenticate operations. On the other hand, hardware encryption uses a dedicated processing module to generate the encryption key, offloading the CPU load and keeping the critical keys and security parameters safer from brute force and cold boot attacks.

In spite of newer Qualcomm SoCs supporting hardware encryption, Google opted for CPU-based encryption on Android, which forces data encryption and decryption during disk I/O, occupying a number of CPU cycles, with device performance taking a serious hit as a result. With Lollipop’s mandating full disk encryption, the Nexus 6 was the first device to bear the brunt of this type of encryption. Shortly after its launch, numerous benchmarks showed results of a regular Nexus 6 versus a Nexus 6 with encryption turned off using modified boot images, and the results were not pretty, showing the encrypted device far slower than the other. In sharp contrast, Apple devices have supported hardware encryption since the iPhone 3GS, with the iPhone 5S going on to support hardware acceleration for AES and SHA1 encryption backed by its 64bit armv8 A7 chipset.

Encryption and the Nexus lineup

Last year’s Motorola Nexus 6 was the first Nexus device to force software encryption on users, and the impact it had on storage read/write operations – rendering them extremely sluggish – was widely criticized. However, in a Reddit AMA shortly after the launch of the Nexus 5X and Nexus 6P, Google’s VP of Engineering, Dave Burke, stated that this time too, the encryption was software based, citing the 64bit armv8 SoCs while promising results faster than hardware encryption. Unfortunately, a review by AnandTech showed that despite a significant improvement over the Nexus 6, the Nexus 5X fared about 30% poorer than the LG G4 in a head to head comparison, despite a similar spec sheet and the usage of eMMC 5.0 on both devices.

Impact on User Experience

Despite the Nexus 6, and seemingly the Nexus 5X, suffering from disk I/O issues due to encryption, software optimizations in Lollipop made up in the performance department, which rendered the Nexus 6 on Lollipop with full disk encryption arguably faster than a theoretical Nexus 6 running KitKat. However, end users with an eagle-eye may occasionally notice a slight stutter when opening disk-intensive apps like the gallery, or when streaming local 2K or 4K content. On the other hand, encryption significantly secures your personal data and protects you from programs like government surveillance, with the slight stutter being the only trade-off, so if that’s something that you can live with, encryption is definitely the way to go.

OEMs and Encryption

Despite device encryption being an overarchingly benevolent mechanism for end users, some OEMs sporadically view it in a less than favorable light, the most notorious among them being Samsung. The South Korean OEM’s Gear S2 smartwatch and its mobile payments solution, Samsung Pay, are incompatible with encrypted Samsung devices… with the former refusing to work and the latter disallowing users from adding cards, informing users that full device decryption is required for their functioning. Given that encryption increases device security manifold, blocking users from adding cards is a seemingly bizarre move, with security being a major deciding factor in the adoption of mobile payment solutions.

Is it really needed?

For most users, especially the group excluding power users, encryption is something that they’re not likely to stumble upon, much less enable willingly. FDE certainly secures device data and protects it from surveillance programs, albeit with the slight performance trade-off. While Android Device Manager does a decent job wiping data on devices that have fallen into the wrong hands, encryption takes the security barrier one step forward, so if the performance compromise is one you’re willing to take, FDE undoubtedly keeps your data out of the wrong hands.

What do you think about device encryption? Do you think Google should go the hardware encryption route? Do you have encryption on, and if so, are you facing any performance issues? Share your thoughts in the comments section below!