Tel Aviv University scholars have revealed information of now-patched “serious” design defects in Samsung devices. The bug, which affected around 100 million Android-based smartphones, may have allowed the extraction of private encryption keys.
The flaw stems from Samsung’s implementation of a component of the Android Trusted Execution Environment. TEEs (Trusted Execution Environments) are secure zone that provides an isolated environment for Trusted Application execution (TAs). To ensure confidentiality and integrity, these TAs perform security-critical functions. An examination of the cryptographic design and implementation of Android’s hardware-backed Keystore revealed the flaws.
The flaw was discovered in Samsung’s flagship Galaxy S8, S9, S10, S20, and S21 devices by researchers Alon Shakevsky, Eyal Ronen, and Avishai Wool. The vulnerability would have made even newer devices like the S21 vulnerable to initialisation vector reuse attacks.
How Samsung made its own encryption vulnerable?
To comprehend what went wrong with Samsung’s implementation of Android’s cryptographic security, we must first understand the Android operating system’s design.
The top-level Android OS is separated from the TrustZone on ARM-based Android smartphones, which is pretty much all of them. TrustZone is a dedicated piece of hardware that houses a Trusted Execution Environment (TEE) and a TrustZone Operating System (TZOS). To perform security-related operations, this zone employs Trust Applications (TAs).
Android must submit a request to the TZOS whenever an Android app needs to do something with user authentication or other aspects of device security. “The implementation of the cryptographic functionalities within the TZOS is left to the device vendors,” the researchers said. The vendors create undocumented proprietary designs.”
Samsung uses a hardware abstraction layer to connect the user-facing Android side (also known as the regular world) with the secure world of the TEE. This layer uses APIs to communicate data between the Android and TEE worlds. In Samsung devices, an app called Keymaster TA manages the hardware abstraction layer.
The function of Keymaster TA
In the real world, Keymaster TA has a safe key storage room where it keeps keys in blob form. They’re encrypted for storage in the real world, and the Keymaster TA decrypts and re-encrypts them.
An initialisation vector is used to perform the actual decryption (IV). It’s effectively a randomised number that serves as the decryption operation’s starting point. These numbers are supposed to be generated in the TEE, randomised and unique, and kept in the normal world to make them more challenging to decipher. According to the research, this is not the case with the aforementioned Samsung handsets.
Researchers revealed that Samsung allows the app-layer code (which runs on the regular side) to choose the IV key, making decrypting them simple.
As a result, an attacker might inject their own IVs into key parameters, forcing the Keymaster TA to use their rather than a random one. This is referred to as an IV reuse attack because it allows attackers to spoof keys, decrypt allegedly protected data, and otherwise gain unauthorised access to a device.
Furthermore, the researchers discovered that their discoveries might be utilised to evade a website’s passwordless authentication scheme. The attacker can intercept the website’s key generation request, change it with an IV reuse attack, and then authenticate with the stolen private key on the website.
Remedial Measures
In a nutshell, successful exploitation of the weaknesses in the Keymaster TA could allow unauthorized access to TEE-protected keys and data. The consequences of such an assault could range from an authentication bypass to advanced attacks that can compromise cryptographic systems’ core security guarantees.
“Vendors like as Samsung and Qualcomm keep their implementation and design of TrustZone operating systems and TAs under wraps,” according to the researchers. “Independent researchers should audit and review the design and implementation details, rather than relying on the difficulties of reverse engineering proprietary systems.”
Endnote
The security patches fixed the flaws. They were distributed in August and October 2021 for the impacted devices, following responsible disclosure in May and July 2021. The results will be presented later this month at the USENIX Security Symposium.
