Full disk encryption vulnerabilities discovered in Qualcomm-powered Android devices
Independent security researcher Gel Beniamini recently discovered a vulnerability in Android's full-disk encryption (FDE) on devices with Qualcomm chips, even newer ones used in flagship models. In a blog post published Thursday, Beniamini outlines how crypto keys could be extracted from a locked handset via a brute-force attack.
The problem lies in both the hardware and software compartments, as Android stores the disk encryption keys in software, which makes them vulnerable to extraction on Qualcomm-powered devices due to two oversights in ARM's TrustZone – hardware-based security built into SoCs by semiconductor chip designers before they are distributed to the device manufacturers. The blog post also includes the exploit code capable to execute code within the TrustZone kernel and thus, to extract cryptographic keys, which can then be cracked in numerous different ways.
Beniamni also goes over Apple's approach to FDE, which is apparently pretty good at keeping your data safe. We are going to take a more summarized look at both systems.
Each iDevice has a unique 256-bit key that cannot be modified, called a Unique Identification Number (UID). It is randomly generated and basically fused in to the device's hardware at the factory. This key is bound to the device's hardware and is completely inaccessible to both software and firmware, meaning that even Apple cannot extract it from the device once it's been set. The UID is also used in combination with the user's password, in order to generate an encryption key which effectively “tangles” the device-specific key and the user's password. This complicates the matters for would-be attackers a lot, as it necessitates the use of the device itself for each cracking attempt, which in itself allows Apple to introduce a myriad of other measures – such as an incrementally increasing delay between subsequent password guesses – to further mitigate brute-force attacks.
Android's FDE on the other hand, is based on a Linux Kernel subsystem called dm-crypt, which is widely deployed and researched, which is definitely a good thing. The system is actually quite robust with its encryption scheme, but is unfortunately only as strong as the encryption key employed to protect the information. In short, a device running Android 5.0 or later generates a random 128-bit master key and a 128-bit salt key. The master key is protected by an elaborate key derivation scheme, which involves the user's unlock credentials to derive a key which ultimately decrypts the master key. The master key is then stored on the device, inside a special – and unencrypted – structure called the “crypto footer”, and which can be extracted in a number of different ways. It's not that simple, granted, but it's possible, since the key derivation is not hardware bound.
The worst part is, Beniamini claims, that patching TrustZone vulnerabilities does not necessarily protect users from this issue, as even on patched devices, hackers can still obtain the encrypted disk image which can be used to roll the device back to a vulnerable version, extract the key by exploiting TrustZone, and crack the key.
While both vulnerabilities have apparently already been fixed earlier this year, some independent sources have reported estimates that the majority of devices out there are still vulnerable, as they haven't received the latest security patches.
Having said all that, Beniamini claims that regular users are not likely to fall victim to such an attack, as the protection scheme involved is elaborate enough to not make it worthwhile for would-be attackers. Enterprise Android users on the other hand, are still at risk. Beniamini is currently working with both Google and Qualcomm to come up with a solution to the issue and we can only hope for the best.
source: Gel Beniamini via ARS Technica
The problem lies in both the hardware and software compartments, as Android stores the disk encryption keys in software, which makes them vulnerable to extraction on Qualcomm-powered devices due to two oversights in ARM's TrustZone – hardware-based security built into SoCs by semiconductor chip designers before they are distributed to the device manufacturers. The blog post also includes the exploit code capable to execute code within the TrustZone kernel and thus, to extract cryptographic keys, which can then be cracked in numerous different ways.
Beniamni also goes over Apple's approach to FDE, which is apparently pretty good at keeping your data safe. We are going to take a more summarized look at both systems.
Each iDevice has a unique 256-bit key that cannot be modified, called a Unique Identification Number (UID). It is randomly generated and basically fused in to the device's hardware at the factory. This key is bound to the device's hardware and is completely inaccessible to both software and firmware, meaning that even Apple cannot extract it from the device once it's been set. The UID is also used in combination with the user's password, in order to generate an encryption key which effectively “tangles” the device-specific key and the user's password. This complicates the matters for would-be attackers a lot, as it necessitates the use of the device itself for each cracking attempt, which in itself allows Apple to introduce a myriad of other measures – such as an incrementally increasing delay between subsequent password guesses – to further mitigate brute-force attacks.
The worst part is, Beniamini claims, that patching TrustZone vulnerabilities does not necessarily protect users from this issue, as even on patched devices, hackers can still obtain the encrypted disk image which can be used to roll the device back to a vulnerable version, extract the key by exploiting TrustZone, and crack the key.
Having said all that, Beniamini claims that regular users are not likely to fall victim to such an attack, as the protection scheme involved is elaborate enough to not make it worthwhile for would-be attackers. Enterprise Android users on the other hand, are still at risk. Beniamini is currently working with both Google and Qualcomm to come up with a solution to the issue and we can only hope for the best.
source: Gel Beniamini via ARS Technica
Things that are NOT allowed: