The boot failure symptom is reproduced on Walleye devices. System boots
up after taking OTA and try to upgrade key, but keymaster returns "failed
to ugprade key". Device reboots to recovery mode because of the failure,
and finally trapped in bootloader screen. Possible scenario is:
(After taking OTA)
vold sends old key and op=UPGRADE to keymaster
keymaster creates and saves new key to RPMB, responses new key to vold
vold saves new key as temp key
vold renames temp key to main key -------------- (1) -- still in cache
vold sends old key and op=DELETE_KEY to keymaster
keymaster removes old key from RPMB ------------ (2) -- write directly to RPMB
==> SYSTEM INTERRUPTED BY CRASH OR SOMETHING; ALL CACHE LOST.
==> System boots up, key in RPMB is deleted but key in storage is old key.
Solution: A Fsync is required between (1) and (2) to cover this case.
Detail analysis: b/124279741#comment21
Bug: 112145641
Bug: 124279741
Test: Insert fault right after deleteKey in vold::begin (KeyStorage.cpp),
original boot failure symptom is NOT reproducible.
Change-Id: Ia042b23699c37c94758fb660aecec64d39f39738
Merged-In: Ib8c349d6d033f86b247f4b35b8354d97cf249d26
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
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
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
If it's not a keymaster key, don't try to invalidate or delete the key
blob.
Bug: 25861755
Test: Create and forget a volume, check logs and files.
Change-Id: If8bfb1a9ab41e6c7e46bc311eb296242e56d264f
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
This is used by LockSettingsService to delete sensitive credential files.
Bug: 34600579
Test: manual - change device lock under synthetic password, verify
old data on disk is erased.
Change-Id: I5e11b559ad8818bd2ad2b321d67d21477aab7555
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
Keymaster but in-process crypto.
Bug: 33384925
Test: manual for now: patch KeyAuthentication.usesKeymaster() to always return true;
flash a FBE device, add a device PIN, reboot and verify PIN can unlock FBE.
Then clear device PIN, reboot and verify FBE is unlocked automatically.
In both cases, check there is no keymaster_key_blob in
/data/misc/vold/user_keys/ce/0/current/
Unit tests to be added.
Change-Id: Ia94e2b39d60bfd98c7a8347a5ba043eeab6928c5
Don't rely on cryptographic binding of secdiscard to key; securely
delete the other information needed to reconstruct the key too.
Bug: 26021231
Change-Id: If03d2c051b0ec2fdcb5c6f70bde7e3287424f216
Avoid a timeout error by extending the time allowed between getting
the auth token and decrypting the key from five to thirty seconds.
Bug: 28398766
Change-Id: I1dbb9e0e33707e7de4c1720ad1b8e153c77094b2
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
A bug meant that the auth token wasn't being used; it turns out that
in order to use it we need to do things slightly differently.
Bug: 27496553
Change-Id: I0f0ab77fed31b92a79eba4acf488cb098691b4be
- 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
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
