Google received a lot of praise for the security improvements in Android N, but some security experts have taken... <\/p>\n
Enjoy this article as well as all of our content, including E-Guides, news, tips and more. <\/p>\n
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers. <\/p>\n
You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy. <\/p>\n
Google to task over what they claim are shortcomings with Android N encryption. What are the issues with Android N's encryption scheme? <\/p>\n
Encryption is the cornerstone of information security, yet it is notoriously difficult to implement well, particularly on desktops and mobile devices used by non-tech-savvy users. Ease of use, speed and data recovery all need to be balanced against robust encryption. <\/p>\n
The two main technologies for meeting these requirements are full disk encryption (FDE) and file-based encryption (FBE). FBE only encrypts selected folders or files, which remain encrypted until the user chooses to access them by providing the correct credentials. FDE encrypts the entire contents of a device's hard drive, so if the device is lost or stolen, or the drive is placed into another device, all the data remains protected. However, once a user unlocks their device, none of the data is protected, as the entire contents of the drive will have been decrypted. While desktop computers are regularly turned off, most mobile devices are left on indefinitely, leaving sensitive data decrypted and potentially accessible to unauthorized users. <\/p>\n
Since Android version 5.0, Android devices have had FDE enabled by default. This is based on the Linux kernel subsystem dm-crypt, a widely used and robust encryption scheme. But, like every encryption scheme, it is only as strong as the key used to encrypt the data. <\/p>\n
An independent researcher, Gal Beniamini, posted an exploit code that breaks Android's FDE on devices running on Qualcomm chips by leveraging weaknesses in the chips' design. <\/p>\n
ARM TrustZone is a system-on-a-chip and CPU system-wide approach to security that supports a Trusted Execution Environment, backed by hardware-based access control, which cannot be interfered with by less trusted applications or the operating system. <\/p>\n
Android's Keystore Keymaster module is intended to assure the protection of cryptographic keys generated by applications, and it runs in the ARM TrustZone. It contains the device encryption key (DEK) used for FDE, which is further protected through encryption with a key derived from the user's unlock credentials. This key is bound to the device's hardware through the intermediate Keymaster signature. This means all cryptographic operations have to be performed directly on the device itself by the Keymaster module, thus preventing off-device brute force attacks. <\/p>\n
However, as the key derivation process is not truly hardware-bound, the Keymaster signature is stored in software instead of hardware, and is directly available to the TrustZone. This makes Android's FDE only as robust as the ARM TrustZone kernel or Keymaster module. <\/p>\n
Beniamini's previous blog posts have shown that applications that run in the TrustZone in Android devices using Qualcomm chips can be reverse-engineered. By reverse-engineering the Keymaster module and leveraging two ARM TrustZone kernel vulnerabilities he discovered, Beniamini developed an off-device exploit to decrypt the DEK. No longer restricted to a limited number of password attempts, the user's credentials can be brute forced by passing them through the key derivation function until the resulting key decrypts the stored DEK. Once the DEK is decrypted, it can be used to decrypt the entire drive, breaking Android's FDE scheme. The attacker can also downgrade a patched device to a vulnerable version to extract the key. <\/p>\n
This flaw makes Android's FDE implementation far weaker than Apple's, which has encryption keys that are properly bound to the device's hardware, and which are never divulged to software or firmware. This means an attacker must brute force an iOS user's password on the device. This requires overcoming the on-device protections, like delays between decryption attempts and wiping user data after so many failed attempts. Android devices, on the other hand, perform encryption using keys which are directly available to the ARM TrustZone software. <\/p>\n
Poor implementation is usually the weak point in any encryption technology. While the two ARM TrustZone vulnerabilities used by Beniamini, CVE-2015-6639 and CVE-2016-2431, have been patched, many devices remain susceptible to the attack because they have yet to receive the patches. This is a constant problem that plagues Android devices due to restrictions and delays created by manufacturers or carriers that prevent end users from receiving or installing the updates they release. <\/p>\n
Read about the new memory protection features in the Linux kernel on Android OS <\/p>\n
Learn about the security features in the Samsung Knox platform <\/p>\n
Find out the differences between symmetric and asymmetric encryption types <\/p>\n
<\/p>\n