This patch addes verbose logging whenever an error code in the vendor
error code range is returned by keymaster.
Bug: 123562864
Test: atest android.keystore.cts
Merged-In: Ifceece542d6f3536ad87d053145c7aa8dd6d6603
Change-Id: Ifceece542d6f3536ad87d053145c7aa8dd6d6603
/dev/urandom is not an approved random number generator
for NIAP certification. Changing to use BoringSSL's
RAND_bytes(), which is approved.
Bug: 121272336
Test: Ran Keystore CTS tests against Walleye
Change-Id: I579d140ef56c90b477b0d8989e3b02375681aee8
The keystore dispatcher thread must not hold any locks when it calls
LockedKeyBlobEntry::list.
Also fixed an issue with the KeyBlobEntry conparisson function that lead
to clients beeing blockd by each other if they edit the same alias at
the same time altough they have different name spaces.
Test: A script that is currently under development. Stay tuned
Change-Id: I1d7f46cc27b3d90305a0ea64b8859d85b42996d8
This patches changes the keystore to use the asychronous api model for
begin, update, finish, and abort.
Also removes unused class KeystoreArguments (aidl and implementation).
Test: Keystore CTS tests
Bug: 111443219
Change-Id: Icc6def9ff6dbe32193272d7d015079a006ebc430
This patch transitions keystore a threading model with one dispatcher
thread and one worker thread per keymaster instance, i.e. fallback, TEE,
Strongbox (if available). Singleton objects, such as the user state
database, the enforcement policy, and grant database have been moved to
KeyStore and were made concurrency safe.
Other noteworthy changes in this patch:
* Cached key characteristics. The key characteristics file used to hold
a limited set of parameters used generate or import the key. This
patch introduces a new blob type that holds full characteristics as
returned by generate, import, or getKeyCharacteristics, with the
original parameters mixed into the software enforced list. When
keystore encounters a lagacy characteristics file it will grab the
characteristics from keymaster, merge them with the cached parameters,
and update the cache file to the new format. If keystore encounters
the new cache no call to keymaster will be made for retrieving the
key characteristics.
* Changed semantic of list. The list call takes a prefix used for
filtering key entries. By the old semantic, list would return a list
of aliases stripped of the given prefix. By the new semantic list
always returns a filtered list of full alias string. Callers may
strip prefixes if they are so inclined.
* Entertain per keymaster instance operation maps. With the introduction
of Strongbox keystore had to deal with multiple keymaster instances.
But until now it would entertain a single operations map. Keystore
also enforces the invariant that no more than 15 operation slots are
used so there is always a free slot available for vold. With a single
operation map, this means no more than 15 slots can ever be used
although with TEE and Strongbox there are a total of 32 slots. With
strongbox implementation that have significantly fewer slots we see
another effect of the single operation map. If a slot needs to be
freed on Stronbox but the oldest operations are on TEE, the latter
will be unnecessarily pruned before a Strongbox slot is freed up.
With this patch each keymaster instance has its own operation map and
pruning is performed on a per keymaster instance basis.
* Introduce KeyBlobEntries which are independent from files. To allow
concurrent access to the key blob data base, entries can be
individually locked so that operations on entries become atomic.
LockedKeyBlobEntries are move only objects that track ownership of an
Entry on the stack or in functor object representing keymaster worker
requests. Entries must only be locked by the dispatcher Thread. Worker
threads can only be granted access to a LockedKeyBlobEntry by the
dispatcher thread. This allows the dispatcher thread to execute a
barrier that waits until all locks held by workers have been
relinquished to perform blob database maintenance operations, e.g.,
clearing a uid of all entries.
* Verification tokens are now acquired asynchronously. When a begin
operation requires a verification token a request is submitted to the
other keymaster worker while the begin call returns. When the
operation commences with update or finish, we block until the
verification token becomes available.
As of this patch the keystore IPC interface is still synchronous. That
is, the dispatcher thread dispatches a request to a worker and then
waits until the worker has finished. In a followup patch the IPC
interface shall be made asynchronous so that multiple requests may be in
flight.
Test: Ran full CTS test suite
atest android.keystore.cts
Bug: 111443219
Bug: 110495056
Change-Id: I305e28d784295a0095a34810d83202f7423498bd
Logs key integrity violation in two cases:
1. software-detected corruption of key blob.
2. keymaster operation returning INVALID_KEY_BLOB
Changed AES_gcm_decrypt to return VALUE_CORRUPTED on decryption errors
to be consistent with digest check for older version blob.
Bug: 70886042
Test: manual, by patching some bytes in the blob.
Test: cts-tradefed run cts -m CtsKeystoreTestCases
Change-Id: Ic8f6b7a2a49aee01253b429644af409e568d7deb
This is required by NIAP audit logging requirements.
import and destruction events contain key name and uid.
Keystore is added to "log" secondary group to be able to write
to security buffer.
Test: manual, imported and deleted key via Settings while
monitoring adb shell su - logcat -b security
Bug:70886042
Change-Id: Iebb29380da5251ff66609884e615aabc379cd389
Keymaster4 introduces security levels. Android devices
may have multiple keymaster implementations, one for each
possible security level, where the presence of a strong
security level implies the presence of all lower levels.
This patch adds code that enumerates all keymaster device
implementations available from ServiceManager and populates
Keystore's keymaster device database with at most one keymaster
implementation per security level. It gives precedence to
newer versions if multiple implementations exist for the same security
level.
The security level is chosen by a set of flags passed to the keystore
operations generate, import, addRngEntropy.
For existing keys the right security level is chosen by the blob flags.
To that end a new flag KEYSTORE_FLAG_STRONGBOX was added, and the
security level is expressed through a combination of
KEYSTORE_FLAG_FALLBACK (F) and KEYSTORE_FLAG_STRONGBOX (S).
Encoding is as follows:
F S
Software 1 X (don't care)
TEE 0 0
Strongbox 0 1
Some operations in keystore cli2 where amended with the optional
--seclevel flags. Allowing the user to chose the security level for the
given operation. Possible options are "software", "strongbox", and "tee"
where tee is the default value.
Test: Existing KeyStore CTS tests run
Change-Id: I01ef238f5e7067e480cf9b171630237236046bb1
The "Keymaster" class provides an abstraction that hides the
underlying implementation. It will always inherit the current
IKeymasterDevice version and extend it with additional pure virtual methods
that are used by keystore to query for meta information. This class
will in turn have subclasses which will wrap an instance of each
different version of IKeymasterDevice that we support.
Test: CTS
Change-Id: I62420dc0a8c196bb3f19753a8f304d46a75fae0e
We currently have two different keystore.h files. This renames one of
them, and the corresponding implementation, to KeyStore.h, which
tracks the class name.
Test: runtest --path cts/tests/tests/keystore/src/android/keystore/cts
Change-Id: I910e3d60d165b65d055e7da92acd04d3ee73a6d3
