Further securing Nexus devices running CopperheadOS by using separate Encryption/Lockscreen passphrases

Please note that this article has undergone a major revision. After receiving negative feedback about mixing different aspects in this article from the Copperhead CTO [1], I decided to discuss the more opinionated comparison with other systems in a separate article. [2]


Some of you may be familiar with CopperheadOS. CopperheadOS is a security-oriented custom Android distribution that is based directly on AOSP (not on LineageOS or similar “heavy” forks). It is free from Google Apps and aims to be more secure than stock Android by incorporating various hardening patches.

When CopperheadOS was announced in 2015, one great feature they wanted to provide was support for using separate passphrases/pins for device encryption and the lockscreen. Unfortunately, with the move to Android 7 (or 8 ) supporting this feature got infeasible. However, providing a long passphrase each time you want to unlock your phone is extremely incovinient. On the other hand, using a short passphrase or simple PIN is insecure, because if an attacker succeeds to read your key from the (unauditable hard to audit) TEE, it is trivial to get the key using brute force attacks.

Officially, there is no way for using a separate encryption passphrase in neither AOSP or CopperheadOS atm. Luckily, I found a (rather complicated) method how it can be achieved on Nexus devices (according to discussion with CopperheadOS devs it is not applicable for Pixel devices). This article briefly describes this method (that in principle should also work for AOSP).


All data and information provided in this article is for informational purposes only. The author makes no representations as to accuracy, completeness, currentness, suitability, or validity of any information on this article and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use. All information is provided on an as-is basis.

In no event the author we be liable for any loss or damage including without limitation, indirect or consequential loss or damage, or any loss or damage whatsoever arising from loss of data or profits arising out of, or in connection with, the use of this article.

Enabling a secure boot time password in CopperheadOS

In all Android versions since 4.0, a separate passphrase could be enabled via the terminal or ADB using the “vdc” command. There are also some apps in the F-Droid store which allow to to this even more comfortably. However, both approaches require root access. Since CopperheadOS has decided (for good reasons!) not to provide root access at all, it’s not possible to use the vdc call (or even those less secure apps that require a superuser service installed) in the vendor-supported CopperheadOS builds.

You can overcome this limitation by using a self-compiled “userdebug”-build that allows root access via adb. However, you want to run such a build only temporarily and this is where things get more complicated. I spent way too much time in figuring out how to achieve a desirable result, thus, I can only share the principal steps how to achieve this for now:

  1. Modify the boardconfig for your device and edit the CMDLINE parameter so that it tries to disable SELinux (todo: provide the necessary string here). Note that this will be only effective in “userdebug” builds but ignored in “user” builds. There also seems to be a bug that it will still display “enforcing” in the system menu.
  2. Compile CopperheadOS using the official documentation and own release signing keys; backup the keys and the generated images.
  3. Compile second “release” build (using the same release keys!) but choose the variant “userdebug” to obtain an insecure, debug-enabled build. Backup the generated images as well. It is important that your “user” build is newer, since OTA downgrades are not allowed in many bootloaders.
  4. Unlock the bootloader (your data partition will get wiped!).
  5. Flash the userdebug build using the “flash-all” method.
  6. Re-flash the recovery partition, replacing it by the one from the normal “user” build. This is needed because the “userdebug” recovery is insecure as it provides root access without authentication! (Turned out to be not needed)
  7. Lock the bootloader (your data partition will get wiped again on the next boot).
  8. Boot into the insecure “userdebug” build.
  9. Set the simple lockscreen protection you would like to have for everyday use PIN/password (the lockscreen is rate-limited, so you can even use a simple PIN).
  10. Enable adb
  11. Connect via adb and use “su” to become root.
  12. Run the vdc command to set a complex passphrase for the boot-time password (vdc cryptfs changepw password your-new-super-secure-extraa-long-password).
  13. Reboot the device and verify that everything is working as expected.
  14. Reboot to recovery
  15. Verify that you have the secure recovery installed: (1) It welcomes you just with “no command” and you have to hold power+volup to get a menu. (2) The menu you get does not have the insecure options such as “mount /system”.
  16. Sideload the OTA image of your secure “user” build.
  17. Reboot to the normal OS (do not wipe!)

To make sure you are running the secured build, you can enable adb, log in via adb and try calling “su” to make sure it does not exist.

If I find the time I will update this article with more detailed instructions and describe how to work around the several build issues I encountered in CopperheadOS (you have to overcome them in order to build it) as well.


Please be aware of the following limitations:

  • To change your password or key you have to build a new userdebug build and a new user build and flash them via OTA because the recovery does not accept older builds.
  • To do other operations which require root (e.g. a full backup via one of the methods described in one of my earlier posts [3]) you also have to go through this procedure of making two new builds.
  • Even if you have a separate and more secure boot password, your key remains in memory if you lock the device and could be subject to various attack vectors (unlike the newer FDE approach on Pixel devices, where the key is not in memory when your screen is locked)


[1] https://github.com/copperhead/bugtracker/issues/451
[2] https://blogs.fsfe.org/kuleszdl/2018/04/02/looking-for-a-secure-smartphone-running-only-free-software-good-luck/
[3] http://blogs.fsfe.org/kuleszdl/2016/11/02/android-data-backup/