With the support of security chips, Android data encryption is becoming increasingly difficult to steal

Background of Android FBE

In this article, we will introduce and analyze static data encryption. Android FBE is the abbreviation of Android Full Disk Encryption, which is a security mechanism used to encrypt all data on Android devices to protect users' personal privacy and sensitive data.

In short, this feature allows files to never be stored in plaintext to prevent attackers from reading them by simply extracting the storage device. Instead, files are automatically decrypted when loaded into memory (for example, through a text editor) and encrypted again when written back to disk. This is thanks to the support of the operating system, and Android has historically used two methods: full disk encryption (FDE) and file-based encryption (FBE). As the name suggests, file-based encryption works at the file level. That is, each file has its own key and can be decrypted independently of other files. Android relies on the Linux kernel feature fscrypt to achieve this, which is supported in various file systems such as Ext4 and F2FS. After obtaining the master key for a directory tree, the system retrieves separate keys for files, directories, and symbolic links.

FBE implementation is very precise due to the file level approach. Android takes advantage of this to divide files into two encryption levels:

Device Encryption (DE): files are available immediately after booting;

Credentialed Encryption (CE): Files are available only after the user has authenticated (this is a select level for user data).

The DE key is automatically derived when booting the device, and considering this and the type of data it protects, it is not particularly interesting from an attacker's perspective. However, it is worth noting that this is the basis for the direct boot feature, which allows certain features of the device, such as the alarm, to be unlocked before the user is authenticated.

Nonetheless, since the attacker's goal may be to retrieve private data, this article focuses on the CE key. The steps to derive it are fairly complex and the process starts with some DE protected files owned by the system (in /data/system_DE//spblob). The raw bytes of the final key are actually derived from the raw bytes of the credential. Despite the complexity of the process, it means that no matter how many vulnerabilities an attacker can exploit, they still need to brute force the credential to feed it into the key derivation process.

Using TrustZone to derive CE keys

With the support of security chips, Android data encryption is becoming increasingly difficult to steal

The image above shows how the different components required to derive the CE key are linked together. As mentioned above, this is a fairly complex process, so we recommend opening the image in a separate tab. For devices not equipped with a security chip, the key derivation comes from two different protected components:

Files owned by privileged users (system or root): ordinary users cannot access;

TEE protected keys: These keys can only be used by Keymaster applications inside the TEE. These keys are also authentication-bound, so they can only be used if the user has successfully authenticated.

This means that an attacker should be able to escalate privileges and tamper with the trusted execution environment in order to extract the key or be able to use the key before authentication. To do this, it is necessary to understand how Gatekeeper performs authentication.

Authentication with Gatekeeper

With the support of security chips, Android data encryption is becoming increasingly difficult to steal

Gatekeeper is one of the Trusted Applications (TAs) that often appear in TEEs, and it plays a key role in verifying the user's authentication credentials by communicating with the corresponding Android daemon as well as the hardware abstraction layer. Note that Gatekeeper only participates in authentication via PIN/password/pattern, while other TAs are used to support biometrics. Despite this, when users authenticate for the first time when booting the device, they cannot use biometrics for reasons precisely related to data encryption.

Gatekeeper implements two conceptually simple commands: Enroll and Verify. Enroll is typically called when a user first sets up an authentication factor or when an authentication factor is changed. The command takes a so-called password (pwd) blob, signs it, and returns it, converting it into a password handle. The password blob is created from the credential, which is first extended using scrypt and then combined with a hash string. The key used to sign the provided password is Gatekeeper's internal key and is used to verify the credential. Such functionality is implemented via the Verify command, which is called when a user attempts to authenticate. As the name suggests, it verifies that the password blob for the current authentication attempt is valid. It does this by calculating its HMAC and comparing it with the original password handle, which is also sent with the command.

Scrypt is a key derivation function that, in this case, slows down custom hardware attacks by requiring a lot of memory. Its parameters are stored in a file along with the credential's salt. This means that the latency for each authentication attempt is negligible, but slows down attackers who need to authenticate multiple times.

