WAL mode attempts to open an additional file for use as a shared memory
mechanism. If storage is too full, then the database fails to open.
Remove the use of WAL mode so that keystore can perform read-only
transactions on the database and startup even on a full disk.
Disabling WAL mode shows about a 5% performance drop on a synthetic test
that creates and destroys 5000 AES keys.
Bug: 190142197
Test: keystore2_test
Change-Id: I9b1cb7e6398e07fa9f02f0ba4e9eb48313c06472
Merged-In: I9b1cb7e6398e07fa9f02f0ba4e9eb48313c06472
We should not panic when a checksum failure happens during shared key
negotiation. This is typical for pre production devices that have not
been fully provisioned yet. Not panicking gives the user the chance to
finalize the provisioning step.
Bug: 190702219
Test: N/A
Merged-In: I0c847b52f2c63c6c2eef0765cc1536daa0893d1c
Change-Id: I0c847b52f2c63c6c2eef0765cc1536daa0893d1c
The km_compat legacy wrapper would only cache the first shared secret
participant and then return this participant regardless of which
security level was requested. As a result only one Keymaster instance
would take part in the shared secret negotiation.
This patch adds a per security level cache for ISharedSecret instances
to km_compat. It filters Keymaster instances in Keystore 2.0 to only
include the highest version of each HIDL Keymaster security level.
Bug: 190539964
Test: See b/190539964
Merged-In: I0b73da88d3e1b6900cfb332c1befc704eca59cc5
Change-Id: I0b73da88d3e1b6900cfb332c1befc704eca59cc5
Modify odsign to verify an existing CompOS cert and add it to the
fs-verity keyring if ok or delete it if not.
The significant new behaviour is all behind an if (false), since
there's still a lot to do (like making it possible for a valid cert to
exist).
Otherwise, various refactorings and gratuitous tinkering.
Bug: 190166662
Bug: 188450218
Test: Presubmits
Test: Manual - push various differently-invalid certs & observe
Change-Id: I51021c95fa4670d5fd022783565b1e215962483b
Set notBefore and notAfter times using strings rather then architecture
dependent time_t.
Bug: 185119443
Test: atest keystore2_crypto_test
Merged-In: I83e64829b20d965f800e648d9b5d1452c526cb35
Change-Id: I83e64829b20d965f800e648d9b5d1452c526cb35
When generating the boot level zero key the operation params were
missing the digest parameter which throws off some KM implementaions.
Ignore-AOSP-First: No automerge path from AOSP.
Bug: 187862706
Test: Reboot twice after applying the patch. Check logs from odsign for
sucessful recovery of boot level keys.
Change-Id: Ic719fcaae4fc3f5550fcf14b55143c1ca1f125cc
Merged-In: Ic719fcaae4fc3f5550fcf14b55143c1ca1f125cc
This patch uses the database versioning mechanism to delete boot level
bound keys that have been generated before cryptographic binding to the
boot level was implemented.
Ignore-AOSP-First: No automerge path from AOSP.
Bug: 187862706
Test: keystore2_test
Change-Id: I34999d7633e4ef17205b055e11751f0498ae6932
Merged-In: I34999d7633e4ef17205b055e11751f0498ae6932
This patch adds database versioning.
When a KeystoreDB connection is opened, the database file is queried for
its version. If the version is lower than current version expected by
keystore2, upgrade function are executed until the target version is
reached and the database version is updated.
Ignore-AOSP-First: No automerge path from AOSP.
Test: keystore2_test (Note the test is added in this CL but not included
in keystore2_test yet. This will happen in the next CL.)
Bug: 187862706
Bug: 189470584
Change-Id: Ia75633942dbb8f168e781579e1c9a755c84671af
Merged-In: Ia75633942dbb8f168e781579e1c9a755c84671af
This refactor makes key type an explicit to relevant database function
to make it harder to implicitly use the wrong type.
Ignore-AOSP-First: No automerge path from AOSP.
Bug: 187862706
Bug: 189470584
Test: Regression tested with keystore2_test.
Change-Id: I9e1416743093f0a1ab86fd9351aed97f106ee819
Merged-In: I9e1416743093f0a1ab86fd9351aed97f106ee819
Check the key characteristics of the level zero key to verify its
integrity.
Ignore-AOSP-First: No automerge path from AOSP.
Bug: 187862706
Test: N/A
Change-Id: Id83e581781507e499790e77729b0e2d96795f908
Merged-In: Id83e581781507e499790e77729b0e2d96795f908
Prefer KM4.1 and higher over KM4.0 and lower, but prefer TEE over
Strongbox if TEE meets the minimal requirements.
Ignore-AOSP-First: No automerge path from AOSP.
Bug: 187862706
Test: Manually tested by observing logs during boot.
Merged-In: I1d27c80ef7c869b84b6d0c1a5d8eec287c242f6c
Change-Id: I1d27c80ef7c869b84b6d0c1a5d8eec287c242f6c
Merged-In: I1d27c80ef7c869b84b6d0c1a5d8eec287c242f6c
The upstream RSA APIs are annoyingly tedious, but ah well. Note
X509_set1_signature_algo sets both copies of the signature algorithm.
This also fixes an EVP_PKEY leak in some error paths.
Test: mm
Change-Id: Ifa6f130e9d7dce328c649aa241057dbe5c0e5e66
* changes:
On-device signing: Remove Keymaster implementation.
On-device signing: verify the public key.
On-device signing: Switch to using a TEE-backed keystore key.
While we can generally trust the key properties of the Keystore key to
be correct, the public key certificate that Keystore returns in
KeyMetadata is simply retrieved from an on-disk database. This allows
an attacker that gets filesystem access to simply modify the public key,
and we will happily accept that (and the artifacts that are signed with
the private key component).
To prevent this, sign the public key itself with another HMAC key that
carries the same boot level as the signing key. This is secure, because
in order to forge such a signature, an attacker would need to create an
HMAC key with the same boot level, which is not possible once early boot
has passed.
Bug: 187862706
Test: TEST_MAPPING
Change-Id: I688fff83f73b1df4e91c3fa03c43df647703d9f8
We previously used a Strongbox key; but since we'll need to start
verifying the public key component with an HMAC operation on every boot,
switch to a TEE key instead, as TEE operations are much faster, and
this should help bring boot time down.
This also requires some logic to deal with keys in Strongbox on
updating devices.
Bug: 187862706
Test: TEST_MAPPING; manual upgrade test.
Change-Id: Ib99d689dbef02d2f0c34bfa4c852205b1ec680a7
Running keystore_cli_v2 as root included user0 super keys in the list of
keys. This revealed that the database list keys query was not
restrictive enough.
Bug: 188451778
Test: keystore_cli_v2 list as root should not include any super keys.
Merged-In: I803b7c19f3cdb8a29fbc114e74da1b0dc2473c81
Change-Id: I803b7c19f3cdb8a29fbc114e74da1b0dc2473c81
* Fix keystore_cli_v2 and have it installed on the device by default
again.
* Fix confirmationui invocation test by statically linking dependencies.
Bug: 188450250
Test: atest confirmationui_invocation_test
run any keystore_cli_v2 command
Merged-In: I7097646b6714214782cf15c51dffb7368d62761b
Change-Id: I7097646b6714214782cf15c51dffb7368d62761b
With these changes, the test easily identifies threading issues by
calling selinux concurrenly. With no locking in the selinux rust module,
this test causes hard locks very quickly (usually within 2 iterations).
Fixed test hangs (false positives) by adding an explicit "complete" to
all all threads instead of using the turnpike for both test start and
test complete.
Added some debug output and increased the iteration count to run the
test longer, getting more confidence in passing tests.
Lastly, use synthetically generated categories (CatCount) for all test
threads instead of just one thread. This seems to both make the test
more "abusive" of selinux as well as reduces test code size.
Test: Remove selinux lock and run keystore2_selinux_concurrency_test
Test: keystore2_selinux_concurrency_test with selinux lock
Change-Id: I796147397da021ca5c78fe8b60aa3853d1a882a3
This test attempts to corrupt the access vector cache of libselinux by
calling selinux_check_access concurrently. The test will fail if the
cache gets corrupted in such a way that selinux_check_access ends up in
an infinite loop.
Test: atest keystore2_selinux_concurrency_test
Bug: 184006658
Change-Id: I357a4454281bdec9865ac1d8a8343378bac1698d
This is a rework of the previously reverted commit
6a50983169, which was attempting to set
WAL mode after startup. It turns out that doing this can race with other
code that is trying to use the DB, resulting in DB lock errors.
Bug: 184006658
Test: CtsKeystoreTestCases
Change-Id: I737fd2750c3157a732c2677eaabf8aa114f42832
This reverts commit 6a50983169.
Reason for revert: Bug 187889158. We forgot to account for database locks in the WAL mode set, and apparently some devices are running into locked dbs.
Change-Id: I43f8cb231397adc69ac6286b64a943cff55629c1
