Flaw in Android Full Disk Encryption discovered
A security researcher discovered a flaw in how Android devices handle full disk encryption which makes it easier for attackers to gain access to the data.
Google started to implement Full Disk Encryption on Android starting with version 5.0. The idea behind the security feature is to protect data on the device from unauthorized access.
The recent Apple versus the FBI case has shown that full disk encryption can protect data even from powerful organizations. While the FBI managed to gain access to the data eventually, it had to resort to hacking the device instead of beating its full disk encryption implementation.
Android's disk encryption in a nutshell is derived from the user's authentication code and a hardware derived key. The disk is decrypted when Android users enter their password.
All of this happens in the background and invisible to the user. Google implemented additional means to improve the security of the data. It introduced delays between password attempts to make brute forcing less useful, and there is even an option to wipe the data after failed decryption attempts.
A security researcher analyzed Android's full disk encryption implementation recently and came to the conclusion that it is not as secure as it should be.
Flaw in Android Full Disk Encryption
You find all the technical bits of the analysis on this blog, and it is a good read if you are interested in security. The information is highly technical on the other hand and most Android users are probably only interested in what this means for them.
Basically, what it means is that in worst case, Android's disk encryption hinges on the user's account password only. The researcher managed to gain code execution privileges within the TrustZone kernel by exploiting two security vulnerabilities discovered in 2014. Qualcomm did create patches for these vulnerabilities.
While you may have thought that this is the case anyway, it is not. Android uses the password to create a strong 2048-but RSA key derived from it instead.
Another takeaway from the analysis is that Qualcomm or OEMs can comply with law enforcement to break the full disk encryption.
Since the key is available to TrustZone, Qualcomm and OEMs could simply create and sign a TrustZone image which extracts the KeyMaster keys and flash it to the target device. This would allow law enforcement to easily brute-force the FDE password off the device using the leaked keys.
Again, recreating the attack requires executing code within the TrustZone kernel which means that creating a modified TrustZone kernel image is not sufficient.
Ultimately, it means that hackers can break Android's full disk encryption when Qualcomm chips are used, and OEMs or Qualcomm may be coerced to do the same.
The researcher has created a proof of concept script which is available on GitHub, and a brute force script to brute force Android's full disk encryption off the device.
There is little that users can do about it. Without doubt the best defense is to use a very secure password for the device.
http://www.howtogeek.com/141953/how-to-encrypt-your-android-phone-and-why-you-might-want-to/
Please don’t let facts get in your way. You do realize that anyone could easily create a bug report even if it’s not accurate, right?
Was that directed to me? You mention bug reports, so I am guessing this was meant to be a reply to my last comment. I don’t see anything in your link that contradicts what I have written. There is a detailed explanation of the problem here (and a solution for those who want to / are able to root their devices): https://nelenkov.blogspot.com/2012/08/changing-androids-disk-encryption.html .
There’s an even bigger problem with Android full disk encryption, AFAIC. It’s that you are forced to use the same password for the lock-screen as you use for disk encryption. This is a huge mistake, because it means you have to enter your encryption password every single time you want to use your device. Well, how many characters is a person willing to enter? No one in their right mind is going to use password longer than 8 or 10 characters – far fewer than a good encryption password would have. In other words, the encryption system is crippled by its own design.
Incidentally, this problem has been widely discussed online for years. There’s even an active Android bug report about it. But I don’t see any evidence that Google is going to address it (which could involve just copying what Apple does…. It’s not rocket science.)
“Crippled by design”, so true!
The vulnerabilities were patched in January and May.
Did your or any Android device that you know got the patch ?
Since when Android OEMs patch Android devices (except for Google’s Nexus devices) ?
It hasn’t been, and never will be patched :
“I’ve been in contact with Qualcomm regarding the issue prior to the release of this post, and have let them review the blog post. As always, they’ve been very helpful and fast to respond. Unfortunately, it seems as though fixing the issue is not simple, and might require hardware changes. ”
The proper way for Qualcomm to fix this issue is by full Android recall replacing all devices in use by new ones.