This is the second CL on migrating keystore logging to statsd.
This migrates the logging for key operation events.
Three new ResponseCodes are added for the logging purpose of the
abort operations.
Test: Adding tests for logging is yet to be decided.
Change-Id: Iede72341b0f4c80199c9e16cef96a5d98bca8754
Merged-In: I68c1d89beeb733e4b6ba493b8d95935b7e73df60
This is the first part of the update, adjusting keystore to use the
KM4.1 interface, but not call any of the new methods. That will come
in a subsequent CL.
Test: CtsKeystoreTestCases
Change-Id: Ib7486aad46c144471a1607eec31b8df1059a511d
Merged-In: Ib7486aad46c144471a1607eec31b8df1059a511d
This change will reduce the number of files written to dropbox for the
purposes of keystore logging. Previously, if a ton of operations were
being done, a file would be created for each operation which led to
spamming of the dropbox directory.
Now, all equivalent operations are counted and only one copy is sent
along with the corresponding count over the time period of an hour. This
limits the number of files keystore can write to dropbox to 24 a day,
and will reduce the possible size of files since redundant operations
aren't being written.
Bug: 117823210
Bug: 110988360
Test: atest cts/tests/tests/keystore/src/android/keystore/cts
Change-Id: I79367aa7a8eb3679aace2058e128d06e513e25ea
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
This will allow us to track the actual usage patterns of keystore
functions and error occurences.
Bug: 36549319
Test: DropBox logging works for keystore tags
Change-Id: Iadfba3afebaa0be753212b1111b68f50b77f9978
(cherry picked from commit d6d8952b34)
The Operation interface confused me. It looked like it was holding a
pointer to an auth token from the AuthTokenTable. In fact it made a
copy, but that wasn't clear from the interface. Ths CL changes
Operation::setOperationAuthtoken to take the token by value, making
clear that it copies (unless std::move is used).
Test: runtest --path cts/tests/tests/keystore/src/android/keystore/cts
Change-Id: I1d1b6983f421f5be9f56c60aaf56dda8fc4aa207
Auth tokens have an unfortunate dual character. To most of the system
they are opaque blobs that are intended only to be obtained from one
HAL (e.g. gatekeeper or fingerprint) and passed to another
HAL (keymaster), but keystore actually needs to extract some bits of
information from them in order to determine which of the available blobs
should be provided for a given keymaster key operation.
This CL adds a method that resolves this dual nature by moving the
responsibility of parsing blobs to the HAL so that no component of the
framework has to make any assumptions about their content and all can
treat them as fully opaque. This still means that the various HAL
implementers have to agree on content, but they also have to agree on an
HMAC key which much be securely distributed to all at every boot, so
asking them to agree on an auth token format is perfectly
acceptable. But now the Android system doesn't have to care about the
format.
Bug: 32962548
Test: CTS tests pass, plus manual testing.
Change-Id: I2ab4b4fbea1425fc08aa754fc10f8e386899af25
This patch ports keystore to the HIDL based binderized keymaster HAL.
Keystore has no more dependencies on legacy keymaster headers, and
therefore data structures, constant declarations, or enums. All
keymaster related data structures and enums used by keystore are the
once defined by the HIDL based keymaster HAL definition. In the process
of porting, keystore underwent some changes:
* Keystore got a new implementation of AuthorizationSet that is fully
based on the new HIDL data structures. Key parameters are now either
organised as AuthorizationSets or hidl_vec<KeyParameter>. (Formerly,
this was a mixture of keymaster's AuthorizationSet,
std::vec<keymaster_key_param_t>, and keymaster_key_param_set_t.) The
former is used for memory management and provides algorithms for
assembling, joining, and subtracting sets of parameters. The latter
is used as wire format for the HAL IPC; it can wrap the memory owned
by an AuthorizationSet for this purpose. The AuthorizationSet is
accompanied by a new implementation of type safe functions for
creating and accessing tagged key parameters,
Authorizations (keystore/keymaster_tags.h).
* A new type (KSSReturnCode) was introduced that wraps keystore service
response codes. Keystore has two sets of error codes. ErrorCode
errors are less than 0 and use 0 as success value. ResponseCode
errors are greater than zero and use 1 as success value. This patch
changes ResponseCode to be an enum class so that is no longer
assignable to int without a cast. The new return type can only be
initialized by ResponseCode or ErrorCode and when accessed as int32_t,
which happens on serialization when the response is send to a client,
the success values are coalesced onto 1 as expected by the
clients. KSSreturnCode is also comparable to ResponseCode and
ErrorCode, and the predicate isOk() returns true if it was initialized
with either ErrorCode::OK (0) or ReponseCode::NO_ERROR (1).
* A bug was fixed, that caused the keystore verify function to return
success, regardless of the input, internal errors, or lack of
permissions.
* The marshalling code in IKeystoreService.cpp was rewritten. For data
structures that are known to keymaster, the client facing side of
keystore uses HIDL based data structures as (target) source
for (un)marshaling to avoid further conversion. hidl_vecs are used to
wrap parcel memory without copying and taking ownership where
possible.
* Explicit use of malloc is reduced (malloc was required by the C nature
of the old HAL). The new implementations avoid explicit use of
malloc/new and waive the use of pointers for return values. Instead,
functions return by value objects that take ownership of secondary
memory allocations where required.
Test: runtest --path=cts/tests/tests/keystore/src/android/keystore/cts
Bug: 32020919
Change-Id: I59d3a0f4a6bdf6bb3bbf791ad8827c463effa286
* Use const reference type for parameters, local variables,
and for-loop index variables to avoid unnecessary copy.
Bug: 30407689
Bug: 30413223
Bug: 30413862
Change-Id: I3b9383f34e466ca6b5290bad802d535443fd0187
Test: build with WITH_TIDY=1
This CL doesn't wire in any of the new keymaster2 features, it just uses
the keymaster2 HAL rather than the keymaster1 HAL. This means that if
keymaster1 hardware is found, it is unconditionally wrapped in
SoftKeymasterDevice, so keymaster2 functionality can (eventually) be
provided.
Change-Id: Ica2cb0751e4e0a82c56c36b03f94da54ef62d9a3
keystore service's begin operation may sometimes encounter a situation
where the underlying device's begin operation fails because of too
many operations in progress. In that case, keystore attempts to prune
the oldest pruneable operation by invoking the underlying device's
abort operation. Regardless of whether the abort operation fails,
keystore then removes the operation from the list of in-progress
prunable operations.
The issue is that when the underlying device's abort operation fails,
keystore fails the begin operation that caused all this prunining.
This is despite the fact that keystore has managed to make space for
one more operation.
The fix is to fail the begin operation only if the pruning attempt
did not make space for a a new operation.
Bug: 22040842
Change-Id: Id98b2c6690de3cfb2a7b1d3bdd10742cc59ecbfa
The operation map caches the hw_auth_token used to start the operation
but it was storing the pointer returned by the auth token table and not
the token itself leading to a potential use-after-free if the token was
removed from the table between the operation starting and completeting.
The operation table now stores the auth token itself instead of the
pointer provided by the auth table.
Change-Id: I80fd49655ed98e7879d2caa7f1ae077ff50e0e54
Auth tokens will now be checked on begin and then used for all
subsequent calls for that operation, this means that things like
auth timeouts will only be checked on begin, and operation that starts
at timeout - .00001 will now be able to be used to completion.
One exception to this is keys that use per operation authorization.
Begin for these operations must succeed so that the application gets a
handle to authorize. For those keys if the application calls update
before authorizing the operation the call will fail. For these keys
begin will return OP_AUTH_NEEDED so let the caller know more work is
needed before using the operation.
(cherry picked from commit aebbfc2ba5)
Change-Id: I3da4f93a076c0ed2d8630ca8cd1608e9bad2c2ff
Instead of storing the key blob and parsing the characteristics out,
which some implementations might not support, instead call get
characteristics on begin and store that result for subsequent auth
calls.
Change-Id: I75e39ee28cc440e4ed411b2daaa2744085e1aa12
Auth tokens are now fetched from the table in begin update and finish if
needed. Begin will not fail on a missing/expired auth token since some
authorization requires a valid operation handle.
This doesn't yet do any enforcement of the token beyond what the auth
token table does, that should happen in the keymaster auth code when it
is done.
This also includes the key in the operation map since authorization
works based off that and not the handle.
Change-Id: I62a395b74a925b819f4cde75ae3bfab8b8928cd1
