Is it possible to make TWRP skip Gatekeeper verification of a password and just go straight to attempting to use it to decrypt /data/misc/vold/user_keys/ce/0/current/encrypted_key? My phone is a Pixel running Pie and it uses file-based encryption (FBE) instead of FDE.
Who is knowledgeable about FBE?
Bumpity.
Bump.
More details: When it is given a password to decrypt a device that uses FBE at least, TWRP uses Gatekeeper, locksettings.db, gatekeeper.*.key, and /data/system_de/0/spblob/<SP-HANDLE>.{pwd,secdis,spblob} to verify the password. Presumably, this is how Android verifies a PIN/pattern/password for unlocking the device and NOT for verifying that the key derived from the password works in decrypting the data stored on the device.
What I want to do with TWRP is skip the password verification altogether and go straight to deriving the decryption key from password (and verify if that key works). I need to try this because I was modifying locksettings.db and gatekeeper.*.key in attempt to get TWRP to decrypt the device and now it's facing trouble handling this stuff.
How do I get it to skip the password verification?
Bump.
Bump.
Someone here must understand what I'm talking about.
Bump.
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
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.
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!