Question about encryption:
Is there a way to find out if a device uses the Full Disc Encryption or the File Based Encryption?
Thanks for help!
Related
Hallo,
I want to create an encrypted container that i can mount on demand. I've found references of ecryptfs in CM10.2 and it has an built-in encryption function (whole device only, OS managed). How can i manually use that encryption feature on shell level to create an encrypted container? Projects like guardianproject (cryptsetup, LUKS) seem dead. I guess because it's now built into android os natively. But I'm not sure...
Any ideas?
DualJoe said:
Hallo,
I want to create an encrypted container that i can mount on demand. I've found references of ecryptfs in CM10.2 and it has an built-in encryption function (whole device only, OS managed). How can i manually use that encryption feature on shell level to create an encrypted container? Projects like guardianproject (cryptsetup, LUKS) seem dead. I guess because it's now built into android os natively. But I'm not sure...
Any ideas?
Click to expand...
Click to collapse
Questions in these xda forums related to enabling encryption on android are ignored, removed, or have zero replies against them. Read into that what you will. After weeks of trying to figure out an answer, I'm left looking for my tin foil hat.
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.
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.
Is it possible to have file-based encryption on POCO F1? If it is, can anybody help me get it on my device? I already tried using the command "fastboot --wipe-and-use-fbe" but I got an error I saw something about putting changes to fstab file but didn't know how to perform those...
If you know how to enable it, please help...
(Source of Information: https://developer.android.com/training/articles/direct-boot )
Thanks.
Specs:
Xiaomi Mi A2 (A/B part. scheme)
Android 10 Pixel Experience
I'm currently using F2FS for the added read/write speed but with no encryption at all. And that's not really ideal, as you might've guessed.
Code:
fastboot --wipe-and-use-fbe
formats to ext4 by default and there's no way to choose the FS. What I'm asking is is there a way to do this manually, via adb shell from recovery, for instance?
Edit: I mean, of course it's possible to use fscrypt directly but I'm not even sure that that's what Android uses by default and where it stores the passphrase to unlock it
enable file based encryption
yes you can do it.
let me search little bit about it.
i will be back to you soon
So, any new info?