This important line is omitted from Android Enterprise Security White Paper 2021 which exists in 2020 paper:
"The Verified Boot state is used as an input in the process to derive disk encryption keys."...
Conversation
..."If the Verifed Boot state changes (e.g. the user unlocks the bootloader), then the secure hardware prevents access to data used to derive the disk encryption keys that were used when the bootloader was locked."
1
What is the cryptographic relationship between verified boot state and FBE keys? Does it pass as a constant input to KDF to derive a key that decrypts FBE keys?
2
Replying to
Yes, unlocking the boot loader changes the input to the KDF that generates the key that encrypts KeyMint key blobs.
1
1
Also worth noting that it also changes based on verified boot key while locked.
Nexus 5X, Nexus 6P, Pixel and Pixel XL predated AVB and essentially relied on this for verified boot enforcement since they didn't directly enforce the verified boot key or verified boot state.
1
1
On those pre-AVB devices an attacker could swap out the OS images to another OS with a valid signature and the device would happily boot up in the yellow boot state but would lose the keystore keys, so if an attacker didn't already have the FDE/FBE keys they couldn't derive them.
2
1
Is it not a good security design (using Verified Boot Key instead of Verified Boot State as an input to KDF) if the attacker loses FBE keys if he boots up another OS with a valid vbmeta?
1
An attacker shouldn't be able to boot up a different set of OS images while the device is locked and isn't able to do that on AVB devices with proper verified boot enforcement. It shouldn't work at all and it's still a serious problem if they can do it but can't derive keys.
If the device isn't using wrapped keys inaccessible to the OS, an attacker would also already have the keys if they compromised the OS while it was previously booted. They'd have the device encryption keys and the keys for any profiles that were unlocked when they compromised it.
1