Revert "Add deleteAllKeys to IKeystoreMaintenance"
Revert "Enable deleteAllKeys from vold"
Revert "Allow vold to deleteAllKeys in Keystore"
Revert submission 15521094-vold-deleteAllKeys
Reason for revert: Causes infinite loop in Trusty KeyMint
Reverted Changes:
I9c5c54714:Detect factory reset and deleteAllKeys
I2fb0e94db:Allow vold to deleteAllKeys in Keystore
Id23f25c69:Add deleteAllKeys to IKeystoreMaintenance
Ife779307d:Enable deleteAllKeys from vold
I4312b9a11:Enable deleteAllKeys from vold
Bug: 187105270
Change-Id: I8e2621bef234d0a59be422b8d1d8d52a91378a5e
Where metadata encryption is enabled, if there is no metadata encryption
key present and we are generating one anew, then there has been a
factory reset, and this is the first key to be generated. We then call
deleteAllKeys to ensure data from before the factory reset is securely
deleted.
This shouldn't really be necessary; the factory reset call itself
should be doing this. However there are currently three factory reset
paths (settings, recovery, fastboot -w) and it is not clear that all
three are doing this correctly on all devices. Obviously an attacker
can prevent this code from being run by running a version of the OS
that does not include this change; however, if the bootloader is
locked, then keys will be version bound such that they will only work
on locked devices with a sufficiently recent version of the OS. If
every sufficiently recent signed version of the OS includes this change
the attack is defeated.
Bug: 187105270
Test: booted Cuttlefish twice, checked logs
Ignore-AOSP-First: no merge path to this branch from AOSP.
Merged-In: I9c5c547140e8b1bbffb9c1d215f75251f0f1354e
Change-Id: I9c5c547140e8b1bbffb9c1d215f75251f0f1354e
Vold currently uses AServiceManager_getService() to connect to
keystore2, which has an internal timeout of 5s. Since a lot of vold
keystore2 connection failures are fatal, we instead use
AServiceManager_waitForService(), which will wait efficiently for
keystore2 to start, instead of timing out after 5s.
Bug: 185934601
Test: Cuttlefish boots.
Change-Id: Ib4e977a997e020082382e0686f448d1aa72834ec
Fix KeymasterOperation::updateCompletely() to not treat an empty output
as an error, since for RSA signing (used by cryptfs / FDE) it is
expected that the output from update() be empty. The output is instead
produced at the end by finish().
This is one of a set of changes that is needed to get FDE working again
so that devices that launched with FDE can be upgraded to Android 12.
Bug: 186165644
Change-Id: Icf120f8b9526d051d0ebe16bc8ad1edf712241e1
This CL updates vold to use the updated storage key API that provides an
optional upgraded key blob. In this patch the upgraded key blob is not
yet stored by vold.
Bug: 185811713
Test: N/A
Change-Id: I39eeb20df0eb2b023479f3adebab264d29d00048
Now that isSecure() always returns true, we can remove it and simplify
all the callers (i.e. cryptfs). Refer to the commit description for
Iaebfef082eca0da8a305043fafb6d85e5de14cf8 for why this function always
return true.
Bug: 181910578
Test: Cuttlefish and bramble boot
Change-Id: I185dd8180bd7842b05295263f0b1aa7205329a88
Make vold use keystore2 for all its operations instead of directly using
keymaster. This way, we won't have any clients that bypass keystore2,
and we'll no longer need to reserve a keymaster operation for vold.
Note that we now hardcode "SecurityLevel::TRUSTED_ENVIRONMENT" (TEE)
when talking to Keystore2 since Keystore2 only allows TEE and STRONGBOX.
Keystore2 presents any SOFTWARE implementation as a TEE to callers when
no "real" TEE is present. As far as storage encryption is concerned,
there's no advantage to using a STRONGBOX when a "real" TEE is present,
and a STRONGBOX can't be present if a "real" TEE isn't, so asking
Keystore2 for a TEE is the best we can do in any situation.
The difference in behaviour only really affects the full disk encryption
code in cryptfs.cpp, which used to explicitly check that the keymaster
device is a "real" TEE (as opposed to a SOFTWARE implementation) before
using it (it can no longer do so since Keystore2 doesn't provide a way
to do this).
A little code history digging (7c49ab0a0b in particular) shows that
cryptfs.cpp cared about two things when using a keymaster.
- 1) that the keys generated by the keymaster were "standalone" keys -
i.e. that the keymaster could operate on those keys without
requiring /data or any other service to be available.
- 2) that the keymaster was a non-SOFTWARE implementation so that things
would still work in case a "real" TEE keymaster was ever somehow
added to the device after first boot.
Today, all "real" TEE keymasters always generate "standalone" keys, and
a TEE has been required in Android devices since at least Android N. The
only two exceptions are Goldfish and ARC++, which have SOFTWARE
keymasters, but both those keymasters also generate "standalone" keys.
We're also no longer worried about possibly adding a "real" TEE KM to
either of those devices after first boot. So there's no longer a reason
cryptfs.cpp can't use the SOFTWARE keymaster on those devices.
There's also already an upgrade path in place (see
test_mount_encrypted_fs() in cryptfs.cpp) to upgrade the kdf that's
being used once a TEE keymaster is added to the device. So it's safe for
cryptfs.cpp to ask for a TEE keymaster from Keystore2 and use it
blindly, without checking whether or not it's a "real" TEE, which is why
Keymaster::isSecure() just returns true now. A future patch will remove
that function and simplify its callers.
Bug: 181910578
Test: cuttlefish and bramble boot. Adding, switching between, stopping
and removing users work.
Change-Id: Iaebfef082eca0da8a305043fafb6d85e5de14cf8
HardwareAuthTokens are no longer used by vold since Android P. So remove
the auth token parameter from vold. This patch doesn't remove the token
from IVold.aidl, and the methods in VoldNativeService.cpp return an
error if a non-empty auth token is passed to them.
Bug: 181910578
Test: cuttlefish and bramble boot with patch
Change-Id: I1a9f54e10f9efdda9973906afd0a5de5a699ada5
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
Until VerificationTokens are wired up, StrongBox can't work. Also,
this will reduce complications for early StrongBox testing.
Bug: 77338527
Test: Boot the device
Change-Id: I44a1577c388703aeecb2886e7db52084c17e2afd
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
The compatibility check assumes that the keymaster session was created
successfully which is a faulty assumption.
This patch adds propper error handling to the check.
Bug: 35576166
Change-Id: I0c70a0e53f488f8bd3164898722f490cd0573ce3
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
The getService() and registerAsService() methods of interface objects
now have default parameters of "default" for the service name. HALs
will not have to use any service name unless they want to register
more than one service.
Test: marlin boots
Bug: 33844934
Change-Id: I7c68c8b9ab0101b2f10ca20b9971a5bd34377168
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
- catch errors in looking for the keyring
- static_assert to prevent a buffer overrun
- remove obsolete, misleading comment
- dial down priority of some log messages
- explain why we ignore some errors
- idiomatic C++11
Bug: 27552432
Change-Id: Ic3ee05b41eae45e7c6b571a459b326a483663526
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
