KeyStorage: don't request rollback resistance for wrapped storage keys
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
Test: partner has tested that this works as expected, see bug
Fixes: 3dfb094cb26c ("vold: Support Storage keys for FBE")
Change-Id: I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6
(cherry picked from commit 2d30b890d24767a50b15a28ee6aa933f4f67d765)
Merged-In: I648a1af9e16787dfcfeefa2b2f2e4a72cac2c6a6
1 file changed