It seems that Android's "full-disk-encrytpion" is only concerned about encrypting the data or internal storage partition. It says:

Full-disk encryption is the process of encoding all user data on an Android device using an encrypted key. Once a device is encrypted, all user-created data is automatically encrypted before committing it to disk and all reads automatically decrypt data before returning it to the calling process.

I am puzzled what encryption (at rest) of user-data is worth, if an attacker can simply modify the content of the /system partition, to contain a malware that would exfiltrate data or encryption key.

Is there a reason to consider Android's encryption to be effective even though /system partition is not encrypted?

I assume that an answer involves a chain-of-trust, relative to a locked boot loader.

  • /system is read-only, and what's stored there is stored there on all devices of the same brand/model running on the same Android version – so what do you want to protect there? "System data" (configuration etc) is stored on /data together with the user data. So if that's what's been encrypted (and AFAIK it is), it's encrypted along.
    – Izzy
    Jan 20, 2019 at 18:47
  • Follow this link to know about Android's verified boot process. android.googlesource.com/platform/external/avb/+/master/…
    – Firelord
    Jan 21, 2019 at 4:56
  • @Izzy I was perfectly able to retrieve data from encrypted /data partition, by simply modifyng (i.e. by inserting an app in /system/app), being that /system is not encrypted made this easier. Jan 21, 2019 at 8:00
  • @humanityANDpeace what Device, android version, and chip set where you able to do that to?
    – Bo Lawson
    Jan 21, 2019 at 12:16
  • 2
    @Izzy with an unlocked boot loader, hence implied root, correct. The question however, was exactly as provided in the answer, the information that the security of /system is not via encryption, but boot-chain lock. Jan 21, 2019 at 21:40

3 Answers 3


It looks like Google agrees with you and is phasing out "legacy" full disk encryption:

Caution: Support for full-disk encryption is going away. If you're creating a new device, you should use file-based encryption.

Full disk encryption was considered pretty solid until 2016 because of the hardware backed trusted execution environment. Depending on how the OEM implements the trusted execution environment and if the OEM utilizes the android keystore system. Makes a varying degree of security. If instead it is software backed then not so much.

The encryption keys are not just sitting in some un-encrypted partition. The encrypted encryption key is stored in th e crypto metadata. The hardware backed trusted execution environment’s signing capability and if the android keystore system is implemented then the android device as a whole and even the android kernel do not have access to the keymaster within trusted secure enviroment. The keystore system is very intresting but explaining the security and operations behind it involves a multiple page explaination that would be answered best though its own question. 

Android devices that support a lock screen and ship with Android 7.0 or higher have a secondary, isolated environment called a Trusted Execution Environment. This enables further separation from any untrusted code. The capability is typically implemented using secure hardware.

Examples of the way a trusted execution environment can be set up are:

A separate virtual machine, hypervisor, or purpose-built trusted execution environment like ARM TrustZone. The isolated environment must provide complete separation from the Android kernel and user space (non-secure world). This separation is so that nothing running in the non-secure-world can observe or manipulate the results of any computation in the isolated environment.

Android 9.0 introduced a hardware backed trusted execution environment called a strongbox. The strongbox is a completely separate, purpose-built and certified secure CPUs. Examples of StrongBox devices are embedded Secure Elements (eSE) or on-SoC secure processing units.

A hardware backed trusted secure environment that utilizes the android keystore system can serve as strong protection for the encrypted encryption key. Unless a third party such as Qualcomm (2016) happens to mess up with design oversite in the implementation of the keymaster.

  • "Full-disk encryption was considered pretty solid until 2016" — Could you give a reason as to why it's not considered solid anymore? I'm asking in particular because the way I understand the Android docs, file-based encryption was not introduced because of security concerns (if we disregard that FBE also separates multiple users from one another through encryption) but because full-disk encryption didn't allow alarms and other apps to work right after boot without user input.
    – balu
    May 7, 2019 at 23:03
  • As for /system not being encrypted by FDE – the way I understand the docs, /system is still not getting encrypted under the new FBE scheme but only user data, so OP's concerns still apply.
    – balu
    May 7, 2019 at 23:05
  • 1
    @balu yes I can, if you consider compromising the trustzone by exploiting Qualcomm's small kernel running within to load the attackers own custom QSEE (Qualcomm Secure Execution Environment) app within the secure environment which then can exploit a privilege escalating flaw which will allow us to gain code execution thus hijacking the space so to utilize an exploit that extracts Qualcomm's KeyMaster keys. Feom those keys use the keys generated for full disk encryption. Using the FDE keys to brute force the password, pin, or lock crack/decrypy the device retrieving the data protected within.
    – Bo Lawson
    May 9, 2019 at 0:10
  • 1
    Security researcher Gal Beniamini has discovered and provided proof of concept step by step guide on 06/2016. bits-please.blogspot.com/?m=1 -- github.com/laginimaineb you missed the security update bulletin Docs source.android.com/security/bulletin/2016-05-01.html
    – Bo Lawson
    May 9, 2019 at 0:16
  • 1
    Well explained answer, but I was hoping to see why /system isn't encrypted. No notion of VB or AVB or dm-verity. Explanation is on merits of FBE and demerits of FDE. FBE uses the same TEE and same KeyStore/KeyMaster that FDE used (with minor differences in implementation). /system is protected with dm-verity, an entirely separate kernel framework. Integrity of dm-verity depends on AVB at SoC/bootloader level. The same is true for FBE (DE). Android is using TEE for hardware-backed keys since Lollipop. Implementations have emerged over time: QSEE, Trusty, Kinibi, TEEGris, iTrustee etc. Sep 7, 2019 at 10:07