If authentication is successful, Gatekeeper creates an authentication (auth) token. This is a signed token in a standard format (as specified in AOSP) designed to prevent replay attacks. This token proves that the user has been authenticated and needs to be sent to Keymaster TA to unlock the key bound to the authentication. If the authentication attempt fails, Gatekeeper's throttling mechanism kicks in, making brute force attacks impossible. This is implementation-dependent, but typically TA stores information about the time of each failed request and starts returning errors when the frequency of such failed requests becomes suspicious. When the user successfully authenticates again, the counter is reset.

Synthetic password

Once the user is authenticated, the system has a valid applicationId. There are a few more steps before it can actually become a CE key. The first and more interesting one for us is the derivation of the synthetic password. After retrieving this information, there are a few more operations, but these steps do not require any information from the user or some trusted component.

With the support of security chips, Android data encryption is becoming increasingly difficult to steal

The synthetic password is stored in the Android file system and must be decrypted with two different keys. The first is a regular key stored in the Android Keystore, which is protected by the TEE and bound to the authentication. Since these keys never leave the TEE, they are stored in encrypted form and need to be decrypted in the Keymaster TA. In addition to this, as mentioned above, they can only be used if the command also contains a verification token previously generated by Gatekeeper and is still valid. Once the first decryption is done in the TEE, the intermediate buffer is decrypted again using the hashed applicationId as the key. Note that the AES here is done using GCM mode, and if there is a problem with the key, the operation will fail due to a tag mismatch.

At this point, the attacker essentially needs to accomplish three things to recover the CE keys. First, they need to be able to retrieve files owned by a privileged user, most likely by exploiting a kernel vulnerability that contains multiple vulnerabilities. Then, they must also tamper with the TEE, either by leaking the required keys from Keymaster or attacking the credential validation and authentication token generation in Gatekeeper. Finally, they need to perform a brute force attack on the information obtained.

PoC for Gatekeeper

The researchers implemented a PoC on Samsung A22 devices (more precisely, A226B and A225F), which use two vulnerable SoCs from Mediatek: MT6769V and MT6833V, which can be exploited using MTKClient. The tool interacts with the download mode (similar to the EDL mode on Qualcomm SoCs), which exposes a USB interface that is initially used to perform support operations on it (such as flashing firmware). To trigger the vulnerability, physical access is required, and on some devices (such as the A225F), two pins must be shorted on the device PCB to enter the download mode. Once the device is booted in the correct mode, the tool exploits the Boot ROM vulnerability, then modifies BL2 (called preloader in Mediatek boot mode) to disable the next secure boot check, and finally loads it onto the device and boots on it.

With the support of security chips, Android data encryption is becoming increasingly difficult to steal

But to carry out the attack, the following components need to be fixed:

BL3, which is called a small kernel (LK for short), disables Android verified boot checks because we want to boot a modified Android image.

The Android system (in this case, the boot image), grants us root access and modifies the Gatekeeper Trusted application present in the vendor partition.

3. The TEE operating system (called TEEGRIS) disables verification of trusted applications.

Get the highest permissions of the Android system (Android Rooting)

To achieve Android Rooting, we used Magisk. To replace it with a repaired Gatekeeper TA, we only need to create a new file in the SPU partition, and then Magisk's init program will install it in the place of the existing file at boot time. The advantage of this method is that it can simply replace any file, because we only need to put it in the SPU partition where the directory tree is copied.

Once this is done we can gain root access to the device and then use it to access the files involved in CE key derivation.

Repair TEEGRIS

TEEGRIS is a TrustZone OS designed by Samsung and can be found on Exynos and Mediatek SoCs. Its design and reverse engineering has been covered many times, so this article will only focus on the parts we need to fix to achieve our goal: execute a modified TA. In this example, we decided to fix Gatekeeper to bypass handle verification and always generate valid verification tokens.

TEEGRIS is divided into several images:

tee1.img: It contains the Arm Trusted Firmware (executed in monitor mode with the highest privileges - EL3), the Secure World kernel and a binary called userboot.so. The last one is very important for us because it is used to load and verify the root file system of TEEGRIS.

tzar.img: This is the root filesystem of TEEGRIS, stored in a custom compression format for reverse engineering. It contains libraries that can be used by other libraries but also by TA, as well as binaries, including one called root_task that is responsible for verifying and running the TA provided by Android.

