Android Information Encryption in depth

Introduction

Following our latest presentation on the Titan M, the safety chip made by Google for his or her Android smartphones, we obtained a request from somebody who had damaged their system. Whereas the primary SoC gave the impression to be lifeless, the Titan M was nonetheless working, due to this fact they had been asking if they might recuperate the information in storage. Sadly, that was not doable, because the major SoC has a essential position within the encryption schema. Nonetheless, this query aroused our curiosity and was the start line for this analysis.

We began asking ourselves how an attacker with entry to a variety of software program vulnerabilities can defeat the Android knowledge encryption. Particularly, what parts of the OS needs to be focused? How can a number of bugs be chained collectively, and what occurs when safety chips are concerned? And most significantly, what’s the position of the person’s credentials? To reply these questions, we put in place two PoCs exploiting essential recognized vulnerabilities, focusing on the 2 mechanisms for authentication: one counting on TrustZone with the Gatekeeper Trusted Software, and the opposite one counting on safety chips with Weaver. Whereas hardware- or cryptographic-based approaches could possibly be thought of as properly, this analysis is concentrated on software program assaults solely.

We offered a chat primarily based on this work at REcon’23, you will discover the slides here.

Background on Android FBE

On this weblog submit, we give attention to knowledge encryption at relaxation. In brief, this characteristic permits to by no means retailer recordsdata in plaintext, to forestall attackers from with the ability to learn them by merely extracting the storage system. As an alternative, recordsdata are mechanically decrypted on the fly when loaded in reminiscence (e.g., by a textual content editor), and encrypted once more when written again to disk. That is made doable because of OS assist, and traditionally Android has used two strategies: full-disk encryption (FDE) and file-based encryption (FBE). Since Android 10 the latter is required, and there exist many assets explaining the variations between the 2, for these . Within the following part, we go over the small print of FBE.

Because the identify suggests, File-Based Encryption works on the file degree. That’s, every file has its personal key and will be decrypted independently from different ones. Android depends on a Linux kernel characteristic to realize this, known as fscrypt, supported in varied file methods equivalent to Ext4 and F2FS. We don’t dive into the implementation particulars themselves, as they don’t seem to be wanted for this analysis, however the upstream documentation provides an ideal overview for readers. So far as we’re involved, we have to know that after deriving a grasp key for the listing tree, the system retrieves separate keys for recordsdata, directories, and symbolic hyperlinks. Due to this fact, from a conceptual viewpoint, we’re fascinated with recovering the system grasp key that enables to unlock the listing the place all person’s knowledge is saved (i.e. the /knowledge folder).

Because of the file-level method, FBE permits to realize very exact granularity. Android leverages this to divide recordsdata into two encryption ranges^:

• Machine Encrypted (DE): recordsdata can be found proper after boot;
• Credential Encrypted (CE): recordsdata are solely out there after the person has authenticated (that is the extent of alternative for person knowledge).

The DE secret is mechanically derived when booting the system. Given this and the kind of knowledge it protects, it isn’t notably fascinating from an attacker’s viewpoint. It’s, nonetheless, value noting that that is on the base of the Direct Boot characteristic, permitting to unlock some options of the system (alarms are sometimes used for instance) earlier than the person has authenticated.

Nonetheless, since an attacker most likely has the purpose to retrieve personal knowledge, our major focus goes to the CE key. The steps to derive it are quite complicated, and the process begins from some DE-protected recordsdata owned by system (underneath /knowledge/system_de/<uid>/spblob). Within the following sections we scope right down to some elements of this derivation, however to answer instantly to one in all our preliminary questions, person credentials are immediately used. That’s, the uncooked bytes of the ultimate key are literally derived from these of the credentials. Although there may be a lot of steps in between, which means that no matter what number of vulnerabilities an attacker can leverage, they nonetheless must bruteforce the credentials to feed them into the important thing derivation course of.

CE key derivation with TrustZone

