Crypto Bug in Samsung Galaxy Devices: Breaking Trusted Execution Environments (TEEs)

Crypto Bug in Samsung Galaxy Devices: Breaking Trusted Execution Environments (TEEs)

If you use an Apple Macbook, it’s likely that you have a secret enclave for important secrets — such as your encryption keys. These keys define the core of the trust infrastructure on the device — and protect applications from stealing these secrets. The TEE also allows isolation between code which is fully trusted, and code that cannot be fully trusted. If this did not happen, we could install applications on our computer which would discover our login password and steal the encryption used used to key things secret and trusted.

On many cloud-based systems, too, we protect our most important secrets within Trusted Execution Environments (TEEs). Normally encryption keys are stored in the secure enclave and where trusted code operates on these. The encryption keys are then never exposed to other applications running within Rich Execution Environments (REEs).

In Figure 1, the TEE stores the actual encryption key that is used to encrypt data or digitally sign it. The applications which run in the REE will never see this code, as only trusted code can access the key. When an application then wants to encrypt or sign something, it presents the wrapped key and the data, and the TEE code will perform the trusted code and return back the encrypted or signed content:

In Figure 1, we can see that there is a KEK (Key Encryption Key) and which wraps the encryption keys stored in the TEE. In this case, the REE never sees K, and only ever see the wrap/encrypted version (EKE(K)). When an application in the REE wants an operation performed on data, it passes the wrapped key to the TEE, and which will then be trusted to reveal the key to be used.

An interesting new paper shines a light on a serious bug related to this on Samsung’s Galaxy S8, S9, S10, S20, and S21 devices [paper]:

Trusted Execution Environment

Android devices use a Trusted Execution Environment (TEE) — named TrustZone Operating System (TZOS) — to run code and store data that must be separate from the main operating system. Within TZOS, vendors can create their own cryptographic code implementations (Figure 2). Normally applications that cannot be fully trusted run with Rich Execution Environments (REEs), while code for key management, Samsung Pay, and FIDO2 login are run within the TEE.

Breaking the TEE

With this, the researchers analysed the hardware backup store and reverse-engineered the cryptographic code used. They found some bad practice and where the devices were open to an IV (Initialisation Vector) reuse attack. These attacks can be applied between the TrustZone and a remote server and managed to compromise Google’s Secure Key Import from the FIDO2 WebAuthn login.

The researchers reverse-engineered the Hardware-Backed Keystore used in Samsung’s Galaxy S8, S9, S10, S20, and S21 devices, and extract encryption keys from the device. The attack was reported to Samsung in May 2021, and they since patched their systems. It is now defined in CVE-2021–25490 [here] and CVE-2021–25444 [here]:

Within the device, an application running within the untrusted area can request a key from the trust zone (Figure 3). With this, the key is wrapped to protect it from being observed in the unrusted area.

If you want to understand key wrapping, try here.

The trusted zone then returns back the encrypted key, and where the application cannot view the actual key. When the application needs something to be digitally signed or to encrypt something, the application will pass the wrapped key to the trust zone and which will then perform the operation by using the actual encryption key.

The attack involved a downgrade attack on the key generation (Figure 4), and where the trust zone returns wrapped keys for the key pair. Then there is an IV reuse for the key pair, and where the attack can generate the private key used within the keypair.

The researchers then build on this attack and illustrate a successful FIDO2 attack (Figure 4).

Conclusions

The TEE is core to trust on a system — whether it’s running on devices or in the Cloud. Any breach of this can leak trusted keys. This research paper should that while code can be kept secret, it can often be reversed, and then reveal vulnerabilities.

If you want to understand IV reuse, try here:

Reference

[1] Shakevsky, A., Ronen, E., & Wool, A. (2022). Trust Dies in Darkness: Shedding Light on Samsung’s TrustZone Keymaster Design. Cryptology ePrint Archive.