« first day (4 days earlier)      last day (47 days later) » 

defalt
defalt
12:05 PM
As far as I know, locked/unlocked state doesn't play role in device encryption. It is handled by TEE.
If forceencrypt flag is given in fstab, kernel enforces "encrypt device on first boot"
TEE generates key bundles for FBE
See key derivation for FBE
Screen lock plays an important role here. Unless user provides right biometric or PIN, Gatekeeper application inside TEE won't issue token that is used to re-derive FBE key-bundles
 
alecxs
alecxs
@defalt refer to 22:50 (video)
 
defalt
defalt
12:28 PM
I think he oversimplified it for the audience. FBE keys are not bound with the lock/unlock state of the bootloader. The master key that TEE stores is wiped in the factory reset so data can longer be decrypted.
This is why bootloader unlocking factory resets the device.
 
alecxs
alecxs
@defalt so what's the purpose of having TWRP in the first place, if restoring backup won't work after factory reset?
 
defalt
defalt
TWRP first decrypts the data. Then backs it up.
There's no point in backing up encrypted data when the key to decrypt FBE keys that encrypts the data is held by TEE.
I'll see how exactly TEE backs up and restores data.
 
alecxs
alecxs
@defalt i am looking for something similar to downgrade protection. in Keymaster 3 the KEK depends on
VENDOR_PATCH_LEVEL
BOOT_PATCH_LEVEL
OS_PATCH_LEVEL
OS_VERSION
https://source.android.com/security/keystore/version-binding
 
defalt
defalt
What's your goal exactly?
 
alecxs
alecxs
12:53 PM
@defalt simply unlock bootloader and restore encrypted backup. (as long as metadata encryption isn't involved) for FBE there is no crypto footer and all the stuff ...
/vold/user_keys/ce/0/current/encrypted_key
/data/system/gatekeeper.password.key
/data/system/locksettings.db
...
an so on is stored in plain files (on ext4 file system). I am only afraid in losing data, because i may lose the availbility to decrypt backup. if you are 100% sure bootloader state is not involved it should work, i just need some confirmation ;)
 
 
1 hour later…
defalt
defalt
2:04 PM
@alecxs How did you make encrypted backup?
 
alecxs
alecxs
2:40 PM
@defalt it's partition image from edl.py (like adb pull userdata) already tried AVB signed boot and recovery, both times that broke bootchain. only thing haven't tried is empty vbmeta yet (but guess will also fail) so no chance to root or decrypt on locked bootloader, although i know the PIN and have full access
 
defalt
defalt
3:10 PM
@alecxs Twrp won't be able restore this backup. I find that TWRP support for encrypted device depends on the maintainer and device.
 
 
2 hours later…
alecxs
alecxs
4:45 PM
@defalt restoring is possible with adb push or edl mode, building TWRP with encryption support should also be no big deal. my concern is only about encryption keys probably becomes invalid (because of the bonding to unlock state)
 
defalt
defalt
5:11 PM
@alecxs The bootloader will reset the device after unlock which will flush the master key in TEE. If your backup is encrypted with FBE keys that are still on your device, that data won't get deciphered after boot. You need to backup data manually.
 
alecxs
alecxs
6:06 PM
@defalt thx so you are saying, for FBE KeyMaster is not using hardware-backed RSA-2048 private key to cipher KEK and storing encrypted DEK in user space (like it is the case for FDE), but random KEK is created and securely stored in TEE itself instead, which TEE wipes on factory reset so there is no way to backup/restore (encrypted) partition images (like for FDE)?
 
 
1 hour later…
defalt
defalt
7:10 PM
@alecxs What I've learned from android documentation, a 256-bit AES-GCM master key is held by TEE that encrypts 512-bit FBE keys. These FBE keys derive sub keys using HKDF-SHA512. The master key is wiped on factory reset which leaves FBE keys encrypted without any way of decrypting them in future.
The master key is itself derived from user's passcode and SHA-512 of 16KB random file. Resetting the device wipes this file and seed which makes it impossible to reconstruct the same master key again even if user sets the same passcode again after factory reset.
 
alecxs
alecxs
7:43 PM
@defalt that's bad news. but explains why backup/restore (encrypted) partition images is still possible once bootloader is unlocked - because TWRP never send instructions to KeyMaster erasing KEK (AES-GCM master key). so as long as no factory reset is performed from android (or stock recovery) a partition backup can survive formatting userdata
@defalt assume generating HKDF also involves hardware-backed private key, that's how device bonding is still realized
@defalt indeed involving the bootloader state is not necessary in this case, so CCC seems refering to FDE crypto footer only
@defalt many thx for clarifying, will accept this as answer
 
defalt
defalt
8:24 PM
@alecxs I think as long aa you are backing up /data partition byte by byte using Twrp even if it's encrypted, it's possible to restore /data byte by byte again because in the process you are also backing up FBE keys and restoring them once again.
If you have backup of your personal data in plain text, try doing this experiment.
 
alecxs
alecxs
8:52 PM
@defalt by "using Twrp" you refer to decrypting. yeah that's the one thing i don't have, plain backup. will try to adb backup as much as possible before unlocking :)
 
 
1 hour later…
alecxs
alecxs
10:13 PM
@defat seems wiping KEK is device specific, so there is small chance it could survive unlocking..
ROLLBACK_RESISTANT is ready since KeyMaster 1 - 'deleteKey' however is optional (not related to version binding):
"This method is optional, and is only implemented by Keymaster modules that provide rollback resistance"
https://source.android.com/security/keystore/implementer-ref#rollback_resistance
 

« first day (4 days earlier)      last day (47 days later) »