It turns out there are more clients that use Keystore in a creative
way. This patch renames the VpnProfileStore to LegacyKeystore and
extends the functionality such that it allows access to all blobs with
alias prefixes that were not known to Keystore. It also brings back the
option to specify a uid argument. Specifically, for AID_SYSTEM to
manipulate the WIFI namespace.
Test: TBD
Bug: 191373871
Merged-In: Iaf81e7ccaee3c09a465dcec0fd5899b781c31db5
Change-Id: Iaf81e7ccaee3c09a465dcec0fd5899b781c31db5
Production keys are 6 bytes smaller than test keys due to the absence of
an entry in the COSE_Key map which would denote that key as a test key.
(-70000, nil). This patch properly adjusts for the size difference
between the two keys.
Bug: 189018262
Test: Let the provisioner run.
Change-Id: I9ff0c99e58a1691c8e7bdedb0cbeafb683b39722
Merged-In: I9ff0c99e58a1691c8e7bdedb0cbeafb683b39722
WAL mode was disabled, but one of the VPN profile store tests was
still checking to ensure WAL mode was enabled.
Fixes: 191099248
Test: keystore2_test
Test: vpnprofilestore_test
Change-Id: Ib02057e01bbc73ac3b744a4298fc388487fb61a8
Merged-In: Ib02057e01bbc73ac3b744a4298fc388487fb61a8
This may allow us to recover in certain bad situations. Also, add some
more clear error logs when failing to create/delete a key, to make it
easier to debug failures.
Bug: 190711210
Test: TEST_MAPPING
Change-Id: Ib9a9ce0c0d0e99ce44d124af85775780f448a854
struct fsverity_formatted_digest (previously called
fsverity_signed_digest) is now in <linux/fsverity.h>, so there is no
longer any need to have a local definition of it.
Test: build
Change-Id: Ie3623a56fe6415d686a51ddfde8a1ebab83b8364
This tool has been made obsolete by rkp_factory_extraction_tool
Test: n/a -- nothing uses this tool
Change-Id: Ic15ff9e526809dd7dae0d9f17b79fd7ff87f61c7
The test was disabled and got stale. Fix the test so it uses the GC,
as it's useful for checking perf-related code changes. Will investigate
fully re-enabling the test on T.
Bug: 190142197
Test: keystore2_test
Change-Id: Ifc0a4a5b3c8c301c42d068ee46754d877eeb10bc
Merged-In: Ifc0a4a5b3c8c301c42d068ee46754d877eeb10bc
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
If we have a persisted key blob and public key for CompOS, but no
cert, then get CompOS to verify that they are genuine. If so, we can
generate a new cert for the public key. Otherwise we fall back to
generating a new keypair.
Once again I have made a few unrelated changes as I understand things
better.
Bug: 190166662
Test: Presubmit
Test: Manual - various valid & missing/invalid files.
Change-Id: I1bcb7f89698c103f413bdb899026bfd2578447db
Note: the CompOS work here is all still behind an if (false).
Added a new class, FakeCompOs, to allow prototyping of the interface
and implementation of the key management work that will be in CompOS.
Extensive refactoring of the certificate generation code to support
both a self-signed cert and our certificate for the CompOS key.
Bug: 190166662
Test: presubmits
Test: manual - certificate gets generated on first boot
Test: manual - certificate verifies ok on second boot
Test: manual inspection of the generated certs' text form
Change-Id: I2f2f043427774c0805e963dfe582feb8d3eac3a4
When attempting to load a non-existent cert I got:
06-10 12:48:11.939 662 662 E fsverity_init: Failed to add key: Invalid argument
06-10 12:48:11.940 662 662 E fsverity_init: Failed to load key from stdin
06-10 12:48:11.941 648 648 I odsign : Added CompOs key to fs-verity keyring
Which looks like everything worked when nothing did.
Added more error checks on both sides.
Test: Presubmits
Test: Manual
Change-Id: Ib2b17ce75e58dafb0ad6905106e35b11b55e91d0
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