The image above exhibits schematically how the totally different parts wanted to derive the CE key are chained collectively. As we talked about beforehand, it’s a quite complicated process, so we advise opening the image in a separate tab if you wish to zoom into a number of the steps. For units that don’t characteristic safety chips, the “components” for key derivation come from two totally different protected parts:

• recordsdata owned by privileged customers (system or root): regular customers can not entry them;
• TEE-protected keys: these keys can solely be used contained in the TEE, by the Keymaster software. These keys are additionally authentication-bound, to allow them to solely be used when the person has efficiently authenticated.

That is already guiding us towards how an attacker would wish to assault the schema: they need to each have the ability to escalate privileges and tamper with the trusted execution surroundings, to both extract the keys or have the ability to use them earlier than authentication. Allow us to give attention to the second half, and specifically, on how authentication works with Gatekeeper.

Authentication with Gatekeeper

Gatekeeper is likely one of the Trusted Purposes (TA) which can be all the time present in TEEs. By speaking with the corresponding Android daemon (and the {Hardware} Abstraction Layer), it performs a essential position in validating the person’s credentials for authentication. Notice that Gatekeeper is just concerned in authentication through PIN/password/sample, whereas different TAs are used to assist biometrics. Nonetheless, the primary time a person authenticates when booting their system, they can not use biometrics, and the reason being exactly linked to knowledge encryption.

Gatekeeper implements two conceptually easy instructions: Enroll and Confirm. Enroll is often known as when a person first units an authentication issue, or after they change it. The command takes a so-called password (pwd) blob, indicators it, and returns it, turning it right into a password deal with. Password blobs are created from the credentials, that are first stretched utilizing scrypt (extra particulars on that beneath), then mixed with a hashed string. The important thing used to signal the supplied password is inside to Gatekeeper, and important to confirm the credentials when wanted. Such a characteristic is carried out by – not surprisingly – the Confirm command, which is as an alternative known as at any time when the person tries to authenticate. Because the identify suggests, it verifies if the password blob for the present authentication try is a legitimate one. It does so by computing its HMAC and evaluating it with the unique password deal with, which can also be despatched with the command.

Scrypt is a key derivation operate that on this context is used to decelerate customized {hardware} assaults, by requiring a major quantity of reminiscence. Its parameters are saved in a file, along with the credentials’ salt. This quite simple step implies a negligible delay for every authentication try, however incredibly slows down an attacker who must undergo it many instances. That is in the end additionally our bottleneck, as we later present in our proof-of-concepts.

If authentication is profitable, Gatekeeper creates an authentication (auth) token. This can be a signed token of normal format (as specified within the AOSP), designed to forestall replay assaults. This token proves that the person has authenticated, and must be despatched to the Keymaster TA to unlock an authentication-bound key. If as an alternative the authentication try fails, Gatekeeper’s throttling mechanism kicks in, to make bruteforcing inconceivable. That is implementation-dependent, however typically the TA shops details about the time of every failed request, and begins returning errors when the frequency of such failed requests turns into suspicious. The counters are reset when the person efficiently authenticates once more.

Artificial Password

As soon as the person has authenticated, the system has a legitimate applicationId. This must undergo just a few extra steps, earlier than truly turning into the CE key. The primary and extra fascinating one for us is the one behind the derivation of the Artificial Password. As soon as this has been retrieved, there are nonetheless a lot of additional steps, which nonetheless don’t require something from the person or from some trusted parts.

The artificial password is saved on the Android file system and must be decrypted with two totally different keys. The primary one is a daily key saved within the Android Keystore, which is TEE-protected and authentication-bound. Since these keys can by no means go away the TEE, they’re saved in encrypted kind and should be decrypted contained in the Keymaster TA. Along with that, as described beforehand, they will solely be used if the command additionally accommodates an auth token that was beforehand generated by Gatekeeper (and that’s nonetheless legitimate). As soon as the primary decryption has been carried out (within the TEE), the intermediate buffer is decrypted once more, utilizing the hashed applicationId as key. Notice that AES right here is finished utilizing GCM mode: if one thing went incorrect with the important thing, the operation fails as a result of mismatching tag. Hold this in thoughts, because it seems to be helpful later.

At this level, there are basically three issues an attacker wants to realize to recuperate the CE key. First, they want to have the ability to retrieve recordsdata owned by privileged customers, seemingly with a kernel exploit that chains a number of vulnerabilities. Then, in addition they need to tamper with the TEE, both leaking the required keys from Keymaster, or attacking the credential validation and auth token technology in Gatekeeper. Lastly, they should carry out the bruteforce with the obtained info.

PoC for Gatekeeper

As soon as we understood how we needed to proceed, we began searching for recognized vulnerabilities in units with out safety chips. By studying some on-line blogs devoted to customized ROMs and Android tweaks, we ended up discovering a tutorial that was citing MTKClient (by Bjoern Kerler – @viperbjk) because the software for use. As quickly as we learn what the tutorial allowed customers to do, we understood that there was no approach anybody might obtain that with out exploiting some vulnerabilities. Certainly, MTKClient exploits some Boot ROM bugs impacting a number of Mediatek SoCs: by doing so, it permits to learn/write all of the partitions and bypass safe boot. That was precisely what we had been searching for, with the additional benefit of being very straightforward to make use of and dealing nearly out of the field (kudos to the creator for that!). By patching the entire boot chain, we are able to root the system, and likewise substitute the unique TAs with customized ones, making our assault doable. To elucidate how we did that although, we have to present some particulars on the Mediatek boot course of.

Mediatek boot course of

We carried out our PoC on the Samsung A22 system (extra exactly on the A226B and the A225F). These units are utilizing two susceptible SoCs from Mediatek: MT6769V and MT6833V, which will be exploited utilizing MTKClient. This software interacts with the Obtain Mode (much like the EDL mode on Qualcomm SoCs), which exposes a USB interface that’s initially used to carry out assist operations on it (equivalent to flashing the firmware). To set off the bug, bodily entry is required, and on some units (such because the A225F) two pins should be shorted on the system PCB to enter Obtain Mode. As soon as the system is booted in the best mode, the software exploits the boot ROM vulnerability, then modifies BL2 (known as preloader within the Mediatek boot schema) to disable the following safe boot test, and at last masses it on the system and boots on it.

To mount our assault, we have to patch the next parts:

• the following bootloader, BL3, which is named Little Kernel (shorted as LK), to disable the Android Verified Boot checks as we wish to boot modified Android pictures;
• the Android system (in our case the boot picture), to grant ourselves root entry, and to change the Gatekeeper Trusted Software, which is current within the vendor partition;
• the TEE OS, known as TEEGRIS, to disable the verification of the Trusted Purposes.

Rooting Android

To root Android, we’re utilizing the notorious Magisk, which patches the boot picture to embed some binaries that present root entry to purposes (and to the shell person). It additionally disables the verification of Android pictures (apart from boot that’s verified by Little Kernel) carried out by dm-verity.

Nevertheless, Magisk had just a few limitations for our use case, for which we needed to make some modifications to the model we’re utilizing:

• It often comes as an software for use on an Android system. In our case, we wished to make use of it immediately from our laptops.
• It asks the person to grant root entry when requested by any software by a immediate on the display screen. We are not looking for this, as we’re nonetheless not in a position to unlock the system once we want root entry.

One very last thing we carried out in Magisk is somewhat characteristic to mechanically bind (by the mount syscall) recordsdata from the SPU partition (which was empty on each units) into the Android filesystem. This little trick was a great way for us to keep away from taking part in with the dynamic partitions, which appear to lack the instruments to control them. Certainly, the tremendous.img partition is a dynamic partition, and as such accommodates a number of logical partitions together with system, vendor, and others.
To exchange the Gatekeeper TA with the one we patched, we merely must create a brand new file within the SPU partition, following the identical listing tree construction: the init program from Magisk then mounts it at boot instead of the present one. This methodology has the benefit that it makes it easy to exchange any file, since we simply must put it within the SPU partition replicating the listing tree.

As soon as that is carried out, we now have root entry on the system that we are able to use to entry the recordsdata concerned within the CE Key derivation.

