Today, we carry a large part of our lives on our mobile phones: personal photos, private chats, work documents, saved passwords, banking apps… Losing your phone or having it stolen without your data being protected It can turn into a real disaster, both personally and professionally, so it's important to know how to take measures to strengthen security.
To minimize that risk, Android has for years incorporated various encryption mechanisms that go far beyond a simple PIN or unlock pattern. Disk encryption and file-based encryption, along with verified boot and hardware-protected keysThey form a complex ecosystem designed so that, even if someone has the device in their hand, they cannot read the information without the proper credentials. If you need to do so, consult How to encrypt your mobile phone.
What is data encryption on Android and why does it matter so much?
When we talk about encrypting an Android device, we are referring to the process of transform all stored data into unreadable information If you don't have the correct key. In practical terms, it's like putting all the contents of your phone inside a digital safe that can only be opened with your PIN, pattern, password, or biometric factor.
This encryption protects both personal data (photos, videos, messages, downloaded files) and corporate data. In business environments, it is a key element for complying with regulations such as the European GDPR or HIPAA in the USA.This greatly reduces the risk of data leaks if a terminal containing customer information, medical records, legal documents, or internal VPN access credentials is lost or stolen. Furthermore, maintaining backup It prevents the loss of the device from resulting in the total loss of information.
It's worth noting that a screen lock alone isn't enough. A PIN without encryption only prevents someone from using the phone's interface, but If the storage is not encrypted, an attacker could physically extract the data. copying the contents of the memory using forensic tools or bootloader vulnerabilities. Additionally, using a Prey security app It can help locate and manage a lost or stolen device, complementing encryption.
With encryption enabled, the storage is saved in a mathematically incomprehensible format without the key. Even if someone copies the data partition byte by byte or boots a modified systemWhat you'll get are just meaningless blocks of encrypted data.
From full disk encryption to file-based encryption
Historically, Android has gone through two major approaches to device encryption: full disk encryption (FDE) and file-based encryption (FBE)Understanding the difference helps a lot in understanding what is being protected at any given time and why certain functions continue to work even when the phone is "locked".
Full disk encryption was introduced in Android 4.4 (API 19), and gained real traction with Android 5.0 (API 21). In this model, The entire user data partition is protected with a single keyThat key is derived from the user's credentials, so the system cannot access anything in /data until you enter your PIN, pattern, or password at startup.
This approach is very robust from a privacy standpoint, but it has a clear drawback: virtually the entire system remains inoperative until it is unlocked for the first time after startupThere is no access to alarms, many services do not start, and the phone cannot even receive normal calls, only emergencies, because the telephone layer does not yet have access to its data.
To solve this problem, Google redesigned the entire encryption scheme in Android 7.0 Nougat (API 24), introducing file-based encryption (FBE). In this model, Each file can be protected with a different key.This allows different parts of the system to be unlocked independently depending on which credential has been provided.
FBE also brings the so-called mode of Direct BootThis allows the device to boot directly to the lock screen and allows some apps to function in a limited context before the user enters their PIN or password.
How Direct Start mode and CE/DE separation work
The key conceptual change in FBE is that, on a file-based encryption device, Each system user has two separate storage areaswith different keys and different unlocking times.
The first one is Credential-encrypted storage (CE)This is the default storage location for user and application data, and it is only unlocked after the user enters their credentials upon startup. This is where all truly sensitive data should be stored: app databases, personal documents, local email backups, etc.
The second is the Device-encrypted storage (DE)This area is available both in Direct Boot mode (before the user logs in) and after, and is encrypted with a device-bound key that is available as soon as the system starts successfully. It's the area intended for data that needs to be accessible even before the first unlock: basic notifications, phone services, some accessibility features, alarm apps, or the lock screen login method.
Ideally, if an app needs to function before the user unlocks the device (for example, an alarm clock or a telephone dialer), only store in DE what is strictly necessary for that basic function, and keep any personal or critical information in CE.
In fact, Google's recommendation is clear: Whenever possible, the files should reside in CE.DE storage is intended for minimal configurations and ephemeral data, not for sensitive content such as full contact lists, chat histories, or company documents.
Technical requirements and the mandatory nature of encryption in modern Android
Android 7.0 allows FBE, and from Android 10 onwards Google requires it All devices released with that version or later will use file-based encryptionOn phones without hardware AES encryption acceleration, the Adiantum algorithm is used to maintain good performance.
To properly implement FBE, the manufacturer must meet several low-level requirements. On the one hand, the The device's Linux kernel must support the fscrypt file system encryption layer. For ext4 or F2FS (the two common options for /data in Android). In modern kernels, simply enable options like CONFIG_FS_ENCRYPTION and, if you want to take advantage of inline encryption, CONFIG_FS_ENCRYPTION_INLINE_CRYPT.
It is also necessary to have KeyMint or at least Keymaster 1.0And with Gatekeeper, running within a Trusted Execution Environment (TEE). This way, the encryption keys linked to the device and the user are protected from unauthorized operating systems and modified kernels that attempt to boot with the bootloader unlocked.
The device must also have a hardware root of trust and a verified boot This is linked to the KeyMint initialization process, preventing unauthorized access to device encryption (DE) keys. In other words, even if modified firmware is flashed, the security hardware refuses to release the keys if the boot chain is not legitimate.
At the configuration level, FBE encryption is enabled by editing the device's fstab file for the userdata partition. An option is specified there. fileencryption=… which defines the content encryption algorithm (usually aes-256-xts or Adiantum), the file naming algorithm (aes-256-cts, aes-256-heh, aes-256-hctr2 or adiantum) and a series of optional flags (v1/v2, inlinecrypt_optimized, emmc_optimized, wrappedkey_v0, dusize_4k).
Which parts of the system are encrypted and how are the keys organized?
In an Android system with FBE properly configured, /data is organized in different “storage classes” depending on the key that protects them and the moment they become accessible.
There are directories that are not encrypted with FBE (although in many cases they are encrypted with metadata encryption), such as /data/apex (except for some subdirectories), /data/lost+found, /data/preloads or /data/unencrypted. These are paths where system components or structures that do not need to be linked to user credentials are stored.
Then there's the class of System ofThis category groups encrypted data per device that does not belong to a specific user: /data/app, /data/misc, /data/system, /data/vendor, and other subdirectories of /data. There is also a "per_boot" class (/data/per_boot) for ephemeral files that do not need to persist across reboots.
Specific CE and DE routes are created for each user: /data/user/${user_id}, /data/system_ce/${user_id}, /data/misc_ce/${user_id}, /data/vendor_ce/${user_id} For internal CE; and /data/user_de/${user_id}, /data/system_de/${user_id}, /data/misc_de/${user_id}, /data/vendor_de/${user_id} for internal DE. If adoptable storage is present (SD card transformed into an extension of internal memory), similar structures are replicated under /mnt/expand/${volume_uuid}/.
Key management is handled by vold, the Android volume daemon. Vold manages FBE keys and stores them encrypted on disk (except for the "on boot" key, which is derived each time and is never saved). For example, the internal user CE and DE keys are stored in /data/misc/vold/user_keys/ce/${user_id} and /data/misc/vold/user_keys/de/${user_id}, respectively, protected in turn by keys stored in Keystore within the TEE.
Except for internal storage CE keys, the rest of the FBE keys are wrapped with AES-256-GCM using Keystore keys that do not leave the secure environment. In addition, techniques such as rollback resistance and "secdiscardable" files are used. to ensure that deleting a key is truly permanent, even against attempts to restore previous system states.
Relationship between screen lock, synthetic password, and CE keys
Internal storage CE keys have an additional level of protection, because they are the ones that actually prevent an attacker, even with control of the system, from decrypting your data without your password. Android introduces the concept of synthetic passwords here.: a high entropy secret, randomly generated by the system for each user, which is never entered directly, but is protected with the PIN, pattern or lock password (LSKF).
The LockSettingsService service, on system_server, manages that synthetic password. When you set up or change your PIN or screen passwordThe system takes that LSKF, passes it through scrypt (to harden it somewhat) and uses it to interact with Weaver or Gatekeeper, depending on the device's hardware.
On Weaver-enabled devices, the hardened LSKF is associated with a high-entropy random secret stored in a secure element (SE) or the TEE. The synthetic password is then encrypted twice: first with a key derived from the LSKF and Weaver secret, and then with a keystore key. This introduces a hardware-enforced attempt rate limit to guess the password, preventing quick brute-force attacks.
On devices without Weaver, the hardened LSKF is used with Gatekeeper, and again the synthetic password is first encrypted with a key derived from the LSKF and a throwaway file, and then with a Keystore key linked to authentication in Gatekeeper. The result is that CE keys cannot be unlocked without overcoming those protections.even if an attempt is made with a modified system or an alternative boot.
When you change your PIN or lock password, LockSettingsService It removes the previous link between LSKF and synthetic password.On devices with reverse resistance support, this prevents the reuse of old associations, further reinforcing the security model.
Is encryption still protected with an unlocked or rooted bootloader?
This brings us to one of the points that generates the most debate among advanced users. In theory, a "well-designed" encryption system shouldn't be broken just because the bootloader is unlocked. or because you obtain an ADB shell with root privileges: as long as you do not have the key derived from the user's password, the data should remain unreadable.
In practice, the modern Android model seeks two things: on the one hand, that CE keys cannot be obtained without the LSKFThis is thanks to the combined use of TEE/SE, Gatekeeper/Weaver, and Keystore; and also because verified boot blocks access to DE keys if an untrusted system is detected. However, there are important nuances.
One of them is that, on devices with FBE, Some of the content in /data may be available in DE even before entering the PINThis includes internal structures, auxiliary files, and even certain directories in /data/misc, /data/system, or similar locations that, although encrypted on disk, are decrypted after boot because the DE key is available without user interaction.
In some real-world experiments, it has been observed, for example, that on a Moto X4 with LineageOS 16 (Android 9), active FBE, and SD card enabled, /data already appears mounted when you reach the lock screenFrom an ADB root shell, some specific files can be extracted without entering the password. Others, however, fail or appear inaccessible, indicating that they are correctly bound to CE.
Even more serious is that, if the permits and policies are not properly adjusted, It is possible to read certain keys associated with adoptable volumes from /data/misc/vold, such as the encrypted SD card. With that key, it's possible to mount and decrypt the volume outside the phone, rendering the card's encryption useless.
These types of situations are not so much a flaw in the design of FBE itself, but implementation errors or insecure configurations In custom ROMs, modified recoveries, or devices where the manufacturer hasn't followed all the recommendations (for example, not properly isolating who can access /data/misc/vold, not applying SELinux in strict mode, or not properly separating the data that should go in CE). Review and adjust the security settings helps to reduce these risks.
Why do Spotify, YouTube, or notifications still work when my phone is locked?
A very common question among users is: if “everything is encrypted” when I lock my phone, How come notifications are still going off, Spotify is still working, or messages are still being received? while the screen is off and the device is seemingly protected?
The key lies in the FBE model and the distinction between screen lock state and storage unlock state. After the first unlock following boot, most CE keys remain available as long as the device is not restarted.Locking the screen does not re-encrypt everything from scratch; it simply closes logical access to the interface and certain APIs, but the system still has the keys in memory to be able to operate.
Furthermore, much of the data needed by apps like Spotify, YouTube, or push notification services is stored or replicated in DE zones, or the apps are marked as “directBootAware” for to be able to function with a limited subset of data while the user has not yet entered the PIN after a restart. That's why you can, for example, receive a call or hear an alarm even if the phone has just turned on and you're still on the initial lock screen.
Decryption doesn't literally take "1 second"; what happens is that The heavy lifting has already been done during startup and the first unlocking.From then on, the system keeps the keys active (until the next restart) so as not to have to recalculate everything continuously, which would make the user experience unbearable.
This means that if an attacker gains elevated privileges once the device has already been unlocked after a boot (for example, through root malware or a kernel exploit), He could access much more information than if he tried to do it right after turning on the device, before anyone enters the PIN.That's why it's so important force restart a device before handing it over to border controls, repair technicians, or other sensitive situations, and do not unlock it again.
What can and can't system apps do with Direct Boot
With the arrival of FBE, Android introduced new APIs and manifest attributes so that apps know What encryption state is the device in? and what storage they have available at any given time.
In an app's manifest, two relevant attributes can be declared: android:directBootAware and android:defaultToDeviceProtectedStorage. The first indicates that all app components are aware of the encryption and can function during Direct Boot mode; the second makes the app, by default, use DE storage instead of CE for its data.
System apps marked with defaultToDeviceProtectedStorage must carefully audit what information is stored in that location. and move any data that could be considered personal or sensitive to CE. Manufacturers are responsible for not transferring extensive histories, contact lists, or user data to DE, but rather limiting themselves to the minimum configurations necessary for the device to be functional before the first unlock.
To better handle these contexts, Android provides methods such as Context.createCredentialProtectedStorageContext() and Context.isCredentialProtectedStorage(), which allow apps to explicitly choose where to store or read their data based on encryption status and privacy needs.
On multi-user devices with work profiles, things get even more complicated: Each user and each job profile has their own CE and DE keys. App permissions Features like INTERACT_ACROSS_USERS or INTERACT_ACROSS_USERS_FULL allow certain system apps to interact between users, but can only access the CE of those who are already unlocked, adding another layer of isolation.
SD card encryption and adoptable storage: strengths and weaknesses
When you use an SD card as adoptable storage, Android treats it as an encrypted extension of internal memory. The card is encrypted with a key that, in principle, only the device itself should be able to use., and that key is stored encrypted along with other volume keys under paths such as /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} or /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid}.
Since Android 9, FBE and adoptable storage have been fully supported, and from Android 11 onwards, the way of defining content and metadata encryption formats is unified through system properties such as ro.crypto.volume.options or ro.crypto.volume.metadata.encryption. In previous versions, separate properties were used for content modes and filenames, and on many devices the default value for names on adoptable volumes was not recommended, so it had to be explicitly adjusted.
In an ideal world, even if someone removes the SD card, The data should remain inaccessible without the key stored on the phone.But again, if that key can be extracted from /data/misc/vold with a root shell because the device is misconfigured, the model collapses. This demonstrates why simply "enabling encryption" in theory is not enough: it must be accompanied by sound SELinux policies and careful permission design.
For SD cards used as traditional (non-adoptable) external storage, many manufacturers offer an "encrypt SD card" option from Settings > Security. Normally, this encryption ensures that only that specific device can read what's on the card.The process may take more or less time depending on the size and speed of the SD card, but once completed, if you insert the card into another phone or computer, the contents will appear unreadable. In addition to this, it's also advisable to keep cloud backups to ensure that information is not lost if the card fails.
Even so, if the key approach is not properly tied up, Extracting the SD card key from the phone itself could allow it to be decrypted externally.Therefore, in high-security contexts, many companies recommend not using adoptable SD or limiting their use only to non-critical data.
Encryption, performance, and potential drawbacks
Encryption has a computational cost: reading or writing encrypted data involves operating with algorithms such as AES-256-XTS or Adiantum. On modern devices with hardware cryptographic acceleration (for example, ARMv8 CE extensions on ARM64), the impact on performance and power consumption is very small and almost imperceptible.
To maximize performance, common Android kernels include a framework of inline encryptionThis allows certain storage controllers (UFS, eMMC) to encrypt and decrypt data "in flight." Enabling options such as CONFIG_BLK_INLINE_ENCRYPTION, CONFIG_SCSI_UFS_CRYPTO, or CONFIG_MMC_CRYPTO, along with flags like inlinecrypt_optimized or emmc_optimized, helps minimize overhead and extend battery life.
On older devices or those without accelerated AES support, the penalty may be more noticeable, hence Google will design AdiantumThis is a scheme designed to offer strong security on modest hardware. Even so, some users may experience a slight drop in performance, especially if encryption is manually enabled on a low-end device.
Another point to keep in mind is that, Once storage is encrypted, there is usually no going back without a factory reset.The disk encryption format is defined by options like `fileencryption` in `fstab` and cannot be changed with a simple over-the-air (OTA) update. If you want to disable encryption, the typical solution is to delete the data partition and start from scratch.
In older versions of Android, some traditional OTA updates required access from the recovery partition to data located in /data, which is not possible if that area is protected by DE. In those cases, certain manufacturers opted for leave a top-level directory unencrypted (for example, /data/misc_ne) exclusively to store update packages, controlling with SELinux that only the update process could access them.
Beyond these technical considerations, for the average user the main “drawback” of encryption is that, If you forget your PIN or password and there are no recovery mechanisms, the information is lost forever.There is no official backdoor: without the LSKF and without being able to derive the synthetic password, CE keys cannot be recovered.
Ultimately, this entire framework makes disk encryption and the protection of sensitive data on Android much more sophisticated than it appears at first glance. Between FDE and FBE, the CE and DE spaces, the TEE, KeyMint, Gatekeeper, fscrypt, metadata encryption, and verified bootThe system is designed so that an unauthorized attacker, even if they have the device in their hands and try to boot modified software or use ADB with root access, will find it extremely difficult to read anything useful without the user's password, provided that the manufacturer has followed the recommendations and the user complements this with a strong lock, up-to-date updates, and common sense when installing applications.
