Removing the hardware key of full disk protection in Android phones on Qualcomm processors
Exploit published on Github
Google has begun to implement full disk encryption (Full Disk Encryption, FDE) by default with the version of Android 5.0 Lollipop. At the first time, when encryption was implemented in Nexus 6 devices, many users complained about a decrease in performance when reading and writing data to the drive, but since Android 6.0, this problem seems to be solved.
Full disk encryption protects all information on the phone, even if the device fell into the hands of law enforcement or
When encryption is enabled, any information on the phone is automatically encrypted on the fly with an AES key before being written to the media. And vice versa, when reading information, it is automatically decrypted with this key.
On iOS 9 devices, this key is a derivative of the user password and the unique 256-bit hardware key sewn into the smartphone at the factory. Even the FBI, as we know from a recent history with a San Bernardino shooter’s smartphone, because of which the FBI and Apple got to court, cannot crack the encryption of such a level with the help of brute force . As a result, the FBI still managed to hack the phone using an unknown 0day vulnerability. As can be understood from the words of the head of state structure, hackers had to pay over a million dollars to bypass the FBI’s defense .
Full disk encryption in iOS
Thus, brutfors FDE is possible only with the use of a specific hardware device. This greatly complicates the attack. In the usual case, it would be possible to create a million copies and parallelize brute force in the cloud service, which allows you to very quickly select 99% of real passwords. But in this case, we have to limit ourselves to a single device, on which Apple adds additional noise, such as delays between attempts to enter a password, restrictions on the maximum number of attempts, etc. That is why it is extremely important for the special services to find a way to extract the hardware UID, then the brute force password becomes a commonplace technical problem.
Full disk encryption in Android 5.0+ is implemented somewhat differently than in iOS 9, and is described in detail inthe blog of Nikolai Elenkov and the official Android documentation .
Here, the encryption key is also a derivative of the usually weak user password, but also of a randomly generated 128-bit master key (Device Encryption Key - DEK) and a randomly generated 128-bit salt. The DEK generation field is protected using a carefully thought-out scheme in which user-entered values — a pincode / password / pattern (graphic key) are used to enter. The encrypted DEK is then placed in a special encrypted vault called crypto footer . All these levels of encryption need to be overcome before decrypting the DEK, and then any information recorded on the drive.
As in the case of iOS 9, the Android operating system implements the binding of an encryption scheme to a specific hardware in order to prevent bruteforce on copies of the operating system. The hardware binding function is performed by a special hardware storage , KeyMaster, which operates in a special Trusted Execution Environment (TEE) environment, completely independent of the Android operating system. Key security in the KeyMaster environment is essential. Only this protects the system of full disk encryption from effective bruteforce in parallel threads on OS copies.
On Android devices, an isolated environment will never give its own key out to the “insecure” environment. On the contrary, the KeyMaster module receives a “key blob” from an insecure environment, decrypts the key stored there - and gives it back. In other words, the operation of the encryption system is possible only directly on the hardware device, but not in a virtual environment on another computer.
In general, the whole process can be schematically depicted in such a diagram, which Nikolai Elenkov gives .
The protection of the KeyMaster environment and the execution of commands on a dedicated secure processor are ensured by the secure environment provided by the hardware manufacturer. In the case of Qualcomm, this is QSEE (Qualcomm Secure Execution Environment). It allows for execution on a dedicated processor only individual small applications, which are called "trustlets". One such trust is KeyMaster. The Android source code has instructions for accessing the KeyMaster application. In fact, the trustlet only supports four instructions:
* Commands supported
*/
enumkeymaster_cmd_t{
/*
* List the commands supportedin by the hardware.
*/KEYMASTER_GENERATE_KEYPAIR = 0x00000001,
KEYMASTER_IMPORT_KEYPAIR = 0x00000002,
KEYMASTER_SIGN_DATA = 0x00000003,
KEYMASTER_VERIFY_DATA = 0x00000004,
};KeyMaster works exactly as described above: it receives a key blob, calculates the signature and puts it into the buffer.
And now we have come to exactly the stage at which the new exploit is in place, which appeared in open access on June 30 (the repository on Github ). The exploit exploits the recently discovered vulnerabilities CVE-2015-6639 and CVE-2016-2431 .
The author of the exploit, security specialist Gal Beniamini (Gal Beniamini) wrote a fake version of the QSEE application and with the help of the above vulnerabilities managed to download it into a protected environment, thereby increasing authority and hacking the environment protection QSEE, which is involved in the process of key generation for disk encryption.
Thus, a hypothetical attacker can “fake” the hardware component of the encryption key and brute force the rest of the components, bypassing Android’s protection by the number of retries. It remains only to find a user PIN / password.
By the way, for the rare case when a user has set up a truly complex password with high entropy for encryption and cannot be picked up by brute force in a reasonable time, there is a backup plan. If hacking encryption is really extremely necessary, you can find exactly the same phone, the same model, with the same scratches and a protective case - and program it to send a password as soon as the victim enters it. This fake device is attached to the victim instead of the original one. To avoid disclosure and at the same time eliminate the risk of the victim entering the wrong password on the first attempt, the phone must be programmed that it does not accept any entered password as correct.
But this is an extreme case, of course. Ordinary pincodes and passwords are actually quite simple to pick up if there are no hardware brute force restrictions.
There is an interesting point. Protected environment on mobile devices is not set by Qualcomm itself, but by OEMs. They can cooperate with the law enforcement agencies of the country in whose jurisdiction they are located and fulfill the requirements of court inquiries. Accordingly, if such a cryptographic scheme is implemented by a Russian manufacturer, the information on the smartphone will be declassified at the request of the Russian court.
And one more interesting moment. Despite the fact that Gal Benyamini discussed these vulnerabilities with Qualcomm and Google for several months, fixing them is not so easy - there is not enough software upgrade (patches for Android came out in January and May for two vulnerabilities ), or you may need a hardware upgrade. The fact is that if an attacker gets a device, then theoretically he can roll back a software upgrade, return the device to a vulnerable version and launch an attack.
As mentioned above, the exploit code is published on Github . Here is a diagram of his work.
Gal Benjamini has written several Python scripts that simplify brute force after the exploit has been triggered. In the comments to his blog posts colleaguesexpressed a desire to help in porting the script to the most powerful platform for the hashcat / oclHashcat brute-force .
Benyamini suggests that Google, along with OEM builders, will develop a new, completely secure hardware-software encryption scheme, which even theoretically cannot be broken into.
We hope that this scheme will be implemented on a new generation of Android devices.