Don’t get tempted by any app asking you to enable its Accessibility Service. It will change your encryption password to the Android default one allowing everyone to decrypt the “encrypted” data. The PIN you enter at powering on your device may not be used for encryption at all – without a warning given.
If you use encryption on your Android device, follow these steps now:
Every few weeks I feel like rebooting my Nexus 5 because it gets a little slow for some reason. This morning I noticed it booted up without asking my encryption PIN. I was expecting this early boot PIN entry dialogue:
It did ask for a PIN though, but it was clearly already at the regular lock screen, with the launcher background already visible and notifications sounding. For a moment I thought the PIN entry at boot for decrypting the user data had improved so much with the latest CyanogenMod 12.1 nightly, but no… also TWRP recovery was able to access all my files without a PIN!
An encrypted filesystem doesn’t get unencrypted overnight, so, what the heck happened? I had to get to the bottom of this!
I took some dive into how Android encryption is implemented and found what I believe is a relatively serious security issue as a result of the user interface implementation flaw. I’m publishing this because I think people should be aware of until this is improved by Google.
There may be many people out there like me until today, thinking they are protected by their “Encrypt phone” state set to “Encrypted” while in fact, they are not.
The implementation of encryption in Android comprises of the Linux dm-crypt module. It’s the same as what is used by LUKS on your favourite Linux distribution, but Android developers have chosen to implement their own key management.
Custom recoveries like TWRP have built-in support for managing the encrypted partitions and allow the user to input the password to decrypt.
In Android versions 4.x, you might have noticed that when enabling encryption, Android forces you to set a PIN or password for the lock screen to use that as the encryption password as well. During power-up of your phone, you would then enter your device PIN/password/pattern early in the boot process, in order for the user-specific data to be loaded.
With the release of Android Lollipop, encryption security has been improved greatly on a technical level I won’t be touching much. However, it has also “improved” on how tightly the lock screen PIN/password/pattern was connected to the device encryption key.
This article is more about a user interface flaw for that improvement. It can lead to insufficient awareness of the user being raised with regard to the impact it has on the protection level of the encrypted data.
For the Lollipop release, Google is motivating vendors to enable encryption by default with the following feature. Devices should be encrypted in the box, using a default password. This default password is hidden for the user as it is not asked for during boot. The user is asked to set a lock screen PIN/password/pattern in the first time setup wizard, which then also updates the password for the device encryption.
This approach also improves the user experience by not having to go through the long process of encrypting a currently unencrypted data partition, but instead, offers near-instant encryption protection by just changing the passphrase for the master key of the encrypted partitions.
The default password is
default_password according to the Android Documentation on encryption:
The default password is: “default_password”. However, the resultant hash is also signed through a TEE (such as TrustZone), which uses a hash of the signature to encrypt the master key.
Furthermore, the documentation mentions in quite some detail on how proper security is handled:
Hardware backing is implemented by using the Trusted Execution Environment’s (TEE) signing capability. Previously, we encrypted the master key with a key generated by applying the script to the user’s password and the stored salt. In order to make the key resilient against off-box attacks, we extend this algorithm by signing the resultant key with a stored TEE key. The resultant signature is then turned into an appropriate length key by one more application of script. This key is then used to encrypt and decrypt the master key.
This means that even with the default password the storage is safe for “off-box attacks”. Sounds good, right? Well… how likely would it be to find phone built-in flash memory without the actual device? So, in practice, the use of this default password doesn’t offer any data protection for the simple case of losing a device.
Given that users reinitialize this default password on first use… could it still go wrong? Yes.
Before an Accessibility Service is turned on, a user is warned about the data encryption not being “enhanced” anymore as shown below:
First of all, I don’t get what accessibility services have to deal with the device encryption to start with. Please enlighten me if you do. Secondly and more importantly, it’s not just some “enhancement” of a screen lock that gets disabled; it’s the whole data protection that’s being reduced to nothing because the encryption password is being reset to the default!
Moreover, I didn’t even spot that part of the warning message. It looks like a “these apps need access to…” dialogue, don’t you agree?
Upon proceeding, your PIN/password/pattern is unchanged for the lock screen and the Encryption status will still say “Encrypted”. This effectively hides the disabled data protection and the warning is dismissed without ever reminding you.
Anyone having physical access to your Android device will be able to decrypt all your data without knowledge of your PIN/password/pattern. It’s defeating the main purpose of the device encryption, to begin with, so how does that align with the text in the warning?
No, I’m not the first. When googling I’m bumping into a lot of confused users shown the incorrect warning for devices not encrypted at all and for which it’s not even applicable. In Android issue 79309 a user mentions:
I have a Nexus 6 on T-Mobile. Enabling app permissions in the Accessibly settings DISABLES the requirement for a pin during the boot process. This is a pretty big security issue.
And another one:
This one is probably slightly higher than Priority-Small, as it’s likely a deployment blocker for enterprises, where it presents a serious security issue. […] I confirmed that providing the disk encryption credentials then turns off PIN or password requirement at boot, meaning the disk is in practice unencrypted per access requirements.
Yet the issue isn’t given priority by Google.
In the meantime, I see instructions posted to just hit OK to be able to use the app involved. Like this one on the official LastPass Q&A site:
When enabling LastPass Accessibility Service, you may see the following warning: “Because you’ve turned on an accessibility service, your device won’t use your screen lock to enhance data encryption” OR your “require pin at boot” option is disabled. Please note that it is a Google bug and not specific to LastPass but all other Accessibility Services. For more information, please see the post here: https://code.google.com/p/android/issues/detail?id=79309.
You need to disable “require pin at boot” option, enable Accessibility Service, and re-enable the option.
LastPass just refers to this bug report as if the warning being shown by Android is a bug and advises users to just proceed, yet severely impacting the encryption protection level! I’m quite sure LastPass isn’t the only example.
Here’s how I reproduced it on a Nexus 5 with both stock ROM 5.1.1 build LMY48I as well as Cyanogenmod 12.1 nightlies.
Identifying the critical steps from the section above, all an attacked needs to do is persuade a victim to install a perfectly legitimate app. The single requirement for the app chosen is that it needs to be convincing enough for a victim to get him to enable the app’s Accessibility Service on his device.
Once the victim has noticed the app may have caused some harm, he uninstalls it, but it is still affected by the default password being used for encryption. Unless the victim changes his lock screen password, the default encryption password will remain in place.
If and only if there’s a good reason for Accessibility Services to deal with data encryption settings, I think Android should be improved to handle the use of the default password with a lot more noise and clear warnings.
The above should avoid users being tricked into enabling Accessibility Services installed by apps and unknowingly disabling the protection offered by device encryption.
However, most effective is just have Accessibility Services not interfere with data encryption settings.
Android’s user interface insufficiently warns users on the impact of disabling of what is presented as an “enhancement” for encryption. Many Android owners may be unprotected unknowingly while their Android settings menu would suggest they are perfectly fine. If the device is affected, data on devices lost can be easily accessed without the PIN/password/pattern.
Additionally, it opens up ways for attackers to get hold of the user’s data stored on encrypted devices through social engineering.
I think this deserves some attention by end-users, Android developers at Google and those managing mobile devices in enterprises. I’d be grateful for anyone forwarding this to some Google/AOSP developers to get this sorted in a future Android version. Thanks!
This content was originally published here.