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
