What is device encryption and why do you need it?
Learn the need for device encryption policies in the enterprise and how Hexnode helps enforce encryption on work devices.
Get fresh insights, pro tips, and thought starters–only the best of posts for you.
May 20, 2021
11 min read
Encryption for Androids can be a confusing subject, with a broad set of manufacturers and tons of device models out in the market. Depending on the operating system of the device, each of these models may follow different methods when it comes to Android encryption.
In this blog, we’ll blog provide a basic overview of the encryption technologies used on Android, the need for Android encryption, and the best practices to follow when encrypting Android devices.
Once an Android device is encrypted, the system automatically encodes all user data on the device lock. Depending on the type of encryption, the device decrypts this data only after it successfully boots up, or after the user unlocks it with the correct password/touch ID/face ID/screen lock.
Be it personal or corporate data, when using your Android device to store and access sensitive information, it is crucial to ensure that the device is encrypted. In today’s corporate environment, data breaches are on the rise. According to a 2020 data breach report by RiskBased security, almost 36 billion corporate records were breached in the first half of 2020.
Also, with employees gaining access to corporate files on their mobile devices, it becomes even more crucial to encrypt these devices. According to a 2021 financial data risk report from Varonis, nearly two-thirds of organizations have more than 1,000 sensitive files open to every employee. These figures point out the importance of setting up encryption policies in the enterprise.
It is generally safe to encrypt your Android devices. For the older device models, encrypting your Android can result in a drop in system performance. However, this performance drop becomes unnoticeable in the newer Android models. Also, it is worth mentioning that the encryption process is irreversible. Once performed, it can only be removed by a complete factory reset of the device.
Android encryption generally falls under two categories. Full-disk encryption (FDE) and file-based encryption (FBE).
Full-disk encryption (FDE) requires encoding all the data on your device, including essential apps and services, and transforming it into illegible code. This data can then be decrypted only after the user successfully unlocks the Android device after booting up. The highlight when it comes to this technique is that all the data is encrypted using a single key.
In the case of full-disk encryption, the core functionalities of your Android device – including the alarms, accessibility services, and the ability to view caller IDs when receiving calls – are restricted until the device is unlocked with the correct credentials. When compared to file-based encryption, this technique provides greater security, at the cost of user convenience.
File-based encryption (FBE) on the other hand, ensures that the essential and non-essential apps and data are separated and encrypted with different keys. When it comes to FBE, the Android system provides two types of locations for storing encrypted data.
The data in this location get decrypted only after the device completes boot up and reaches the lock screen. Only the essential apps, services and data – such as SMS apps, accessibility apps and Alarm apps – will be decrypted at this point.
The data in this location, usually comprised of user data and apps, is decrypted only after the user has successfully unlocked the device from the lock screen, with the required credentials. However, it is worth noting that once the user has unlocked the device, the apps and data stored in this location do not get encrypted for the subsequent device locks. This data is re-encrypted only after a complete restart of the device.
Device encrypted storage ensures that access to essential apps and services are made available as soon as the device is successfully booted up.
Credential based encrypted storage ensures that until the device is unlocked with the proper credentials, the user apps and data on the device remain encrypted.
Overall, file-based encryption is usually preferred over FDE for commercial Androids due to the better convenience it offers for the users.
Encryption for Android devices was introduced with Android OS version 3. However, for older models, Android encryption would have to be enabled manually. This was usually done because the encryption process for the older models would considerably reduce device performance.
With the introduction of newer models, Android devices began to be encrypted out-of-the-box. Today, any Android device with an OS version above 6, that has a legal license of GMS (Google Mobile Services), will always be encrypted out-of-the-box. These devices also support enrollment in the Android Enterprise program.
It is worth noting that any device enrolled in the Android Enterprise program must have encryption enabled mandatorily. If the device is not encrypted, the encryption process will automatically be enforced when enrolling in Android Enterprise.
Also, Android Enterprise devices with OS versions above 7, set in Profile Owner mode have the option to set up separate encryption keys for the personal and work container. This can be done by setting up a work profile password for the device.
Morden Android devices are always encrypted out-of-the-box. However, in the case of older Android models, the device may or may not be encrypted. You can check the encryption status for Android devices by navigating to Settings > Security > Encryption. This tab shows whether the device is encrypted or not. In case the Android device is not encrypted, you can enable encryption from the same tab.
Before enabling encryption, there are a few things that the user must note to maintain a smooth encryption process.
Android devices with OS versions 7 to 9, comes equipped with the feature that allows users to choose between full-disk encryption and file-based encryption techniques to implement on their device.
To choose between full-disk encryption and file-based encryption methods, you will first need to enable ‘Developer options’ on your Android mobile.
Once you are at Developer options, select the tab, ‘Convert to file encryption’, and tap on ‘Wipe and convert’. The conversion process will take about 1-2 hours to complete.
Unlike its desktop encryption counterparts like BitLocker for Windows and FileVault for macOS,
When it comes to encrypting Android devices, it is not mandatory to set up a device password.
However, the lack of a password will reduce the effectiveness of encryption on your Android device, and it is generally not advisable to set up encryption without a password.
For further clarity, let’s observe the effect of setting up a password on an encrypted Android device. We’ll consider the case for both full-disk encryption and file-level encryption solutions.
When enabling encryption using FDE, if a password is not set, the Android device is encrypted by a randomly generated key, hashed by a default password (“default_password”). This key is also signed by a trusted execution environment (TEE).
But, if a password/pattern/PIN is later set up by the user, the master key gets re-encrypted. However, no change in encryption occurs on any of the apps and user data.
In the case of FBE, files are encrypted with different keys that are unlocked separately. This includes the files in – device encrypted storage and credential-based encrypted storage.
In case a password is not set by the user, the data in credential-based encrypted storage is encrypted by a similar randomly generated key, signed by a TEE. When a password/PIN/pattern is set, this key is re-encrypted, ensuring that the encryption for apps and data remains unchanged.
When enforcing encryption for Android devices, following certain practices will ensure that your Androids are secured and managed in the best possible way.
Enforcing a strong password on your Android device is a crucial factor when setting up Android encryption. Protecting your device with a password/PIN/pattern/touch ID/face ID further strengthens the security on your Android. Hexnode’s UEM solution enables you to enforce strong password policies on your managed Android devices, thereby protecting your data from potential breaches.
Once encryption has been completed, it is necessary for enterprises to manage these encrypted devices and monitor their status periodically. With Hexnode’s UEM solution, enterprises can easily manage and view all their encrypted devices from a remote centralized console. IT can also force encryption via Hexnode when enrolling devices in Android Enterprise, and mark unencrypted devices as incompliant.
Backing up your data at regular intervals ensures that the data remains safe even in the case of a corrupted drive or a device malfunction.
Enable encryption, enforce strong passwords, monitor and manage encrypted devices and more, with Hexnode's award-winning UEM solution.TRY OUT FREE FOR 14 DAYS
Share your thoughts
Thanks for the really good blog on this subject, it’s very informative and pretty much the best guide to this subject I have found.
I’m curious though about a particular scenario which I can’t quite make sense of.
Device = NOT enterprise managed by any MDM (is BYOD/unmanaged)
Lock screen option = NOT set (no lock screen method in place)
OS = Android v6+ (any OS where encryption occurs out of the box)
Question = how does encryption provide any value? Would it just be if the device is turned off with battery dead or removed, and it gets stolen, then the thief extracts the storage chip/hardware from the device, and tries to read the data, then it would be impossible to read right?
Otherwise, every other situation where the device is able to be turned on, would mean the data is readable right?
Thank you for the wonderful compliments.
Yes, you’re right. What you’ve mentioned is exactly the case. Android encryption doesn’t offer any practical value if there is no password set. If the device is stolen, and it’s not protected with a password, the attacker can simply turn on the device, unlock it, and the data is decrypted.
In such cases of a lost device, I’d suggest using ‘Find my Device’ (https://android.com/find) to remotely lock down your phone. Here, even if the device doesn’t have a password enforced, you can remotely set one up. (Find My Device is automatically activated if you’ve added a Google Account to your device.)
Now, an MDM becomes useful when the device that’s lost belongs to one of your employees. An admin can remotely lock the device and set up a password straight from the MDM portal, without requiring the employees’ personal credentials.
I hope I’ve cleared all your queries. If not, please feel free to ping me here again.
Have a nice day Leo!