TL;DR:
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:
- Open up the Accessibility settings menu.
- If a Accessibility Service is listed there at the top, disable it.
- Change your screen lock PIN/password/pattern whatever to reset the encryption password. Make sure to tick the "Require PIN to start device" option.
Introduction
Every few weeks I feel like rebooting my Nexus 5 because it get's 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 dialog:
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 hack 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.
Background information on Android encryption
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 allows 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 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 to the protection level of the encrypted data.
Default password in Lollipop
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 a 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 Trusted Execution Environment’s (TEE) signing capability. Previously, we encrypted the master key with a key generated by applying scrypt 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 scrypt. 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 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.
Accessibility Services
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 "this apps needs access to..." dialog, 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?
Am I the only one to notice?
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 advices users to just proceed, yet severely impacting the encryption protection level! I'm quite sure LastPass isn't the only example.
How to reproduce
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.
- Set up device encryption on your Android device using any option that requires the password/pattern at power on time.
- Notice that you'll get the early PIN/password/pattern input interface which looks different from the lock screen.
- Install an app that installs an Accessibility Service, e.g. Screen Notifications by Luke Korth. There's nothing wrong with this particular app, it's just an example for demonstration purposes.
- Open the app. For the example application above, allow access to the notifications.
- Enable the Accessibility service it requires from the app or, ...
- Verify that the service is indeed enabled by checking the Accessibility section in the Android system settings.
- Notice that when enabling the service the warning message shown does not mention clearly that the protection level is seriously compromised. Instead, it lets you focus on the other single item shown in a list, which is totally sane for the purpose of this app. Proceed by tapping OK.
- Power off your Android device.
- Power it back on. Notice that you won't be asked for user input until you already see your regular lock screen.
The attacker-victim scenario
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.
What I think should be improved
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.
- Change wording from "disable enhanced encryption" to "use unsafe default password for encryption".
- A sticky notification should be present as long as the device encryption password is the default one.
- Suggest the user to re-enable the password if all Accessibility Services are disabled. Also when the app providing the service is removed, this should trigger.
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.
Conclusions
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 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!
Do you agree, do you have suggestions or remarks? Please share your thoughts in a comment below!