Vold incorrectly sends the earlyBootEnded signal only to the Keymaster
instance used for device encryption, but all of them need it.
Bug: 152932559
Test: VtsHalKeymasterV4_1TargetTest
Merged-In: Id8f01a1dc7d2398395f369c3ea74656a82888829
Change-Id: Id8f01a1dc7d2398395f369c3ea74656a82888829
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
Just before mounting partition(s) not verified by verified boot, vold
should notify keymaster that early boot has ended so it won't allow
EARLY_BOOT_ONLY keys to be created or used.
Test: VtsHalKeymasterV4_1TargetTest
Change-Id: I74ffec8d5b33f01e62f845a8fc824b3a3cad50f3
Merged-In: I74ffec8d5b33f01e62f845a8fc824b3a3cad50f3
This CL updates vold to use the Keymaster 4.1 interface, but does not
yet call any of the new methods.
Test: Boot the device
Change-Id: I4574a2f6eead3b71d1e89488b496b734694620c7
Merged-In: I4574a2f6eead3b71d1e89488b496b734694620c7
We make some of the C++ member functions 'const', to reflect how
they (don't) affect the state of the class.
Test: TreeHugger
Change-Id: Iec1c2801bfe721e2741406ed1ac0ef95662840a6
Merged-In: Iec1c2801bfe721e2741406ed1ac0ef95662840a6
During the analysis of b/72953784 it was noticed that vold was calling
keymaster abort() and failing, though vold was succeeding with its
keymaster operation. This had nothing to do with the bug, but the
presence of the error appeared to implicate keymaster, and it's bad
form in any case. This CL correctly clears the mDevice member during
a move, so the destructor will not attempt to call abort.
Test: Build & boot
Bug: 72953784
Change-Id: Ib0700f829e87f19b089396087085585ddd6b96a5
This CL changes vold from using a KM3 device directly to using the KM4
support wrapper from the KM4 support library, which supports both KM3
and KM4 devices (KM0, 1 and 2 devices are still supported as well,
because the default KM3 device is a wrapper that uses them).
In addition, I found myself getting confused about which "Keymaster"
types were locally-defined vold keymaster types and which were from
the KM4 HAL and support library, so I changd the approach to
referencing the latter, so all of them are qualified with the "km::"
namespace reference.
Test: Build & boot
Change-Id: I08ed5425641e7496f8597d5716cb3cd0cbd33a7f
Correctly handle a key upgrade error from keymaster by upgrading the
FDE RSA key and writing the new key blob to disk.
Bug: 69792304
Test: Roll back PLATFORM_SECURITY_PATCH a month, wipe and reboot, roll
forwards again, check logs with and without this patch.
Change-Id: I220d2dd4e3d791f636e9bc5f063064cecbf1b88a
This is temporary. Keystore is in the process of being upgraded to use
the new Keymaster 4.0 HAL, and I want to leave vold alone, using
Keymaster 3.0 for the moment. This CL just copies relevant bits of
keystore support utilities into vold, so it can stop depending on the
copies from keystore.
After the keystore update is complete, vold will be changed either to
use Keymaster 4.0 or -- more likely -- to use keystore rather than
talking to Keymaster directly. At that point the files added by this CL
will be deleted.
Test: Device boots and successfully decrypts /data
Change-Id: I73f6d4cc4c5e20d89d7ac37d29d025bf279f9e12
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
Change to use WaitForProperty API to wait for vold.post_fs_data_done
Also change cryptfs to C++
Bug: 35425974
Test: mma, marlin/angler boot
Change-Id: Id821f2035788fcc91909f296c83c871c67571de3
Cryptfs uses keymaster for key derivation. Vold has a C++ abstraction
for Keymaster. However, cryptfs, being a pure C implementation, uses
its own abstraction of the keymaster HAL.
This patch expresses cryptfs' keymaster abstraction in terms of
vold's C++ Keymaster abstraction, consolidating the code base to a
single point where the actual keymaster HAL is beeing used.
Test: successfully upgrade bullhead/angler while using FDE and
having a PIN set
run vold_cryptfs_scrypt_hidlization_equivalence_test
Bug: 35028230
Bug: 32020919
Change-Id: Ic3b765720be0cf7899dda5005fa89347ffb59b9f
bullhead-userdebug with disk encryption enabled and with PIN prompt at
boot can no longer unlock/mount encrypted userdata partition at boot
after updating from bullhead-userdebug prior to the two commits being
reverted here.
This reverts commit 6b7fa1bf17.
This reverts commit bbe31ba776.
Test: Flash bullhead-userdebug build created prior to the above two
commits, enable disk (set PIN to 1234) with PIN required at
boot, reboot, confirm that PIN prompt accepts the PIN, confirm
that device fully boots up and appears operational. Flash build
with this commit without wiping userdata, confirm that PIN
prompt at boot accepts the PIN and device fully boots up and
appears operational.
Bug: 35028230
Change-Id: I1e9303e9d007c0c9a3021c874340156748dff5f5
Cryptfs uses keymaster for key derivation. Vold has a C++ abstraction
for Keymaster. However, cryptfs, being a pure C implementation, uses
its own abstraction of the keymaster HAL.
This patch expresses cryptfs' keymaster abstraction in terms of
vold's C++ Keymaster abstraction, consolidating the code base to a
single point where the actual keymaster HAL is beeing used.
Test: marlin device boots with FBE enabled
Change-Id: Ia51fed5508e06fd6c436cca193791e57e0ab99ea
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
