Hardware-wrapped inline encryption keys (a.k.a. "wrapped storage keys"
or "TAG_STORAGE_KEY keys") are being generated with rollback resistance
enabled, but are never deleted. This leaks the space that KeyMint
implementations reserve for rollback-resistant keys, e.g. space in the
RPMB. This is a problem especially for the per-boot key, as that gets
regenerated every time the device is rebooted. After enough reboots,
KeyMint runs out of space for rollback-resistant keys. This stops any
new or upgraded keys from being rollback-resistant, reducing security.
This bug affects all devices that use HW-wrapped inline encryption keys
for FBE (have "wrappedkey_v0" in the options for fileencryption in their
fstab), and whose KeyMint implementations support TAG_STORAGE_KEY in
combination with TAG_ROLLBACK_RESISTANCE. But it's more of a problem on
devices that are rebooted frequently, as per the above.
Fix this bug by not requesting rollback resistance for HW-wrapped inline
encryption keys. It was a mistake for these keys to ever be rollback-
resistant, as they are simply a stand-in for raw keys. Secure deletion
instead has to happen higher up the stack, via the Keystore key that
encrypts these keys being deleted, or via the Keystore key and/or Weaver
slot needed to decrypt the user's synthetic password being deleted.
(It was also a mistake for HW-wrapped inline encryption keys to use
Keystore at all. The revised design for them that I'm working on for
upstream Linux doesn't use Keystore. But for now, Android uses Keystore
for them, and the fix is to not request rollback resistance.)
Bug: 240533602
Fixes: 3dfb094cb2 ("vold: Support Storage keys for FBE")
Change-Id: I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6
2d30b890d2