With this change, vold exposes an API that may be used to bind key
storage encryption keys to a given seed value. The seed value passed to
vold must be consistent across reboots, or key storage keys will not be
derived consistently. The seed is expected to be set very early in boot,
prior to the use of any key storage encryption keys.
This feature is intended to be used for embedded applications such as
in autos, where the seed may be provided by some other component of the
system. In such systems, there is a default user that is automatically
signed in without a PIN or other credentials. By binding the file
encryption to a platform-provided seed, the default user's data gains
additional protection against removal of the Android embedded device
from the integrated system.
Bug: 157501579
Test: Set seed at startup via init.rc. Seed changes fail as expected.
Change-Id: I9b048ec5e045b84c45883724ace2356d4ef6244d
Remove the error-prone 'keepOld' parameter, and instead make begin()
(renamed to BeginKeymasterOp()) do all the key upgrade handling.
Don't handle /data and /metadata differently anymore. Previously, when
a checkpoint is active, key blob files were replaced on /data
immediately; only the actual Keymaster key deletion was delayed until
checkpoint commit. But it's easier to just delay the key blob file
replacement too, as we have to implement that for /metadata anyway.
Also be more vigilant about deleting any leftover upgraded keys.
Test: Tested on bramble using an OTA rvc-d1-release => master. In OTA
success case, verified via logcat that the keys were upgraded and
then were committed after the boot succeeded. In OTA failure
case, verified that the device still boots -- i.e., the old keys
weren't lost. Verified that in either case, no
keymaster_key_blob_upgraded files were left over. Finally, also
tried 'pm create-user' and 'pm remove-user' and verified via
logcat that the Keymaster keys still get deleted.
Change-Id: Ic9c3e63e0bcae0c608fc79050ca4a1676b3852ee
Commit 77df7f207d / 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
Change-Id: I42d3f5fbe32cb2ec229f4b614cfb271412a3ed29
To prevent keys from being compromised if an attacker
acquires read access to kernel memory, some inline
encryption hardware supports protecting the keys in
hardware without software having access to or the
ability to set the plaintext keys. Instead, software
only sees "wrapped keys", which may differ on every boot.
'wrappedkey_v0' fileencryption flag is used to denote
that the device supports inline encryption hardware that
supports this feature. On such devices keymaster is used
to generate keys with STORAGE_KEY tag and export a
per-boot ephemerally wrapped storage key to install it in
the kernel.
The wrapped key framework in the linux kernel ensures the
wrapped key is provided to the inline encryption hardware
where it is unwrapped and the file contents key is derived
to encrypt contents without revealing the plaintext key in
the clear.
Test: FBE validation with Fscrypt v2 + inline crypt + wrapped
key changes kernel.
Bug: 147733587
Change-Id: I1f0de61b56534ec1df9baef075acb74bacd00758
This adds the ability to upgrade a key and retain the
old one for rollback purposes. We delete the old key
if we boot successfully and delete the new key if we
do not.
Test: Enable checkpointing and test rolling back
between two versions
Bug: 111020314
Change-Id: I19f31a1ac06a811c0644fc956e61b5ca84e7241a
Protect all per-volume-per-user keys with a per-volume key, which is
forgotten when the volume is forgotten. This means that the user's key
is securely lost even when their storage is encrypted at forgetting
time.
Bug: 25861755
Test: create a volume, forget it, check logs and filesystem.
Change-Id: I8df77bc91bbfa2258e082ddd54d6160dbf39b378
std::vector with custom zeroing allocator is used instead of
std::string for data that can contain encryption keys.
Bug: 64201177
Test: manually created a managed profile, changed it's credentials
Test: manually upgraded a phone with profile from O to MR1.
Change-Id: Ic31877049f69eba9f8ea64fd99acaaca5a01d3dd
This is used by LockSettingsService to delete sensitive credential files.
Bug: 34600579
Test: manual - change device lock under synthetic password, verify
old data on disk is erased.
Change-Id: I5e11b559ad8818bd2ad2b321d67d21477aab7555
Keymaster but in-process crypto.
Bug: 33384925
Test: manual for now: patch KeyAuthentication.usesKeymaster() to always return true;
flash a FBE device, add a device PIN, reboot and verify PIN can unlock FBE.
Then clear device PIN, reboot and verify FBE is unlocked automatically.
In both cases, check there is no keymaster_key_blob in
/data/misc/vold/user_keys/ce/0/current/
Unit tests to be added.
Change-Id: Ia94e2b39d60bfd98c7a8347a5ba043eeab6928c5
The formatting here is inconsistent with Android house style; use
clang-format to bring it back into line.
Change-Id: Id1fe6ff54e9b668ca88c3fc021ae0a5bdd1327eb
Google/Android C++ style requires that arguments passed in for writing
should be pointers, not references, so that it's visible in the caller
that they'll be written to.
Bug: 27566014
Change-Id: I5cd55906cc4b2f61c8b97b223786be0b3ce28862
Added a new call change_user_key which changes the way that disk
encryption keys are protected; a key can now be protected with a
combination of an auth token and a secret which is a hashed password.
Both of these are passed to unlock_user_key.
This change introduces a security bug, b/26948053, which must be fixed
before we ship.
Bug: 22950892
Change-Id: Iac1e45bb6f86f2af5c472c70a0fe3228b02115bf
The key storage module didn't comply with Android coding standards
and had room for improvemnet in a few other ways, so have cleaned up.
Change-Id: I260ccff316423169cf887e538113b5ea400892f2
Instead of writing raw keys, encrypt the keys with keymaster. This
paves the way to protecting them with auth tokens and passwords later.
In addition, fold in the hash of a 16k file into their encryption, to
ensure secure deletion works properly.
Now even C++ier!
Bug: 22502684
Bug: 22950892
Change-Id: If70f139e342373533c42d5a298444b8438428322
