Nmedia - Fotolia
What native Android encryption options should IT consider?
Android encryption has evolved over the years, and full-disk encryption isn't an option in Android 10. IT must learn the best native encryption options for managed Android devices.
It's relatively easy to manage device encryption when there are only iOS devices in a mobile fleet.
Apple provides a single encryption standard across all of the iOS devices it manufactures. Android device encryption, however, depends on the version of Android the devices run, the OEM and device model, the hardware architecture and other factors.
IT professionals should learn about native Android encryption options to protect its mobile users without spending more for third-party encryption tools.
Android's device encryption history
Android has supported some form of device encryption for quite a while now, but the documentation of this encryption is incomplete. It's difficult to determine when Google first introduced Android OS encryption and what was encrypted, but Android has supported full-disk encryption (FDE) since at least Android 5.
FDE encodes all user data in the device's user data partition. To protect the data, Android applies a single encryption key, which is tied to the user's device password. Once IT enables the encryption, Android automatically encrypts user-created data before committing it to a disk. Android automatically decrypts the data before returning it to a calling process.
With the release of Android 6, the OS started to enforce FDE by default. However, FDE comes with a serious limitation: It protects all user data with a single credential. As a result, some features are not available if users reboot their devices, but do not unlock them with their passcode. For example, alarms do not work, and users cannot receive phone calls.
To address these limitations, Google introduced file-based encryption (FBE) in Android 7. FBE makes it possible to encode different files with different encryption keys, so users can unlock the files independently. At the same time, Google introduced new APIs to enable FBE, so OEMs had to design the devices to support them if they wanted FBE compatibility.
Each user on an FBE-enabled device has two available storage locations. The first is Credential Encrypted (CE) storage, the default location. CE storage is only available after the user unlocks the device, similar to traditional FDE storage.
The other location is Device Encrypted (DE) storage, which is available in one of two ways. The first option only decrypts the data after the user unlocks the device, as with CE storage. The other option decrypts the data during Direct Boot, a boot mode that enables encryption-aware apps to operate within a limited context without compromising most of the device's private information. Direct Boot makes it possible for users to carry out certain operations without unlocking their phones, such as receive phone calls or use their alarms.
In Android 9, Google added support for metadata encryption, which encodes any content not protected by FBE, such as permissions, file sizes or directory layouts. Android encryption uses a single key to encode the content at the time of a boot. IT pros can only enable metadata encryption when they first format the data partition, which means it only applies to new devices with hardware that provides an inline cryptoengine that can support metadata encryption.
In early 2019, Google introduced Adiantum encryption for devices with Android 9 or higher and CPUs that do not provide AES instructions. These tend to be low-end devices, with basic processors that do not include AES support. Adiantum encryption likely won't apply to enterprise devices.
In September 2019, Google released Android 10, which lacks support for FDE. For modern enterprise deployments, DE and CE storage are the best native Android encryption options for IT to deploy.