Patching TEEGRIS

TEEGRIS is the TrustZone OS designed by Samsung that may be discovered on each Exynos and Mediatek SoCs. Its design and reverse engineering have been lined many instances already, so we focus solely on the elements we have to patch to realize our purpose: execute a modified TA. In our case, we determined to patch Gatekeeper, to bypass the deal with verification and all the time produce legitimate auth tokens.

TEEGRIS is split in a number of pictures:

• tee1.img: it accommodates the Arm Trusted Firmware (which is executed in monitor mode with the best privileges – EL3), the Safe World kernel, and a binary known as userboot.so. This final one is sort of vital for us, as it’s used to load and confirm the basis filesystem of TEEGRIS.
• tzar.img: that is the basis filesystem of TEEGRIS, saved in a customized archive format that has been reversed engineered. It accommodates libraries that can be utilized by different libraries but additionally by the TAs, and binaries together with one known as root_task, that’s in command of verifying and operating the TAs supplied by Android.
• tremendous.img which is the Android major partition containing a number of logical partitions. Certainly one of them is the seller partition and accommodates a lot of the TAs, together with Gatekeeper.

To sum up, we have to patch the userboot.so binary to disable the verification of the TZAR. Then we patch the root_task to disable the verification of the TAs. So we are able to lastly patch Gatekeeper.

Patching Gatekeeper

Gatekeeper is used to confirm the person’s credentials. The verification makes use of a Key Derivation Perform (KDF) to provide a novel worth that may then be in comparison with the anticipated worth handed as argument. Within the Trusty TEE implementation, the KDF is definitely an HMAC utilizing an inside secret key. For TEEGRIS, the KDF appears to be a customized one apparently implemented within the crypto driver and, a minimum of on exynos-based units, counting on the interior crypto processor.

If the credentials match, Gatekeeper generates an auth_token and sends it again to Android, in order that it may be connected to the Keymaster requests. As a reminder, that is wanted for Keymaster to decrypt authentication-bound keys, such because the encrypted artificial password.
Right here there are a number of choices, however we determined to patch the comparability between the 2 values to verify any credentials are accepted. That is doable as a result of the auth_token technology mechanism doesn’t use any bits from the credentials. Because of our modification, each time we enter some credentials Gatekeeper generates the token and returns success, making the system consider it may transfer ahead with the following steps to unlock the system. For certain it isn’t have the ability to decrypt the person knowledge with incorrect credentials. However earlier than attempting that, the Keymaster activity has to carry out the primary decryption of the Artificial Password (which is encrypted twice).

Following this method, we are able to leak the results of this primary AES decrypt operation. The system is rooted, and utilizing Frida we are able to hook the system_server course of that’s requesting this operation in SyntheticPasswordCrypto.decryptBlob. With this worth retrieved, we now have every part wanted to begin brute forcing the credentials.

Bruteforcing the credentials

We will summarize the bruteforce as the next pseudo-code:

pwd = generate new password
token = scrypt(pwd, R, N, P, Salt)
Application_id = token || Prehashed worth
key = SHA512("application_id" || application_id)
AES_Decrypt(value_leaked_from_keymaster, key)

Right here the parameters of scrypt and the prehashed worth are retrieved from the recordsdata which can be system encrypted. The value_leaked_from_keymaster, because the identify counsel, is the worth we leaked with Frida.
Because of the GCM mode of operation used behind this AES_Decrypt operate, the decryption fails if the secret is the incorrect one, and we all know we have to choose one other password. If it succeeds, it means we discovered the best worth.

Efficiency-wise, our bruteforcing script will be undoubtedly improved. Within the video above, we had been operating it on our machine; we observed a major enchancment even by merely shifting it to a reasonably highly effective VM. Utilizing devoted {hardware} would make the distinction right here, however it isn’t the purpose of our PoC, the place we quite put the give attention to the steps required to make bruteforcing truly doable in any respect.

CE key derivation with Safety chip

