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
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
bionic now has linux/fs.h from the 4.14 kernel, which has the fscrypt
kernel API declarations. Replace the manual declarations in vold,
except for FS_AES_256_XTS_KEY_SIZE which is not available.
Test: built, booted device with f2fs encryption
Change-Id: I6a0e3117eaebe3baac7385421afce2169d46ad55
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
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
The keyname binded to keyring return a wrong string when there are binary char larger than 127,
the sign extension will introduce unexpect FFFFFF string to the keyname.
Bug: 65423023
Test: local build with boot test and device encryption status check.
Change-Id: I26482c98ac1858a63b9f5c3f84a8699fd6a21cd7
Signed-off-by: Ai, Ting A <ting.a.ai@intel.com>
Signed-off-by: Chen, Luhai <luhai.chen@intel.com>
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
We don't know which FS and kernel version is going to want these keys,
so put them in the kernel three times with all three possible prefixes.
Test: Marlin set up before this change successfully boots after it.
Change-Id: I6ccfe0894551ba068de9bf5e23fe4fd1e10e36b1
This reverts commit 8ad0bef7b5.
Bug: 37231161
Test: Boot device with FBE enabled. ls /storage/emulated/0/Android
Unlock device. ls /storage/emulated/0/Android
1st will not be found. Second should be found.
Change-Id: I92c7ad0adaa7bd357e10661a47cc667ac0ff84b4
Support encrypting metadata in /userdata using the dm-default-key
driver with a key in the /metadata partition.
Bug: 29189559
Test: Angler & Marlin build and boot
Change-Id: I716b117508d4bb4f6a4039293acb848cbc60f67b
