Samsung shipped '100 million' phones with flawed encryption
Academics found TrustZone-level code could not be trusted to keep secrets
Academics at Tel Aviv University in Israel have found that recent Android-based Samsung phones shipped with design flaws that allow the extraction of secret cryptographic keys.
The researchers – Alon Shakevsky, Eyal Ronen, and Avishai Wool – describe their work in a paper titled, "Trust Dies in Darkness: Shedding Light on Samsung's TrustZone Keymaster Design," which is scheduled for presentation at Real World Crypto and USENIX Security, 2022.
Android smartphones, which pretty much all use Arm-compatible silicon, rely on a Trusted Execution Environment (TEE) supported by Arm's TrustZone technology to keep sensitive security functions isolated from normal applications. These TEEs run their own operating system, TrustZone Operating System (TZOS), and it's up to vendors to implement the cryptographic functions within TZOS.
The Android Keystore, the researchers explain, offers hardware-backed cryptographic key management via the Keymaster Hardware Abstraction Layer (HAL). Samsung implemented the HAL through a Trusted Application running in the TrustZone called Keymaster TA, to carry out cryptographic operations like key generation, encryption, attestation, and signature creation in a secure environment. The results of these TEE crypto calculations can then be used in apps operating in the less secure Android environment.
The Keymaster TA stores cryptographic keys as blobs – the keys are wrapped (encrypted via AES-GCM) so they can be stored in the file system of the Android environment. In theory, they should only be readable within the TEE.
However, Samsung failed to implement Keymaster TA properly in its Galaxy S8, S9, S10, S20, and S21 phones. The researchers reverse engineered the Keymaster app and showed they could conduct an Initialization Vector (IV) reuse attack to obtain the keys from the hardware-protected key blobs.
The IV is supposed to be a unique number each time, which ensures the AES-GCM encryption operation produces a different result even when the same plain text is encrypted. But when the IV – referred to by the researchers as "salt" – and encryption key remain the same, the same output gets generated. And that sort of predictability is the bane of encryption.
"So they could have derived a different key-wrapping key for each key they protect," observed Matthew Green, associate professor of computer science at the Johns Hopkins Information Security Institute in the US, via Twitter. "But instead Samsung basically doesn’t. Then they allow the app-layer code to pick encryption IVs. This allows trivial decryption."
Our Tel Aviv University boffins found three blob formats used among the Samsung phones – v15, v20-s9, and v20-s10. The first, v15, is the default in the Galaxy S8; v20-s9 corresponds to the Galaxy S9; and v20-s10 was found in the S10, S20, and S21.
In the v15 and v20-s9 blobs, the researchers say, the salt is a deterministic function that relies on the application ID, application data, and constant strings from the Android environment. So for any given application, corresponding key blobs will be protected by the same key-wrapping key.
"Surprisingly, we discovered that the Android client is allowed to set the IV when generating or importing a key," the paper stated. "All that is necessary is to place an attacker-chosen IV as part of the key parameters, and it is used by the Keymaster TA instead of a random IV.
"As the [Android environment] also controls the application ID and application data, this means that an attacker can force the Keymaster TA to reuse the same key and IV that were previously used to encrypt some other v15 or v20-s9 blobs. Since AES-GCM is a stream cipher, the attacker can now recover hardware-protected keys from key blobs."
- You've heard of HTTPS. Now get a load of HTTPA: Web services in verified remote trusted environments?
- Embrace, Extend, and… Enclave? Microsoft guards Kubernetes' privates with TEEs
- Arms race: SiFive, Hex Five build code safe houses for RISC-V chips
More recent model Samsung devices with v20-s10 blobs are not normally vulnerable to IV reuse attacks, though the researchers found a way to conduct a downgrade attack by having the Android environment pass an "encryption version" parameter telling the device to use the vulnerable v15 blob format.
The weak crypto was also used by the researchers to bypass FIDO2 WebAuthn, a way to use public-key cryptography, instead of passwords, to register for and authenticate to websites. Their proof-of-concept attack allowed the researchers to authenticate themselves to a website protected by the Android StrongKey application. What's more, they also managed to bypass Google's Secure Key Import, designed to let servers share keys securely with Android devices.
In all, the researchers estimate 100 million Samsung devices were vulnerable when they identified the encryption flaw last year. However, they responsibly disclosed their findings to Samsung in May 2021, which led to the August 2021 assignment of CVE-2021-25444 to the vulnerability, and a patch for affected devices. In July 2021, they revealed their downgrade attack, which led in October 2021 to CVE-2021-25490 and a patch that removed the legacy blob implementation (v15) from devices including the S10, S20, and S21.
Looking ahead, the boffins argue that an encryption scheme other than AES-GCM, or an IV reuse resistant version like AES-GCM-SIV, should be considered.
Samsung did not immediately respond to a request to confirm the researchers' estimate of affected devices and to estimate how many affected devices, if any, remain unpatched. ®