fscrypt: updates for wrapped key
- During OTA upgrades if security state or ROT changes then Keymaster
keys requires upgrade. So for such usescases, if the FBE ephemeral
key export fails, check whether KM key requires upgrade and try for
exporting ephemeral key again.
CRs-Fixed: 2632902
Change-Id: I3ee2fcd97a56b628dc4304867c8f2b8da875f883
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
- Commit 77df7f2 / http://aosp/1217657 ("Refactor to use
EncryptionPolicy everywhere we used to use raw_ref") unintentionally
made fscrypt_initialize_systemwide_keys() start specifying keepOld=true
(via default parameter value) when retrieving the system DE key, and
likewise for read_or_create_volkey() and volume keys.
As a result, if the associated Keymaster key needs to be upgraded, the
upgraded key blob gets written to "keymaster_key_blob_upgraded", but it
doesn't replace the original "keymaster_key_blob", nor is the original
key deleted from Keymaster. This happens at every boot, eventually
resulting in the RPMB partition in Keymaster becoming full.
Only the metadata encryption key ever needs keepOld=true, since it's the
only key that isn't stored in /data, and the purpose of keepOld=true is
to allow a key that isn't stored in /data to be committed or rolled back
when a userdata checkpoint is committed or rolled back.
So, fix this bug by removing the default value of keepOld, and
specifying false everywhere except the metadata encryption key.
Note that when an affected device gets this fix, it will finally upgrade
its system DE key correctly. However, this fix doesn't free up space in
Keymaster that was consumed by this bug.
Test: On bramble:
- Flashed rvc-d1-dev build, with wiping userdata
- Flashed a newer build, without wiping userdata
- Log expectedly shows key upgrades:
$ adb logcat | grep 'Upgrading key'
D vold : Upgrading key:
/metadata/vold/metadata_encryption/key
D vold : Upgrading key: /data/unencrypted/key
D vold : Upgrading key: /data/misc/vold/user_keys/de/0
D vold : Upgrading key:
/data/misc/vold/user_keys/ce/0/current
- Rebooted
- Log unexpectedly shows the system DE key being upgraded again:
$ adb logcat | grep 'Upgrading key'
D vold : Upgrading key: /data/unencrypted/key
- "keymaster_key_blob_upgraded" unexpectedly still exists:
$ adb shell find /data /metadata -name
keymaster_key_blob_upgraded
/data/unencrypted/key/keymaster_key_blob_upgraded
- Applied this fix and flashed, without wiping userdata
- Log shows system DE key being upgraded (expected because due to the
bug, the upgraded key didn't replace the original one before)
$ adb logcat | grep 'Upgrading key'
D vold : Upgrading key: /data/unencrypted/key
- "keymaster_key_blob_upgraded" expectedly no longer exists
$ adb shell find /data /metadata -name
keymaster_key_blob_upgraded
- Rebooted
- Log expectedly doesn't show any more key upgrades
$ adb logcat | grep 'Upgrading key'
Bug: 171944521
Bug: 172019387
(cherry picked from commit c493903732d0c17b33091cf722cbcc3262292801)
Merged-In: I42d3f5fbe32cb2ec229f4b614cfb271412a3ed29
Change-Id: I42d3f5fbe32cb2ec229f4b614cfb271412a3ed29
Change-Id: I0449b812e91c13020a8b653f2149c33e46027b97
diff --git a/crypto/fscrypt/MetadataCrypt.cpp b/crypto/fscrypt/MetadataCrypt.cpp
index d875ff0..1504367 100755
--- a/crypto/fscrypt/MetadataCrypt.cpp
+++ b/crypto/fscrypt/MetadataCrypt.cpp
@@ -160,6 +160,7 @@
* or we rebooted before commiting the keys in a freak accident.
* Either way, we can re-upgrade the key if we need to.
*/
+
Keymaster keymaster;
if (pathExists(newKeyPath)) {
if (!android::base::ReadFileToString(newKeyPath, &sKey))
@@ -170,7 +171,7 @@
unlink(newKeyPath.c_str());
}
bool needs_cp = cp_needsCheckpoint();
- if (!retrieveOrGenerateKey(dir, temp, kEmptyAuthentication, gen, key, needs_cp)) return false;
+ if (!retrieveOrGenerateKey(dir, temp, kEmptyAuthentication, gen, key, true)) return false;
if (needs_cp && pathExists(newKeyPath)) std::thread(commit_key, dir).detach();
return true;
}