Commit graph

21 commits

Author SHA1 Message Date
Nikita Ioffe
1ee35cf002 fskeyring & userspace reboot: support CE keys
During userspace reboot /data might be unmounted & remounted, meaning
that CE keys stored in fs-level keyring will be lost. In order to be
able to restore them, when installing new key to fs-level keyring, it's
also added to session-level keyring with type "fscrypt-provisioning".

Then when init_user0 is called during userspace reboot, vold will try to
load CE keys from the session-level keyring back into fs-level keyring
for all the users that were unlocked before the reboot.

If for any user vold fails to install the key, init_user0 will fail and
fallback to hard reboot will be triggered.

Test: set a pin pattern
Test: adb shell setprop sys.init.userdata_remount.force_umount 1
Test: adb shell svc power reboot userspace
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 143970043
Change-Id: I37603dc136c7ededc7b0381e4d730cb0ffd912b4
2020-03-07 01:19:42 +00:00
Paul Crowley
249c2fb4aa Refactor: make makeGen local
No need for KeyUtil to know how to make a KeyGeneration, it's cleaner
if each module handles it separately. Also, create a CryptoOptions
structure to track metadata encryption options, and simplify legacy
cipher/option handling.

Test: Treehugger
Bug: 147814592
Change-Id: I740063882914097329ff72348d0c0855c26c7aab
2020-02-18 12:49:36 -08:00
Paul Crowley
4eac264727 Refactor key generation to handle both normal and metadata encryption.
Bug: 147733587
Test: Treehugger
Change-Id: Iee176037dec2621c84da325c2627f988fcebbc8d
Merged-In: Iee176037dec2621c84da325c2627f988fcebbc8d
2020-02-14 13:59:06 -08:00
Barani Muthukumaran
3dfb094cb2 vold: Support Storage keys for FBE
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
2020-02-12 14:26:26 -08:00
Paul Crowley
77df7f207d Refactor to use EncryptionPolicy everywhere we used to use raw_ref
Test: Boots, no bad log messages: Cuttlefish with v2 policies, Taimen
Bug: 147733587
Change-Id: Ice4acac3236b6b7d90e60a2f57b46814aa1949f5
2020-01-28 11:17:58 -08:00
Eric Biggers
506342fb37 Clean up providing key via old API
- Use FSCRYPT_MAX_KEY_SIZE from <linux/fscrypt.h> instead of manually
  defining FS_AES_256_XTS_KEY_SIZE.  These have the same numeric value
  (64), but the former is supposed to be used, and AES-256-XTS isn't
  necessarily the encryption algorithm that is being used anyway.

- Use the new name FSCRYPT_KEY_DESCRIPTOR_SIZE instead of the old name
  FS_KEY_DESCRIPTOR_SIZE.  These have the same numeric value (8).

- Don't try to handle sizeof(fscrypt_key::raw) > FSCRYPT_MAX_KEY_SIZE,
  as this simply isn't the case.

- Set fscrypt_key::mode to 0 rather than FS_ENCRYPTION_MODE_AES_256_XTS.
  This field has always been ignored by the kernel, and AES-256-XTS
  isn't necessarily the encryption algorithm that is being used anyway.

- Initialize the fields of fscrypt_key in order.

This is a cleanup only.

Test: booted hikey with fileencryption=aes-256-xts and a kernel that
      doesn't support the new fscrypt ioctls.
Bug: none
Change-Id: Ie2a7e9240aa479dfab2765c11db8a7124d20c643
2019-12-17 13:48:25 -08:00
Eric Biggers
3e9c996ab0 Use <linux/fscrypt.h> from Bionic
aosp/1184798 has updated the kernel headers to 5.4, so we no longer need
the file fscrypt_uapi.h.  In KeyUtil.cpp we also now don't need
<linux/fs.h>, but rather just the more specific <linux/fscrypt.h>.

Test: build
Bug: None
Change-Id: I56d17826eb7c3b95c74ce0435a4feae7f3cc325e
2019-12-16 16:19:44 -08:00
Eric Biggers
83a73d7d50 vold: support v2 encryption policies
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
2019-10-04 16:04:36 -07:00
Eric Biggers
f3dc4203dd vold: use new ioctls to add/remove fscrypt keys when supported
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
2019-09-30 13:11:42 -07:00
Daniel Rosenberg
690d6de5bf Add Support for metadata key with rollback
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
2018-12-14 14:55:28 -08:00
Eric Biggers
ba997ee583 vold: get the fscrypt kernel API declarations from linux/fs.h
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
2018-10-25 17:12:32 -07:00
Eric Biggers
a701c458ca vold: rename from "ext4 encryption" to fscrypt
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
2018-10-25 17:12:32 -07:00
Paul Crowley
14c8c0765a clang-format many files.
Test: Format-only changes; treehugger suffices.
Change-Id: I23cde3f0bbcac13bef555d13514e922c79d5ad48
2018-09-18 15:41:22 -07:00
Paul Crowley
26a53888a4 When we forget a volume, forget per-volume key
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
2017-10-26 12:19:09 -07:00
Chen, Luhai
5744dfe3cc Fix keyname generation issue
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>
2017-09-11 18:39:01 -07:00
Pavel Grafov
e2e2d308df Zero memory used for encryuption keys.
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
2017-08-10 17:31:03 +01:00
Paul Crowley
cd8bfe3d7f Label keys with all the possible FBE prefixes that might apply
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
2017-06-20 10:10:08 -07:00
Elliott Hughes
c3bda18bda Switch to libkeyutils.
Bug: http://b/37991155
Test: builds+boots
Change-Id: I33a3ba0d59ffd504093dc94517815c1196e95e2b
2017-05-10 16:59:33 -07:00
Daniel Rosenberg
71c56f6dd5 Revert "Revert "Stop dropping caches now we have kernel fix""
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
2017-04-28 16:04:11 -07:00
Paul Crowley
d5759811ff Add support for metadata encryption
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
2017-04-21 13:40:20 -07:00
Paul Crowley
f71ace310e Refactor to lay the groundwork for metadata encryption
Bug: 26778031
Test: Angler, Marlin build and boot
Change-Id: Ic136dfe6195a650f7db76d3489f36da6a1929dc5
2017-04-21 10:47:17 -07:00