One: Introduction to encryption:
Encryption is the process of encoding all user data on the Android device using a symmetric encryption key. After the device is encrypted, all data created by the user will be automatically encrypted before being stored on the disk, and all read operations will automatically decrypt the data before returning the data to the calling process. Encryption ensures that unauthorized parties cannot read the data when they try to access it.
Android has two device encryption methods, namely file-level encryption and full disk encryption.
1 ) Full Disk Encryption (FDE) : Android 5.0 to Android 9 support full disk encryption . Full disk encryption uses a single key (protected by the user's device password) to protect the entire user data partition of the device. At startup, users must provide their credentials before they can access any part of the disk.
Although this encryption method is very helpful to ensure security, it also means that when the device is restarted, the user cannot immediately use most of the core functions of the phone. Due to the protection of this single user's credentials, the system cannot access the user's data, so functions such as alarm clocks will not work, accessibility services will not be available, and mobile phones will not be able to answer calls.
2 ) File-level encryption (FBE) : Android 7.0 and higher versions support file-level encryption . When file-level encryption is used, different keys can be used to encrypt different files, or encrypted files can be decrypted separately. Devices that support file-level encryption can also support direct startup . When this feature is enabled, the encrypted device will directly enter the lock screen after startup, allowing users to quickly use important device features, such as accessibility services and alarm clocks.
With the introduction of file-level encryption and APIs that can set applications as encryption-aware applications, applications can run in restricted environments. This means that applications can run before the user provides credentials, while the system can still protect private user information.
3 ) Android 9 introduced support for metadata encryption with hardware support. When metadata encryption is used, a single key that appears at startup will encrypt anything that is not encrypted by FBE (such as directory layout, file size, permissions, and creation/modification time). The key is protected by Keymaster, and Keymaster is protected by the verification function at startup.
2: Introduction to File Encryption FBE:
Android 7.0 and higher versions support file-level encryption (FBE). When file-level encryption is used, different keys can be used to encrypt different files, or encrypted files can be decrypted separately.
Precautions:
1 ) New devices with Android 10 and higher versions need to use file-level encryption .
2 ) Devices equipped with Android 9 and higher can use file-level encryption and mergeable storage devices at the same time.
3 ) For devices equipped with Android 7.0-8.1, file-level encryption and mergeable storage devices cannot be used at the same time . If file-level encryption is enabled on these devices, the newly added storage medium (such as an SD card) must be used as a traditional storage device .
Direct start
With file-level encryption, a new feature called direct launch is introduced in Android 7.0 . When this feature is enabled, the encrypted device will directly enter the lock screen after booting. Previously, on encrypted devices using Full Disk Encryption (FDE), users had to provide credentials before accessing any data, so that the phone could only perform the most basic operations. For example, mobile phones cannot even answer calls, they can only perform basic emergency dialing operations, alarm clocks cannot operate, and accessibility services are not available.
With the introduction of file-level encryption (FBE) and new APIs that can set applications as encryption-aware applications, these applications will be able to run in restricted environments. This means that applications can run before the user provides credentials, while the system can still protect private user information.
On FBE-enabled devices, each user has two storage locations available for applications:
Credential Encrypted (CE) storage space, which is the default storage location and is only available after the user unlocks the device.
Device encryption (DE) storage space, which can be used in direct boot mode and after the user unlocks the device.
This separation can make work data more secure, because in this way, encryption is no longer based only on the activation password, which can protect multiple users at the same time.
Direct Boot API allows encryption-aware applications to access any of the above storage spaces. There will be some changes in the application life cycle so that the system will notify the application in the following situations: when the user's CE storage space is unlocked by the user's first input of credentials on the lock screen, or when the work profile provides a work profile security inquiry . Regardless of whether FBE is implemented or not, devices equipped with Android 7.0 must support these new APIs and life cycles. However, if FBE is not enabled, the DE and CE storage space will always be unlocked.
The Android Open Source Project (AOSP) provides a complete implementation of file-level encryption in Ext4 and F2FS file systems. On devices that meet the relevant requirements, you only need to enable the implementation to use this feature. Manufacturers who choose to use FBE may want to learn how to optimize this function based on the system-on-chip (SoC) used.
All necessary packages in AOSP have been updated to directly start-aware packages. However, if device manufacturers use customized versions of these applications, they need to ensure that there is at least a direct launch-aware package that can provide the following services:
1 ) Telephone service and dialer
2 ) The input method used to enter the password on the locked screen
Examples and sources
Android provides a reference implementation of file-level encryption, where vold ( system/vold ) is responsible for providing functions for managing storage devices and storage volumes on Android. Adding FBE will provide some new commands for vold to support key management of CE keys and DE keys for multiple users. In addition to the core changes to use the file-level encryption feature in the kernel, many system packages (including the lock screen and SystemUI) have also been modified to support FBE and "direct boot" functions. These options include:
AOSP dialer (packages/apps/Dialer)
Desktop Clock (packages/apps/DeskClock)
LatinIME (packages/inputmethods/LatinIME)*
" Settings" application (packages/apps/Settings)*
SystemUI (frameworks/base/packages/SystemUI)*
* System applications that use the defaultToDeviceProtectedStorage inventory property
Enable file-level encryption
To enable file-level encryption (FBE) on the device, you must enable FBE on the internal storage device (userdata). This will also automatically enable FBE for mergeable storage devices; however, if necessary, you can override the encryption format of mergeable storage devices. The internal storage device can enable FBE by adding the fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] option to the fs_mgr_flags column of the fstab row of userdata. This option is used to define the encryption format of the internal storage device. It contains up to three parameters separated by colons:
Android10：ext4 fileencryption=ice,
Android11：f2fs fileencryption=aes-256-xts:
- The contents_encryption_mode parameter specifies which encryption algorithm is used to encrypt the contents of the file, and can be aes-256-xts or adiantum.
- The filenames_encryption_mode parameter specifies which encryption algorithm is used to encrypt the file name, which can be aes-256-cts, aes-256-heh or adiantum. If not specified, the parameter defaults to aes-256-cts when contents_encryption_mode is aes-256-xts, and the parameter defaults to adiantum when contents_encryption_mode is adiantum.
- The new flags parameter in Android 11 is a list of flags separated by + characters. The following tags are supported:
- The v1 flag is used to select the version 1 encryption policy; the v2 flag is used to select the version 2 encryption policy. The version 2 encryption policy uses a more secure and flexible key derivation function . If the device is equipped with Android 11 or higher (determined by ro.product.first_api_level), version 2 is selected by default; if the device is equipped with Android 10 or lower, version 1 is selected by default.
- The inlinecrypt_optimized flag is used to select an encryption format optimized for embedded encryption hardware that cannot handle a large number of keys efficiently. The specific method is to derive only one file content encryption key for each CE or DE key instead of deriving one for each file. The generation of IV (initialization vector) will be adjusted accordingly.
- The emmc_optimized flag is similar to inlinecrypt_optimized, but it also chooses the IV generation method that limits the IV to 32 bits. This flag should only be used on embedded encryption hardware that complies with the JEDEC eMMC v5.2 specification, so only 32-bit IVs are supported. On other embedded encryption hardware, please use inlinecrypt_optimized instead. This tag must not be used on UFS-based storage devices; the UFS specification allows the use of 64-bit IVs.
- The wrappedkey_v0 flag allows the use of hardware-wrapped keys. When this flag is enabled, the FBE key will not be generated by the software, but by the Keymaster using the STORAGE_KEY tag. Then, each FBE key actually provided to the kernel is a STORAGE_KEY key derived from Keymaster, which will cause the key to be encapsulated with a temporary key every time it is started. Then, the kernel will provide the encapsulated key directly to the embedded encryption hardware. After the correct implementation, the unpacked key will never be displayed in the system memory, and the cracked package key will be unusable after restarting. This flag requires hardware support, Keymaster support for STORAGE_KEY, kernel driver support, inlinecrypt load options, and the inlinecrypt_optimized flag or emmc_optimized flag.
If you do not use embedded encryption hardware, it is recommended to set fileencryption=aes-256-xts for most devices. If using embedded encryption hardware, the recommended setting for most devices is fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized. On devices that do not use any form of AES acceleration, you can set fileencryption=adiantum to use Adiantum instead of AES.
On devices with Android 10 or lower, you can also use fileencryption=ice to specify the FSCRYPT_MODE_PRIVATE file content encryption mode. The Android common kernel does not implement this mode, but vendors can use a custom kernel patch to implement this mode. The format of the disk generated by this mode varies from vendor to vendor. On devices with Android 11 or higher, this mode is no longer allowed, and the standard encryption format must be used.
The device manufacturer can also perform the following manual tests. Perform the following manual tests on FBE-enabled devices:
- Check if ro.crypto.state exists
- Confirm whether ro.crypto.state is encrypted
- Check if ro.crypto.type exists
- Confirm whether ro.crypto.type has been set to file