Change FDE password - doesn't seem to work with Oreo

[sarevok-anchev]

Just changed the encryption password with vdc, rebooted, and the system correctly prompts for the newly set password.

However, from SnooperStopper, and inputting the exact same password, it claims that "The current encryption password is incorrect."

Quick glance at the code reveals this might be the problematic part:

java/cz/eutopia/snooperstopper/CryptfsCommands.java:

168         boolean isCyanogenmod13 = IS_M && SuShell.isCyanogenmod();
169 
170         String command = isCyanogenmod13 ? CRYPTFS_CHANGEPW_PASSWORD_CM_CMD
171                                          : CRYPTFS_CHANGEPW_PASSWORD_CMD;

Earlier in the file we can see,

 27     private static final String CRYPTFS_CHANGEPW_CMD = VDC_CMD_PATH
 28             + " cryptfs changepw '%s'";

...

 35     private static final String CRYPTFS_CHANGEPW_PASSWORD_CM_CMD = VDC_CMD_PATH
 36             + " cryptfs changepw password %s %s";

And indeed, on LOS 15.1 the vdc syntax (still/also) needs the currently-set password before the new one.

[MSe1969]

Hi, I have had a look, and assuming your observation is correct, a fix would be easy. I'll do a test build (fork) and raise a pull request to this repo here hoping it will be merged, if my test is successful... Hope to find time this week... (This is not my repo, I am only interested to have this working in LineageOS 15.1 as well)

[MSe1969]

To add info: SuShell.java - IsCyanogenmod13() - the grep in LineageOS 15.1 must be "ro.lineage..." instead of "ro.cm..." so this would need to be checked in addition

[MSe1969]

I think it is worth to read through this issue: https://github.com/AndroidHardening/bugtracker/issues/451 - in short: Already with Android N, the app was in fact obsolete - in simple terms, "legacy" devices (e.g. my Osprey, which had LineageOS 13.0 on it, when I used this app and continued using it on Lineage 14.1, not knowing that all only worked, because of "legacy design" and that even newer devices designed for Nougat would not work properly) may still work, but definitely new gen. devices... So I'll not issue a cherry-pick and stop messing around with it - SnooperStopper is a great app for ROMS until including Android MM and if it works on N with your older device, be happy. But it is obsolete and that may also be the reason, no further development takes place - pitty, I'll miss it, but for Oreo, I need to think about a different approach (like complex boot pass phrase combined with fingerprint unlock - not nice, but...)

[thestinger]

The issue at AndroidHardeningArchive/bugtracker#451 is about using the existing infrastructure for fingerprint unlock as a secondary unlock mechanism to add support for having a PIN as a secondary unlock mechanism. It might as well always use fingerprint + PIN rather than just a PIN though, especially since it actually makes it more convenient rather than less, while having advantages in terms of mitigating shoulder surfing. Using the fingerprint to trigger it doesn't really have a disadvantage, since the issues like not being able to revoke fingerprints, the fact that you leave them on everything you touch, it being able to be physically forced, weaker legal protections, etc. are all not relevant when using it in combination with a PIN rather than alone.

[nchristensen]

In Android Pie raw vdc cryptfs commands are no longer supported.

https://source.android.com/security/encryption/file-based https://android.stackexchange.com/questions/212370/how-to-change-the-encryption-key-on-rooted-android-9

There is an ugly workaround however. https://forum.xda-developers.com/general/security/guide-separate-passwords-encrypted-t3048072/page6

[thestinger]

By the way, https://github.com/GrapheneOS/os_issue_tracker/issues/28 is the new issue about implementing a replacement as a proper secondary unlock mechanism for FBE. I'd really recommend that anyone interested in this kind of feature looks into implementing it this way. It can support both FDE and FBE along with offering far better semantics. The secondary unlock mechanism has an attempt limit (falling back to requiring the main unlock mechanism which should be a strong passphrase), cannot be used for the initial unlock and has a timeout (48h is the standard one). It can also take advantage of a fingerprint scanner for better convenience and a 2nd factor in addition to the PIN.

A basic implementation would be a UI feature requiring a PIN to finish fingerprint unlock. A more advanced implementation would ideally be integrated into the keystore security. That may not be possible with the current keystore firmware, but that's something to work towards.