The image above exhibits how the CE secret is derived when a safety chip is used. The schema is sort of much like the one offered within the earlier half, with the primary distinction {that a} new part known as Weaver has been launched and is used within the technology of the applicationId.

Authentication with Weaver

Weaver is a characteristic that depends on a safety chip to retailer pairs of keys and values. Every pair is assigned to a novel slot. It exposes a quite simple API of three commands:

• learn: present a slot quantity and a key in enter, and obtain the related worth if the secret is appropriate;
• write: present a slot quantity, a key and a price to be saved;
• getConfig: retrieves the config info for this implementation of Weaver.

Equally to Gatekeeper, Weaver implements a throttling mechanism, that kicks in after a number of failed learn makes an attempt.

When a safety chip is obtainable, the token produced with scrypt is was a Weaver key, which is then despatched to the safety chip, together with the slot quantity that’s saved in a device-encrypted file (/knowledge/system_de/<uid>/spblob/<deal with>.weaver). If the important thing and the slot match, the safety chip sends again the worth, which is then hashed to provide what we known as within the schema above the hashed secret.

Lastly, the token and the hashed secret are mixed to provide the applicationId. From there the CE key derivation is similar as what’s offered within the Gatekeeper schema.

PoC for Weaver

Weaver is a comparatively latest addition to the Android world, as safety chips have gotten more and more fashionable in increasingly more units. At Quarkslab, we spent fairly a while working with the Titan M chip, that was launched by Google with the Pixel 3. For a complete introduction to this subject, you may take a look at our first whitepaper, in addition to the Black Hat EU ’21 discuss (video, slides), the place we first publicly offered our analysis.

As soon as we grew to become acquainted with this part, we spent a while investigating learn how to do vulnerability analysis on it (Black Hat USA ’22 video, slides). We managed to search out an fascinating bug, that was later assigned CVE-2022-20233, which we exploited to acquire code execution on the chip. In case you are fascinated with a full write-up of the exploit, you will discover it here in our weblog. As soon as we obtained code execution on the chip, we created an arbitrary learn primitive, to have the ability to extract something we wished on the chip’s reminiscence. Notice that that is the best impression that we are able to look for, as a lot of the safety supplied by these chips is said to the safety of varied forms of secrets and techniques.

Weaver keys and values are saved within the flash and accessible through such a learn primitive. The one problem is to search out the best addresses. We first reverse engineered the Weaver activity to get a greater understanding of how these are computed, after which we went for some trial and error. Our software to speak with the Titan M – nosclient – was very useful right here: we used it so as to add new entries and attempt to leak them with our exploit. Additionally because of the truth that the Weaver key we’re searching for consists of 16 random bytes (which stand out when surrounded by null ones), we managed to acquire it with out too many difficulties.

Additionally for this proof-of-concept, we have to acquire root privileges on the Software Processor. We did it by rooting the system utilizing Magisk, whereas a real-world assault must depend on one (or a number of) vulnerabilities affecting the kernel. Having mentioned that, our exploit can be utilized to mount an identical assault because the Gatekeeper one, utilizing a barely totally different technique to begin bruteforcing the credentials. In observe, we proceed as follows:

pwd = generate new password
token = scrypt(pwd, R, N, P, Salt)
key = SHA512("weaver_key" || token)
Evaluate with leaked Weaver key

Conclusion

Android Disk Encryption is certainly an fascinating characteristic to play with. The primary takeaway ought to most likely be on how solidly designed the schema is total: by combining a number of items coming from totally different parts, it requires an attacker to have very highly effective vulnerabilities to defeat it. Trusted chips assure a fair increased safety degree, by including a further goal to be attacked, with a restricted assault floor. And nonetheless, even after acquiring all of the required bits, the credentials should be bruteforced. Whereas customized {hardware} can overcome the constraints imposed by scrypt, a really lengthy passphrase stays very exhausting to guess.

An enormous because of our colleagues at Quarkslab for proofreading this text and to OffensiveCon for letting us use this cool picture generated from the title of our discuss.

If you need to be taught extra about our safety audits and discover how we will help you, get in touch with us!