super.img: It is the main Android partition that contains several logical partitions. One of them is the vendor partition, which contains most of TA, including Gatekeeper.

With the support of security chips, Android data encryption is becoming increasingly difficult to steal

In summary, we need to fix userboot. So the binary disables verification of TZAR. Then, we fix root_task to disable verification of TA, so that we can finally fix Gatekeeper.

Fixing Gatekeeper

Gatekeeper is used to verify the user's credentials. Verification uses a key derivation function (KDF) to generate a unique value that can then be compared to the expected value passed as a parameter. In the Trusty TEE implementation, the KDF is actually an HMAC using an internal key. For TEEGRIS, the KDF appears to be a custom one, apparently implemented in the crypto driver, which, at least on Exynos-based devices, relies on the internal crypto processor.

If the credentials match, Gatekeeper generates an auth_token and sends it back to Android so that it can be attached to the Keymaster request. It is important to note that this is required for the Keymaster to decrypt the authentication-bound key, such as the encrypted synthetic password. There are several options here, but we decided to fix the comparison between the two values ​​to ensure that any credential is accepted. This is possible because the auth_token generation mechanism does not use any bits from the credentials. Thanks to the modification, every time we enter some credentials, Gatekeeper generates the token and returns success, making the system believe that it can proceed to the next step to unlock the device. It is certain that it cannot decrypt user data with the wrong credentials. But before trying, the Keymaster task must perform the first decryption of the synthetic password (it is encrypted twice).

With the support of security chips, Android data encryption is becoming increasingly difficult to steal

We can follow this approach to steal the result of the first AES decryption operation. The device is rooted and using Frida we can pause the system_server process that requested the operation in SyntheticPasswordCrypto.decryptBlob. Once we have retrieved this value we can start brute forcing the credentials.

Brute-forcing credentials

The brute force code is as follows:

With the support of security chips, Android data encryption is becoming increasingly difficult to steal

Retrieve the parameters for scrypt from a file encrypted on the device. As the name suggests, value_leaked_from_keymaster is the value we stole with Frida. Due to the GCM mode of operation used behind this AES_Decrypt function, if the key is wrong, decryption will fail and we know we need to choose another cipher. If successful, it means we found the correct value. Click here for a video.

The brute force script could certainly be improved in terms of performance. As mentioned above, even simply moving it to a general purpose VM resulted in significant improvements. Using dedicated hardware would make a difference, but that is not the focus of our PoC, we would rather focus on the process required to achieve brute force execution.

Using the security chip to derive the CE key

With the support of security chips, Android data encryption is becoming increasingly difficult to steal

The figure above shows how to derive the CE key when using a secure chip. The pattern is very similar to the one introduced in the previous section, with the main difference being that a new component called Weaver is introduced and used to generate the applicationId.

Authentication with Weaver

Weaver is a service that relies on a secure chip to store keys and values, with each value assigned to a unique slot. It exposes a very simple API consisting of three commands:

Read: Provides a slot number and a key in input and receives the associated value if the key is correct;

write: Provide the slot number, key, and value to be stored;

getConfig: Retrieve configuration information for a Weaver implementation.

Similar to Gatekeeper, Weaver implements a throttling mechanism that takes effect after multiple failed read attempts.

With the support of security chips, Android data encryption is becoming increasingly difficult to steal

When the security chip is available, the token generated using scrypt is converted to a Weaver key, which is then combined with the key stored in the device encrypted file (/data/system_de/

Finally, the token and hash key are combined to generate the applicationId, from which the CE key is derived which is the same as provided in the Gatekeeper schema.

Weaver’s PoC

Weaver is a relatively new addition to Android as security chips become more prevalent in more and more devices. At Quarkslab, researchers have spent a lot of time working on the Titan M chip that Google introduced in the Pixel 3.

Summarize

Android disk encryption is definitely a breakthrough feature, and its security is airtight. The designers have combined the functions of different components to protect the Android system data very well. Attackers can only launch attacks by finding very powerful vulnerabilities. In addition, the trusted chip has raised the security level to a new level.

This article is translated from: https://blog.quarkslab.com/android-data-encryption-in-depth.html If reproduced, please indicate the original address