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
When creating external storage directories like /data/media/0, make sure
we set the quota project ID correctly, and enable project ID
inheritance. This ensures that all directories/files under this will be
created with the correct project ID and inheritance as well.
Bug: 146419093
Test: lsattr -p on /data/media
Change-Id: I32bfced0d67eb8c1865897b085324f00c55926a0
Move most of it into cryptfs.cpp, and include cryptfs.h in fewer files.
Bug: 147814592
Test: Treehugger
Change-Id: Ia3592d73e7abc1f07a60538e0978a3033bdea7de
CE keys were cached in vold to support untrusted reset
by a device admin, this is now supported by Locksettingservice
using synthetic password. This change requires a secret to be
provided to retrieve the CE key and re-wrap without the secret
when user removes the credential.
Test: Set credential, remove credential, swipe to none
and vice-versa.
Bug: 26948053
Merged-In: I4cb1c035a472477e70c1ff5bf0b2c3fcfad495e5
Change-Id: I4cb1c035a472477e70c1ff5bf0b2c3fcfad495e5
Add support for setting v2 encryption policies when configured in the
fstab (for internal storage) or in system properties (for adoptable
storage), and for installing and evicting the keys for such policies.
v2 policies support the same encryption modes and flags as v1 policies,
but internally they use a more standard, secure, and flexible KDF. Due
to this, some future features will be supported by v2 policies only.
Bug: 140500999
Test: Configured a device to use v2 encryption policies (applied the
needed kernel patches and added
"fileencryption=aes-256-xts:aes-256-cts:v2" to fstab, and set the
corresponding system properties for adoptable storage). Wiped
userdata, booted device and checked logs to verify that v2
policies were being used.
Also enabled virtual SD card and formatted as adoptable storage;
verified it works and that v2 policies were being used on it.
Also created, started, and stopped a 2nd user and verified their
keys were evicted.
Also verified that the device comes up again after rebooting.
Also verified that a device using v1 encryption policies continues
to work, both with and without an updated kernel -- including
stopping a user so that their keys get evicted.
Change-Id: If64028d8580584b2c33c614cabd5d6b93657f608
When the kernel supports the new fscrypt key management ioctls, use them
instead of add_key() and keyctl_unlink().
This will be needed in order to support v2 encryption policies, since v2
encryption policies only support the new ioctls.
The new ioctls have other advantages too. For example,
FS_IOC_REMOVE_ENCRYPTION_KEY automatically evicts exactly the necessary
kernel objects, so the drop_caches sysctl is no longer needed. This
makes evicting keys faster and more reliable.
FS_IOC_REMOVE_ENCRYPTION_KEY also detects if any files are still open
and therefore couldn't be "locked", whereas this went undetected before.
Therefore, to start out this patch adds support for using the new ioctls
for v1 encryption policies, i.e. on existing devices.
(Originally based on a patch by Satya Tangirala <satyat@google.com>)
Bug: 140500828
Test: tested that a device using v1 policies continues to work, both
with and without an updated kernel. See
If64028d8580584b2c33c614cabd5d6b93657f608 for more details.
Also checked via the log that the filesystem-level keyring is in
fact used when supported.
Change-Id: I296ef78138578a3fd773797ac0cd46af1296b959
Bug: 140882488
Test: Booted twice, checked logs to ensure encryption
is different each time, adb created files in directory.
Change-Id: I74077bf8f727dab726c25f512ed7406a74cbe0bf
When Android boots after file_contexts has changed, the boot process
walks the entire /data partition, updating any changed SELinux labels as
appropriate. However, credential encrypted ("ce") directories are
deliberately excluded from this early boot directory walk. Files within
ce directories have their filenames encrypted, and as a result, cannot
match the file_contexts entries. Only after the user has unlocked their
device are the unencrypted filenames available and a restorecon
appropriate.
Ensure that we do a post-unlock restorecon on /data/vendor_ce, like we
do for /data/system_ce and /data/misc_ce. This ensures the labels on
files within these directories are correct after the device has been
unlocked.
Bug: 132349934
Test: See bug 132349934 comment #12 for test procedure
Change-Id: Ifcbef5fdfb236ec6dea418efa9d965db3a3b782f
When a user's CE key is removed, write "2" to /proc/sys/vm/drop_caches
rather than "3". This avoids unnecessarily evicting the pagecache of
in-use inodes. It's only necessary to evict the inodes of the relevant
encrypted files, and these are already sync'ed and no longer in-use.
For this mode "2" suffices, as this evicts "reclaimable slab objects",
including inodes; and evicting an inode implies evicting its pagecache.
This matches the recommendation I've made in the documentation for the
fscrypt kernel feature at
https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html#online-attacks
Test: Sanity check that directories are still "locked" properly:
Unlock device with PIN. Then in adb shell: 'stop; start;
sleep 10; ls /data/data/' still shows filenames in ciphertext form.
Change-Id: I1bdf3c420ebf63e98cc314498211061ea36f2942
Use vold version of writeStringToFile which fsync files, and
manually fsync directories after initialize global DE
(cherry picked from commit a98464f688)
Bug: 71810347
Test: Build pass and reboot stress test.
Original boot failure symptom is NOT reproducible.
Change-Id: I1ca8f8cf0ccfd01075a9c33f79042e58d99aea26
Merged-In: I1ca8f8cf0ccfd01075a9c33f79042e58d99aea26
Now that lockUserKey() will be called for every user each time the
framework is started, it's a normal case that the key being removed
doesn't exist. So downgrade the log message about being unable to find
a key from ERROR to DEBUG.
Test: build and boot, message is now debug level.
Change-Id: I2d1dce8dd8825b02982eab1c902aa10fe5b54b84
Use vold version of writeStringToFile which fsync files, and
manually fsync directories after initialize global DE
Bug: 71810347
Test: Build pass and reboot stress test.
Original boot failure symptom is NOT reproducible.
Change-Id: I1ca8f8cf0ccfd01075a9c33f79042e58d99aea26
Device can't start up after the following steps:
1. set screen lock to PIN/Pattern/Password
2. set screen lock to Swipe/None
3. power down immediately after pressing "YES, REMOVE"
4. reboot
failed log:
Failed to read from /data/misc/vold/user_keys/ce/0/current/keymaster_key_blob
root cause:
flushing data failed because of power down
issue:
https://partnerissuetracker.corp.google.com/u/1/issues/119382750
We support file-based encryption on both ext4 and f2fs now, and the
kernel API is the same. So rename things appropriately in vold:
e4crypt => fscrypt
ext4enc => fscrypt
Ext4Crypt => FsCrypt
EXT4_* => FS_*
ext4_encryption_key => fscrypt_key
Additionally, the common functions shared by 'vold' and 'init' are now
in libfscrypt rather than ext4_utils. So update vold to link to
libfscrypt and include the renamed headers.
Note: there's a chance of 'fscrypt' being confused with the dm-crypt
based encryption code in vold which is called 'cryptfs'. However,
fscrypt is the name used in the kernel for ext4/f2fs/ubifs encryption,
and it's preferable to use the same name in userspace.
Test: built, booted device with f2fs encryption
Change-Id: I2a46a49f30d9c0b73d6f6fe09e4a4904d4138ff6