/boot, /system, /vendor, /vbmeta and ODM Partitions are protected by android verified boot (AVB). They are not encrypted but their integrity is verified during boot. Any modification to these partitions will halt the boot flow and brick the device. At this point without EDL mode, you won't be able to flash stock OS to unbrick it.

AVB verifies vbmeta partition image using OEM public key which is hardcoded in android bootloader (ABL). Then hash of boot image is calculated and compared with the hash stored in vbmeta. Once the boot image is verified, kernel constructs hashtree of every partition and compares their root hash with the ones that are stored in vbmeta. In this way, just by protecting vbmeta, every other partition can be verified on boot.

To protect ABL from tampering (e.g. replacing OEM public key with your own and resigning vbmeta with your private key, thus breaking chain of trust), chipmakers implement secure boot. In Qcom devices, Primary Bootloader (PBL) which is burned on CPU die, verifies Xtended Bootloader (XBL) using Qcom's public key which is stored in eFuse. Then Xtended Bootloader verifies ABL and ABL enforces AVB.

When you unlock bootloader (unlock and unlock_critical), AVB is not enforced but secure boot is still enforced by SoC. This chain of trust goes upto the hardware level making any modification useless. There's no reason to encrypt system partitions as those images are already public. What matters is protection of their integrity.


a quick check on Samsung Galaxy Tab S3 SM-T820 Tablet with official Android 9 Pie indicates that /system is encrypted with FDE

:/ $ df -ah
Filesystem                            Size  Used Avail Use% Mounted on
rootfs                                1.5G  9.4M  1.5G   1% /
tmpfs                                 1.7G  1.1M  1.7G   1% /dev
devpts                                   0     0     0   0% /dev/pts
none                                     0     0     0   0% /dev/cpuctl
none                                     0     0     0   0% /dev/cpuset
proc                                     0     0     0   0% /proc
sysfs                                    0     0     0   0% /sys
selinuxfs                                0     0     0   0% /sys/fs/selinux
debugfs                                  0     0     0   0% /sys/kernel/debug
tracefs                                  0     0     0   0% /sys/kernel/debug/tracing
pstore                                   0     0     0   0% /sys/fs/pstore
tmpfs                                 1.7G     0  1.7G   0% /mnt
tmpfs                                 1.7G     0  1.7G   0% /mnt/secure
/dev/block/dm-0                       3.7G  3.5G  245M  94% /system
/dev/block/bootdevice/by-name/apnhlos    0     0     0   0% /system/vendor/firmware_mnt
/dev/block/bootdevice/by-name/modem      0     0     0   0% /system/vendor/firmware-modem
/dev/block/bootdevice/by-name/dsp      12M  4.1M  7.6M  36% /system/vendor/dsp
none                                     0     0     0   0% /acct
none                                     0     0     0   0% /config
/dev/block/bootdevice/by-name/cache   193M  8.8M  184M   5% /cache
/dev/block/bootdevice/by-name/efs      16M  720K   15M   5% /efs
/dev/block/dm-1                        24G   13G   11G  56% /data
/data/knox/secure_fs/enc_user          24G   13G   11G  56% /data/enc_user
/data/knox/secure_fs/enc_media         24G   13G   11G  56% /data/knox/secure_fs/enc_media
tmpfs                                 1.7G     0  1.7G   0% /storage
/data/media                            24G   13G   11G  57% /storage/emulated
/mnt/media_rw/4280-3E71                60G  4.8G   55G   9% /storage/4280-3E71
tmpfs                                 1.7G     0  1.7G   0% /storage/self
:/ $
  • 2
    That's dm-verity, not dm-crypt (FDE). Both are targets of Linux kernel's Device Mapper framework, but serve different purpose. Feb 13, 2020 at 10:39
  • please downvote, i will leave answer for reference. can you elaborate?
    – alecxs
    Feb 13, 2020 at 10:44
  • 1
    Linux kernel's DMCrypt vs. DMVerity. Android's FDE vs. Verified Boot Feb 13, 2020 at 10:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .