There are currently a bunch of ways Google ensures Android running handsets remain secure – monthly over-the-air patches and a customary full disk encryption policy for OEMs. Implementation, however, for the latter depends on the hardware manufacturer. Google has devised several layers of encryption to prevent any sort of unauthorized access, although, the algorithms aren’t quite robust due to the immense fragmentation issue and therefore, even a single liability or fault can disclose everything.
How Android’s Encryption Works
Android’s encryption is based on a well-established Linux kernel (central core of a particular system), details for which aren’t necessary to understand this. In a nutshell, each specific handset creates a unique and random 128-bit master key which is usually referred as a Device Encryption Key (DEK) and utilized for concealing user data. The smartphone also creates an additional 128-bit salt which along with any PIN or password enabled by the user – Key Derivation Key (KEK), is used for encrypting the DEK itself. Lastly, the DEK is stored in an unencrypted memory space (titled “crypto footer”) on the phone. To decrypt the file system for admin-level purposes, the entire process is essentially, reversed.
However, there’s an another private field which is bounded to each device’s hardware. The key derivation and decryption involve the aforementioned value signing the KEK which later is used to decode the DEK. This process is carried out by a separate module packed in Android, termed as KeyMaster. The core purpose of implementing a dedicated module for decryption and not handing the keys directly to applications is quite obvious. One other thing you should be aware of is the Trusted Execution Environment – TEE that withholds the KeyMaster program.
So What’s the Issue?
Learning about the encryption process does say something about how Google has tried to do its part for keeping vulnerabilities away from Android. Unfortunately, the hardware generated key comes down to how OEMs structure it. A security researcher recently attempted to access private Android files and surprisingly, succeeded in revealing a huge flaw in the system. He stated that the key derivation function which is basically used to sign the KEK isn’t really hardware-bound as expected. He was, in fact, able to generate the key from TrustZone’s software without any hassles. Hence, even a small hole in kernel or KeyMaster module can lead to complete blunder for the user.
The researcher found a tiny unprotected chunk of space in Kernel’s code and without any system failures whatsoever, overrode the area with a custom function to leak keys from the KeyMaster. This does require the hijacker to obtain a person’s device physically, although, it’s a troubling technical bypass that needs immediate attention from Google. The problem can be partially fixed with regular security patches but what percentage of distributions really keep up with Google’s Nexus phones?. Moreover, the researcher mentioned that this loophole can be eventually extended to wireless access if the user visits an unsafe app or website even by accident. As the larger portion of Android’s market share doesn’t include Nexus phones, these sort of vulnerabilities impact an enormous number of users. The only solution remains here is a hardware overhaul and compulsion for OEMs to roll out updated patches monthly. Flagship phones are nowadays receiving these fixes, although, it is an astonishingly small chunk of devices. Given some recent events, manufacturers definitely need to address these privacy concerns for each and every phone out there, else severe malwares will continue to impact the entire Android space which could eventually lead to serious data integrity violations. Customers also need to understand the outcomes and as far as possible, avoid turning off security checks in the settings and Android smartphones that don’t receive updates at all.
