To contribute to the online documentation of Android, I wish to share what I learned encrypting an Android device using File-based Encryption based on fscrypt.
Note that this process is complicated and requires profound experience. I cannot promise that my observations are reproducible or apply to most devices (however, the provided information should apply to a large quantity of Samsung devices). Moreover, this is not a typical step-by-step guide, so please do not treat it as such. Use your expertise and make your own decisions.
The described methods are incomplete because I lack a complete understanding of the Android encryption system. Nonetheless, I could not get help from XDA members, so here are my ideas. It took me multiple days of work to figure things out, so I wish to spare you some time trying to interpret a black box.
Android phones encrypt your data by default and rarely need manual encryption.
As someone owning a device (Samsung; Android 10) barely supported by the Android Developer Community, I used a TWRP build without support for loading the fscrypt decryption keys. Therefore, I chose to use an unencrypted phone for a while since it is easier to maintain when there is no easy way to access your data.
Now that my values have shifted, I decided to encrypt my device, but due to the lack of documentation and decryption/encryption support, I had to discover a strategy myself.
Ignored Deception: A Leftover Trap Hidden by Default
The initial motivation came to me after I saw an encryption option in the system setting of my phone, leading me to believe it was as simple as clicking a button and letting my phone be for the rest of the night while it encrypted the data. In actuality, I woke up to my device's alarm the next day, even though the whole screen was still covered by an overlay, stating that my device was in the process of encrypting.
I knew something was off, considering there should be no reason to retain processes that could interfere with the encryption procedure. Thus,
I investigated the running processes, software logs, system load, and Android system properties, even digging into the source code of Android's system settings. Albeit the linked source code is probably not on par with my OEM's software, it seems like the code threw an exception on line 2399 and did not clear the overlay. In conclusion, this broken option probably still exists because all newer models are encrypted by default, hiding this option.
A similar issue arises when using the CLI (vdc cryptfs enablefilecrypto), failing on my device without explanation.
Android is running Linux - therefore, processes may continue running when their executable file gets deleted, as compared to Windows, where you have direct file-locking of executables. Hence, my basic idea was to overwrite the /data partition (holding all the user data) while it is mounted and the fscrypt keys are loaded. Of course, this is not the perfect solution and will lead to issues with the running system, but another pass with rsync should fix a potential dirty state.
Essentially, we first create a backup of the existing partitions, especially the data partition. Then, we wipe out the user data, letting the system set up a new encrypted install to use as our encrypted volume. And then, we create a backup of the data partition, transfer our files while the encrypted system is running, and retain the necessary files so the device can load the fscrypt keys.
Figuring out the last part was the hardest - searching through the Internet, doing trial and error, and even using a "scientific approach" comparing two encrypted installs with and without password protection, comparing the files created or modified.
Before doing a backup, I suggest clearing the lock screen password to force the use of the default synthetic password. My backup was password protected, and migrating the keystore was hard to figure out.
I advise to create either an nandroid backup or copy the files using rsync.
TWRP uses a unique tar specification and requires a little more care - a simple cat data.f2fs.win??? | tar xvfi - might cause trouble. I have found that libtar-twrp is a good choice for extracting the archives. All you need to do is extract every archive one by one.
The rsync option is likely better because, in the following steps, it will be the only way to restore the data.
To perform an rsync backup - the device requires a ssh server running as root. The setup of an SSH server is straightforward when using the Magisk module MagiskSSH. An SSH server is preferable because ADB and SCP (without rsync) do not preserve permissions, and MTP is unstable, faces the same permission problems, and cannot access the data partition. It is advisable to install MagiskSSH before the backup, because when issues arise the system may be inspected through SSH.
I forwarded SSH over USB because it improves the transfer speed. Also, make sure to provide permission preserving options to rsync.
adb forward tcp:2222 tcp:22
rsync -ravPEUW --delete-after -e 'ssh -p 2222 -i id_rsa' root@127.0.0.1:/data/ ./data/
The above command creates a speedy backup of the data partition. Make sure to back up your other partitions (ex. keydata) as well - good practice.
In addition, note that the backup of /data/media (as excluded by the TWRP backup method) and your external micro SD cards are equally as important. I will not mention restoring them, so make sure to remember yourself.
I advise against wiping through TWRP because on Samsung, for instance, this may lead to a boot loop with the message "Starting Android...". A wipe through the OEM recovery will not.
Make sure to perform the changes to the system that will default to an encrypted state. In my case, I replace encryptable=ice with fileencryption=ice in /vendor/etc/fstab.qcom in the userdata line.
After deleting the data, you should now set up your fresh device. Do not pay too much attention because this install will get overwritten anyway. We only care about the fscrypt-protected directories. It is of utmost importance that you do not set a lock screen password because this will enforce a synaptic password locked by the keystore, which is hardly transferable.
While doing experiments to figure out how to restore a password-protected install, I noticed that all it probably takes is setting up a lock screen and clearing it again. I assume this was the main change that configured the device into a state where restoring a password-protected install would not cause trouble. I am uncertain about this, but this was the only change that suddenly made it work.
The experiments I did helped me understand parts of what differentiates a (un)encrypted and (non-)password-protected install on a file level:
| Path | Encryption | SP-Protection |
|---|---|---|
/data/system/locksettings.db |
No difference between encryption states. | The key sp-handle only exists when password-protected and differs between installs. |
/data/misc/keystore/user_0/ |
- | The files .masterkey, 1000_USRPKEY_synthetic_password_*, and .1000_chr_USRPKEY_synthetic_password_* exist when sp-protected. |
/data/system_de/0/spblob/ |
- | This directory only exists when the device is sp-protected. |
/keydata/ |
Relevant files are only created when the device is encrypted. | The files encrypted_key, keymaster_key_blob, secdiscardable, and stretching exist no matter what but differ depending on sp-protection status. The file salt only exists if the device is sp-protected. |
/data/system/users/0/settings_global.xml |
The key require_password_to_decrypt only when encrypted and sp-protected. |
The key require_password_to_decrypt only when encrypted and sp-protected. |
Files labeled tzstorage |
Only exists on unencrypted devices. | - |
If I had not found the aforementioned method, I would have tried to temporarily remove the keydata, disable the synthetic password, and restore the keydata in the hopes that it would fix the dirty state since the files in keydata are probably assumed to be encrypted by the synthetic password.
Note: sp refers to synthetic password and is enabled when the device is locked by a password. The password is used for wrapping the synthetic password.
In terms of the keystore, I read that /data/smc/user.bin exists on Texas Instruments devices (source 8.4 AndroidKeyStore on TI devices. I am unsure if this information helps anyone, but just in case you are searching for the meaning of the file.
To proceed, overwrite the data partition with your old files using rsync (while the device is unlocked). Awesome, now all your data is restored.
The device will assume a default synthetic password since this installation is not password protected.
After a reboot, you should now set up a password since this is the mediator key for decrypting your phone after it boots.
If you accidentally deleted the relevant spblob files for the WiFi authentication, I suggest you reboot into the recovery, mount the system, edit the build.prop, adding ro.adb.secure=0 and ro.debuggable=1, and forwarding the SSH port.
I am incredibly sorry if the last step did not work for your device and you cannot get past the lock screen. If everything fails, you should be able to restore your original device by reverting the system changes and flashing your nandroid backups.
I genuinely hope this helps somebody.