Context
Android uses the same PIN (or pattern) that is used to unlock the screen to decrypt the disk. However the actual decryption key is bound to the device via some internal device key. So ideally you can only decrypt the disk on the device itself, and the device can delay the process and ultimately delete any data if too many failed attempts are made. This is the same concept that's used e.g. on ATM cards, which lock themselves after a couple of failed attempts, so a 4 digit PIN is enough.
Except that's not true, at least not for Qualcomm chipsets, where you can extract the device key, than brute-force the PIN externally, which shouldn't take too long for a 4 digit PIN. See [1]
So I want a strong password for disk encryption, but still a 4 digit PIN for unlocking. I tried the Cryptfs-app, but that crashed, so I used the "vdc cryptfs changepw ..." command on the commandline to set the disk encryption key. On the next reboot, the phone asked for my password, but didn't accept it. So reset everything, and try again. I did this a couple of times with the same result but ultimately got it work by making data not encrypted and then encrypt it using "vdc cryptfs enablecrypto ...".
Not sure exactly what went wrong there, but I saw a couple of QSEECOM errors in the log (QSEECOM is the component that communicates with Qualcomms "secure" execution environment).
This is on a BQ Aquaris X with TWRP and SuperSU but otherwise stock firmware (Android 7.1.1).
The worrying part
Now here is, what worries me: Whenever the phone didn't accept my (correct) password, I rebooted into TWRP. TWRP then asked for my password to decrypt data, and did so successfully. Except it also worked with the wrong password! Apparently during the boot process, when Android asked for my password, it actually decrypted the key and kept it decrypted over a full reboot! Some component didn't get properly reset. I checked by entering the wrong password during boot. When I then rebooted into TWRP I actually had to enter the correct password for it to work.
Now, that the system is working (i.e. it actually continues to boot after I enter the correct password), I cannot reproduce that behaviour. A reboot seems to always clear the key. But who knows, maybe with some trickery it is still possible to keep data decrypted over a reboot. Given how buggy the implementation seems to be.
Question
Is anyone aware of a known bug where the disk encryption key is kept decrypted over a reboot? I couldn't find anything about this.
Conclusion
Use a strong password for disk encryption
Even if you do, don't trust your phone and don't keep real sensitive data on your phone
harry
[1] (can't post links, so google for: Extracting Qualcomm's KeyMaster Keys - Breaking Android Full Disk Encryption blogspot)
3 years later on Android 10 it seems like this issue still exists? And I wondering why encryption is even enabled because it offers basically not protection.
The only workaround in Android 10 that I could think of:
I can use faceunlock for the lockscreen and for the decryption after a boot up. So basically I never really ever have to enter my PIN or pattern.
That means I could use a really strong and complicated PIN or pattern and there for increase the security of the encryption.
How ever, even a 12 digit numerical PIN or pattern (a pattern is basically just a numerical PIN) won't take long to bruteforce.
Related
Hi there,
Ok so now Lollipop is shipped encrypted by default, good thing. But what's the point of encrypting it if it doesn't even ask for a passphrase at boot time ?
I noticed it gives the user an integrity protection if the bootloader was tampered with but it's not enough.
I tried what was indicated on the torproject's blog, in the "Mission Impossible: Hardening Android" but it's oriented toward 4.x roms. The command was (as root) :
Code:
vdc cryptfs enablecrypto inplace NewMoreSecurePassword
Then I rebooted but there was no passphrase prompt and the device decrypted itself automatically.
Did someone managed to activate this ?
OK found this : https://source.android.com/devices/tech/encryption/
It seems it's syncing the schema/pin/password with the encryption password.
Since I've put a schema my device asks for it at each boot.
It's not what I' d like to have. I'd like to be able to change boottime schema with a passphrase and keep my schema for the screenlock...
I was rather disappointed by the fact that ZTE does not let us use encryption properly on stock ROM.
However, all the stuff is in place in the ROM in principle: I flashed B06 over a data partition encrypted on CM13 and lo and behold, stock ROM asks for password and proceeds to boot up normally.
So if we can find a way to get key handling sorted on stock (which I guess is simply using dm-crypt), we can use proper encryption.
https://source.android.com/security/encryption/full-disk.html says the key used should already be random, so we just need to reencrypt the key with a new password to get proper encryption for which the process is the following
When a user elects to change or remove their password in settings, the UI sends the command cryptfs changepw to vold, and vold re-encrypts the disk master key with the new password.
Click to expand...
Click to collapse
I can´t test it (as I use cm13 as daily), but I assume the following command would set a proper password (obviously needs root):
Code:
su
vdc cryptfs changepw super-secure-long-password
If anyone wants to try, be my guest but I take absolutely no responsibility. Might be helpful to have twrp on your device in case something goes wrong, too.
Loader009 said:
It looks like I've triggered something in the bootloader so that this "SystemImage" (that's how it's named in TWRP) seems to be "activated" and running.
[…]
What I did?
I tried to change the encryptionPW with Cryptfs Password. It failed for some reason (or at least it said so).
After a reboot it showed me the corrupt data screen, in TWRP I entered my password and it was correct.
So I had to format userdata (no prob because of backup) but that's it.
I tried to restore the backup and noticed after a few tries that it always does not boot into my backup but instead into this SystemImage.
Click to expand...
Click to collapse
I was not able to do that...
nupi said:
I was rather disappointed by the fact that ZTE does not let us use encryption properly on stock ROM.
However, all the stuff is in place in the ROM in principle: I flashed B06 over a data partition encrypted on CM13 and lo and behold, stock ROM asks for password and proceeds to boot up normally.
So if we can find a way to get key handling sorted on stock (which I guess is simply using dm-crypt), we can use proper encryption.
https://source.android.com/security/encryption/full-disk.html says the key used should already be random, so we just need to reencrypt the key with a new password to get proper encryption for which the process is the following
Click to expand...
Click to collapse
Interesting, and you had the data properly mounted on boot with functioning lockscreen or FP?
When I tried changing the cryptfs password on stock rom (and @jcadduono did this as well) the phone did ask for boot password, but would not decrypt and mount /userdata
does this return a code 200 if you try it with your current password
vdc cryptfs verifypw <yourpass>
I had, worked perfectly with the previously set password
Not running stock I am not sure trying vdc will be useful. If I can find the time I will try over Xmas
https://community.zteusa.com/thread/12482?start=255&tstart=0
Hi all,
I have a question about encryption on Android 9. I recently fixed up my old Nexus 5 to use as a test device and set it up with the newest Unlegacy Android (Pie) ROM (OpenGAPPS Mini, Magisk 17.1) and enabled encryption on it. So far so good and everything works perfectly without any Problem.
As I was always curious about changing the encryption password on my current daily driver (Nexus 6) because I use a fairly short passcode to not make it annoying to get into the phone, I searched a little and came across the App SnooperStopper, which would do everything I wanted: Make it able to use different passwords for encryption and the lock screen, but also secure the lock screen in a way that after some failed unlock attempts the phone would reboot, requiring the full encryption password again.
After testing on my Nexus 5 I found out that the way the app changes the password does not work on the newer Android OSes anymore. (I also tested the method mentioned on this XDA Blog post without success)
So my question is if there is an updated way to change encryption password or if there is any other way to achieve my goal of having different passwords for encryption and lock screen as well as making the phone reboot on too many retries.
Thanks a bunch!
~Joe
Maybe a bit late, but it might help someone else, as I was looking for a way in Oreo or later the last 2 days too.
bastei said:
As a workaround on Android Pie, you can do the following (on your own risk):
set the desired password for the screen lock
backup lockscreen files:
all files under /data/system_de/0/spblob/
files containing "_synthetic_password_" in /data/misc/keystore/user_0/
/data/system/locksettings.db
set the desired password for the device encryption
restore / replace all lockscreen files
If something went wrong, sqlite into /data/system/locksettings.db and set the values of sp-handle and lockscreen.password_type to 0 to reset the screen lock.
Click to expand...
Click to collapse
For me this did not work and just made the phone hang for a while and then reboot after entering the encryption password.
An alternative way I found was to set a password normally (the one you want for the disk encryption) and then just delete all these files and restart the process of setting a new lockscreen password while denying to turn on the boot protection. This might work on some devices, but according to the following link, this doesn't work for example on LineageOS 16.
Also it seems like LineageOS 17 and possibly other Roms reenabled the old way of changing the password in the Terminal. See: https://github.com/nelenkov/cryptfs-password-manager/issues/25
I wished I could do it without installing any apps, but I am not knowledgeable enough to proceed further. For me the only solution was this modified version of the cryptfs App. The normal install process is explained there as well: https://github.com/thedroidgeek/cryptfs-password-manager/releases
Here is how I installed it:
1) Install the App
2) Get the 'App Systemizer' module through the Magisk Manager (https://forum.xda-developers.com/apps/magisk/module-terminal-app-systemizer-ui-t3585851)
3) Install Cryptfs App normally
4) Run 'systemize' as root in a Terminal app (I got a busybox error and ignored it)
5) Choose 'Systemize Installed Apps (Listed)' and find 'Cryptfs Password'
6) install into '/system/priv-app'
7) For me it errored out saying that the app already exists, ignore it.
8) reboot
9) Start Cryptfs App. If the process of making it a system app failed, then the app shuts down with an error message about needing to be systemized.
10) set your encryption password in the app.
11) Reboot, check if it works
12) Disable cryptfs App and the App systemizer module, no need to keep them running until next use.
The difference to snooper Stopper is that you can't set any actions to take if the password is entered incorrectly a few times. However if that functionality is needed, you can install snooper Stopper afterwards and just ignore the password change options and just set the behaviors.
On Android Pie, one or both of these files may exist:
Code:
/data/system/gatekeeper.password.key
/data/system/gatekeeper.pattern.key
I know that there are used in verifying a device's unlock password/pattern/PIN, but are they also used in deriving the decrypting file-based encryption on a Pie device?
Anyone?
As far as I understood it, the answer would be a no.
These files contain an encrypted form of your PIN/pattern /password.
The decryption key for the contents of these files is derived from the same HW component which also provides the decryption key for your /data partition.
jisoo said:
As far as I understood it, the answer would be a no.
These files contain an encrypted form of your PIN/pattern /password.
The decryption key for the contents of these files is derived from the same HW component which also provides the decryption key for your /data partition.
Click to expand...
Click to collapse
Why is it that in guides for fixing a non-working PIN/pattern/password that it is recommended to delete those files along with locksettings.db?
Master Melab said:
Why is it that in guides for fixing a non-working PIN/pattern/password that it is recommended to delete those files along with locksettings.db?
Click to expand...
Click to collapse
I would guess there are a couple of reasons.
First, that method works for older versions of Android which didn't have encryption turned on by default.
Second, the method still does work for lockscreen bugs. However, it won't help you with actual decryption anymore.
The decryption and unlocking process seems to be: request user password (or pin etc) -> send to HW chip to verify and receive rest of decryption key -> decrypt data -> decrypt contents of keyfile and compare inputted password -> unlock.
The benefit would seem to be that it's no longer possible for a rogue process to find out the user password after the device had been unlocked, as the contents of the keyfiles remain encrypted even after data has been decrypted.
jisoo said:
I would guess there are a couple of reasons.
First, that method works for older versions of Android which didn't have encryption turned on by default.
Second, the method still does work for lockscreen bugs. However, it won't help you with actual decryption anymore.
The decryption and unlocking process seems to be: request user password (or pin etc) -> send to HW chip to verify and receive rest of decryption key -> decrypt data -> decrypt contents of keyfile and compare inputted password -> unlock.
The benefit would seem to be that it's no longer possible for a rogue process to find out the user password after the device had been unlocked, as the contents of the keyfiles remain encrypted even after data has been decrypted.
Click to expand...
Click to collapse
I've looked at the TWRP source code for Decrypt_User and Get_Password_Type. Get_Password_Type is passed a string pointer that it will set to either gatekeeper.password.key or gatekeeper.pattern.key if the path /data/system_de/<USER_ID>/spblob does not exist. Decrypt_User will only use that filename stored at the pointer if the previously mentioned path does not exist. Going off of that, I'd conclude that gatekeeper.*.key files don't provide material used in deriving keys.
Bump.
Assume that one has a device that:
Running a version of Android that is either Nougat, Oreo, or Pie.
The device uses not full disk encryption but rather file-based encryption.
Has a password, pattern, or PIN set.
Say that the user has booted into TWRP or something like and deletes each of these files if they exist:
gatekeeper.password.key
gatekeeper.pattern.key
locksettings.db
locksetting.db-shm
locksettings.db-wal
Here are my questions:
Upon booting into stock Android, will Android be able to load correctly? If not, what should it be expected to do?
I've seen on here and other websites users who did something similar to what I described and were unable to get to their applications/files BUT were able to access Settings. If this is what should be expected to happen, then what will happen if one sets another lock code through Settings? Will it erase the blob data connected to the old lock code that plays a role in deriving the decryption key? Will it crash instead?
Master Melab said:
Assume that one has a device that:
Running a version of Android that is either Nougat, Oreo, or Pie.
The device uses not full disk encryption but rather file-based encryption.
Has a password, pattern, or PIN set.
Say that the user has booted into TWRP or something like and deletes each of these files if they exist:
gatekeeper.password.key
gatekeeper.pattern.key
locksettings.db
locksetting.db-shm
locksettings.db-wal
Here are my questions:
Upon booting into stock Android, will Android be able to load correctly? If not, what should it be expected to do?
I've seen on here and other websites users who did something similar to what I described and were unable to get to their applications/files BUT were able to access Settings. If this is what should be expected to happen, then what will happen if one sets another lock code through Settings? Will it erase the blob data connected to the old lock code that plays a role in deriving the decryption key? Will it crash instead?
Click to expand...
Click to collapse
How about you set the conditions and try it out yourself
([emoji3590]09-09-18[emoji3590])
PoochyX said:
How about you set the conditions and try it out yourself
([emoji3590]09-09-18[emoji3590])
Click to expand...
Click to collapse
Because I don't have a functioning Android device that meets the requirements I outlined.
I am bumping this thread.
Bump.
**DONT**
did the same thing "accidently " a while ago, had to format /data (internal storage is gone!)
My device was struck on "Wait a second" forever.
It worked before file-based-encryption, but now I think the android system (Gatekeeper maybe?) checks for locksettings.db file during the bootup and doesn't start if not found or something
PS: Don't delete any of these files if your system uses file-based-encryption
locksettings.db
locksettings.db-shm
locksettings.db-wal.
file-based-encryption actually requires your PIN (used to encrypt) to decrypt the file-system, in addition it requires a lot of other ce/de key files, my advice would be not to delete stuff without making a proper backup!