This article is more than 1 year old

Inside Android's source code... // TODO – Finish file encryption later

Android 7.0's crypto sauce is 'half-baked' and Google promises to make it better, soon

Looking at the storage encryption Google has implemented in Android Nougat (7.0) through the metaphor of the glass that's either half full or half empty, cryptography expert Matthew Green sees Google's glass as all but drained.

In a blog post last week, Green, assistant professor of computer science at Johns Hopkins University, said that optimists may feel that Android is moving in the right direction and that its "half-baked" implementation of file-based encryption is better than its implementation of full-disk encryption. Then he noted that such people "probably also think clowns are nice."

"On the other hand, you might notice that this is a pretty goddamn low standard," Green wrote. "In other words, in 2016 Android is still struggling to deploy encryption that achieves (lock screen) security that Apple figured out six years ago. And they’re not even getting it right."

Green's post outlines the different approaches to encryption taken by Google and Apple. Starting with Android KitKat (4.4) and continuing through Google Marshmallow (6.0), Google implemented full-disk encryption to protect Android devices.

The drawback with this approach is that it's an all-or-nothing affair. Android devices keep their cryptographic keys in memory, in order to ensure the device's applications can function while it's on. But keeping crypto keys in memory is not very secure – sophisticated adversaries can extract keys from memory.

"In principle, a clever implementation could evict sensitive cryptographic keys from RAM when the device locks, then re-derive them the next time the user logs in," explained Green. "Unfortunately, Android doesn't do this – for the very simple reason that Android users want their phones to actually work."

Apple approached the problem from a different angle. Starting with iOS 4, Apple implemented file-based encryption, protecting each file individually with its own unique key, Green said. But it also allows individual keys to be encrypted with a class key tied to the user passcode and hardware-based secrets.

These classes can be applied to accommodate several scenarios:

  • Files can be encrypted until the device is on and unlocked.
  • Files can be protected until the first user authentication, with keys remaining in memory thereafter.
  • Files can be accessible after a reboot but prior to authentication.
  • Files can be created with a key despite the absence of keys in memory, as one might desire when taking photos from smartphone lock screen.

Android Nougat attempts to implement a system more like iOS through a new scheme called Direct Boot. It allows the phone to access some data before the passcode has been entered. But Android only provides two protection categories and these fail to cover all the desirable scenarios, according to Green.

One problem with Google's approach, Green said, is that "there is no unambiguous way for Android to tell applications when the system has been re-locked."

Without this, applications may start returning errors when the Android device gets locked.

For Green, the problem is not so much Google's technology as that its lack of developer guidance prevents developers from creating apps that handle locked devices properly.

Then there's the issue of the unfinished nature of Android's encryption code, which as Green points out, includes a TODO comment as a placeholder for the lines of C++ that, someday, will evict encryption keys from memory.

//https://android.googlesource.com/platform/system/vold/+/master/Ext4Crypt.cpp

bool e4crypt_lock_user_key(userid_t user_id) {
    if (e4crypt_is_native()) {
        // TODO: remove from kernel keyring
    } else if (e4crypt_is_emulated()) {
        // When in emulation mode, we just use chmod
        if (!emulated_lock(android::vold::BuildDataSystemCePath(user_id)) ||
            !emulated_lock(android::vold::BuildDataMiscCePath(user_id)) ||
            !emulated_lock(android::vold::BuildDataMediaCePath(nullptr, user_id)) ||
            !emulated_lock(android::vold::BuildDataUserCePath(nullptr, user_id))) {
            LOG(ERROR) << "Failed to lock user " << user_id;
            return false;
        }
    }

The bottom line is, these shortcomings make it a lot easier for anyone who seizes your Android phone, or can inject malware into it, to get your file decryption keys and extract your information. Green noted:

By treating encryption as a relatively low priority, Google is basically telling these people that they shouldn’t get the same protections as other users. This may keep the FBI off Google’s backs, but in the long term it’s bad judgement on Google’s part.

In an email to Green posted via Twitter, Google senior software engineer Paul Crowley chooses to see Google's encryption glass as half full, at least.

"I was pleased to see you say that you consider Nougat's encryption to be an improvement over what came before it," he said. "That's very much how we see it."

Then Crowley goes on to acknowledge that further work will be done to enhance Android security. ®

More about

TIP US OFF

Send us news


Other stories you might like