platform_system_security/keystore/user_state.cpp

312 lines
9.7 KiB
C++
Raw Normal View History

/*
* Copyright (C) 2016 The Android Open Source Project
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#define LOG_TAG "keystore"
#include "user_state.h"
#include <dirent.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/stat.h>
#include <openssl/digest.h>
#include <openssl/evp.h>
#include <openssl/rand.h>
#include <log/log.h>
#include "blob.h"
#include "keystore_utils.h"
Multithreaded Keystore 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
2018-10-08 16:15:09 +02:00
namespace keystore {
Port to binderized keymaster HAL 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
2016-10-13 19:43:45 +02:00
Multithreaded Keystore 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
2018-10-08 16:15:09 +02:00
UserState::UserState(uid_t userId)
: mMasterKeyEntry(".masterkey", "user_" + std::to_string(userId), userId, /* masterkey */ true),
mUserId(userId), mState(STATE_UNINITIALIZED) {}
Multithreaded Keystore 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
2018-10-08 16:15:09 +02:00
bool UserState::operator<(const UserState& rhs) const {
return getUserId() < rhs.getUserId();
}
bool UserState::operator<(uid_t userId) const {
return getUserId() < userId;
}
Multithreaded Keystore 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
2018-10-08 16:15:09 +02:00
bool operator<(uid_t userId, const UserState& rhs) {
return userId < rhs.getUserId();
}
bool UserState::initialize() {
Multithreaded Keystore 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
2018-10-08 16:15:09 +02:00
if ((mkdir(mMasterKeyEntry.user_dir().c_str(), S_IRUSR | S_IWUSR | S_IXUSR) < 0) &&
(errno != EEXIST)) {
ALOGE("Could not create directory '%s'", mMasterKeyEntry.user_dir().c_str());
return false;
}
Multithreaded Keystore 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
2018-10-08 16:15:09 +02:00
if (mMasterKeyEntry.hasKeyBlob()) {
setState(STATE_LOCKED);
} else {
setState(STATE_UNINITIALIZED);
}
return true;
}
void UserState::setState(State state) {
mState = state;
}
void UserState::zeroizeMasterKeysInMemory() {
memset(mMasterKey.data(), 0, mMasterKey.size());
memset(mSalt, 0, sizeof(mSalt));
}
bool UserState::deleteMasterKey() {
setState(STATE_UNINITIALIZED);
zeroizeMasterKeysInMemory();
Multithreaded Keystore 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
2018-10-08 16:15:09 +02:00
return unlink(mMasterKeyEntry.getKeyBlobPath().c_str()) == 0 || errno == ENOENT;
}
ResponseCode UserState::initialize(const android::String8& pw) {
if (!generateMasterKey()) {
Port to binderized keymaster HAL 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
2016-10-13 19:43:45 +02:00
return ResponseCode::SYSTEM_ERROR;
}
ResponseCode response = writeMasterKey(pw);
Port to binderized keymaster HAL 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
2016-10-13 19:43:45 +02:00
if (response != ResponseCode::NO_ERROR) {
return response;
}
setupMasterKeys();
Port to binderized keymaster HAL 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
2016-10-13 19:43:45 +02:00
return ResponseCode::NO_ERROR;
}
Multithreaded Keystore 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
2018-10-08 16:15:09 +02:00
ResponseCode UserState::copyMasterKey(LockedUserState<UserState>* src) {
if (mState != STATE_UNINITIALIZED) {
Port to binderized keymaster HAL 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
2016-10-13 19:43:45 +02:00
return ResponseCode::SYSTEM_ERROR;
}
Multithreaded Keystore 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
2018-10-08 16:15:09 +02:00
if ((*src)->getState() != STATE_NO_ERROR) {
Port to binderized keymaster HAL 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
2016-10-13 19:43:45 +02:00
return ResponseCode::SYSTEM_ERROR;
}
mMasterKey = (*src)->mMasterKey;
setupMasterKeys();
return copyMasterKeyFile(src);
}
Multithreaded Keystore 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
2018-10-08 16:15:09 +02:00
ResponseCode UserState::copyMasterKeyFile(LockedUserState<UserState>* src) {
/* Copy the master key file to the new user. Unfortunately we don't have the src user's
* password so we cannot generate a new file with a new salt.
*/
Multithreaded Keystore 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
2018-10-08 16:15:09 +02:00
int in = TEMP_FAILURE_RETRY(open((*src)->getMasterKeyFileName().c_str(), O_RDONLY));
if (in < 0) {
Port to binderized keymaster HAL 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
2016-10-13 19:43:45 +02:00
return ResponseCode::SYSTEM_ERROR;
}
blobv3 rawBlob;
size_t length = readFully(in, (uint8_t*)&rawBlob, sizeof(rawBlob));
if (close(in) != 0) {
Port to binderized keymaster HAL 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
2016-10-13 19:43:45 +02:00
return ResponseCode::SYSTEM_ERROR;
}
Multithreaded Keystore 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
2018-10-08 16:15:09 +02:00
int out = TEMP_FAILURE_RETRY(open(mMasterKeyEntry.getKeyBlobPath().c_str(),
O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR | S_IWUSR));
if (out < 0) {
Port to binderized keymaster HAL 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
2016-10-13 19:43:45 +02:00
return ResponseCode::SYSTEM_ERROR;
}
size_t outLength = writeFully(out, (uint8_t*)&rawBlob, length);
if (close(out) != 0) {
Port to binderized keymaster HAL 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
2016-10-13 19:43:45 +02:00
return ResponseCode::SYSTEM_ERROR;
}
if (outLength != length) {
ALOGW("blob not fully written %zu != %zu", outLength, length);
Multithreaded Keystore 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
2018-10-08 16:15:09 +02:00
unlink(mMasterKeyEntry.getKeyBlobPath().c_str());
Port to binderized keymaster HAL 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
2016-10-13 19:43:45 +02:00
return ResponseCode::SYSTEM_ERROR;
}
Port to binderized keymaster HAL 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
2016-10-13 19:43:45 +02:00
return ResponseCode::NO_ERROR;
}
ResponseCode UserState::writeMasterKey(const android::String8& pw) {
Fix handling of user password changes. A bug introduced in a patch intended to upgrade keystore master keys to use AES-256 and SHA-256 instead of AES-128 and SHA1 causes the newly-updated master key to fail to be retrievable ever again. Making this worse, after five successive failures, keystore decided that all the data is bad and wipes the user's keystore. This problem happens on every password change if the master key is 128 bits. Luckily, since the introduction of synthetic passwords to support escrow tokens, the password presented to keystore is the synthetic password, which never changes. So this problem only crops up in devices that did not have synthetic passwords (launched with Android N or earlier), were not upgraded to O DR1 (when synthetic passwords were enabled by default), were never factory reset or had their password removed and re-added during all of that time and were then upgraded to P or Q, when the master key upgrade code was present. This CL fixes the upgrade process so that updated master keys can be used. It doesn't change the key size, the keys stay 128 bits, but now they're readable and usable. Factory resetting allows an entirely new master key to be generated, which will be AES-256. Note that the keystore master key is not really essential to the security of Keystore keys. They're also encrypted by the secure world (TEE or SE), which is their primary protection. The master key just provides a cryptographic dependency on the user's password, so that in the event of a secure world break the attacker still has to brute force the user's password to recover the key material, or use of the protected keys. Bug: 129970023 Test: Manual Change-Id: I8ce2bb2359cf822039c137bb6bb1fc225da47c29
2019-10-02 01:43:43 +02:00
std::vector<uint8_t> passwordKey(mMasterKey.size());
generateKeyFromPassword(passwordKey, pw, mSalt);
Fix handling of user password changes. A bug introduced in a patch intended to upgrade keystore master keys to use AES-256 and SHA-256 instead of AES-128 and SHA1 causes the newly-updated master key to fail to be retrievable ever again. Making this worse, after five successive failures, keystore decided that all the data is bad and wipes the user's keystore. This problem happens on every password change if the master key is 128 bits. Luckily, since the introduction of synthetic passwords to support escrow tokens, the password presented to keystore is the synthetic password, which never changes. So this problem only crops up in devices that did not have synthetic passwords (launched with Android N or earlier), were not upgraded to O DR1 (when synthetic passwords were enabled by default), were never factory reset or had their password removed and re-added during all of that time and were then upgraded to P or Q, when the master key upgrade code was present. This CL fixes the upgrade process so that updated master keys can be used. It doesn't change the key size, the keys stay 128 bits, but now they're readable and usable. Factory resetting allows an entirely new master key to be generated, which will be AES-256. Note that the keystore master key is not really essential to the security of Keystore keys. They're also encrypted by the secure world (TEE or SE), which is their primary protection. The master key just provides a cryptographic dependency on the user's password, so that in the event of a secure world break the attacker still has to brute force the user's password to recover the key material, or use of the protected keys. Bug: 129970023 Test: Manual Change-Id: I8ce2bb2359cf822039c137bb6bb1fc225da47c29
2019-10-02 01:43:43 +02:00
auto blobType = TYPE_MASTER_KEY_AES256;
if (mMasterKey.size() == kAes128KeySizeBytes) {
blobType = TYPE_MASTER_KEY;
}
Blob masterKeyBlob(mMasterKey.data(), mMasterKey.size(), mSalt, sizeof(mSalt), blobType);
Multithreaded Keystore 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
2018-10-08 16:15:09 +02:00
auto lockedEntry = LockedKeyBlobEntry::get(mMasterKeyEntry);
return lockedEntry.writeBlobs(masterKeyBlob, {}, passwordKey, STATE_NO_ERROR);
}
ResponseCode UserState::readMasterKey(const android::String8& pw) {
Multithreaded Keystore 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
2018-10-08 16:15:09 +02:00
auto lockedEntry = LockedKeyBlobEntry::get(mMasterKeyEntry);
int in = TEMP_FAILURE_RETRY(open(mMasterKeyEntry.getKeyBlobPath().c_str(), O_RDONLY));
if (in < 0) {
Port to binderized keymaster HAL 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
2016-10-13 19:43:45 +02:00
return ResponseCode::SYSTEM_ERROR;
}
// We read the raw blob to just to get the salt to generate the AES key, then we create the Blob
// to use with decryptBlob
blobv3 rawBlob;
size_t length = readFully(in, (uint8_t*)&rawBlob, sizeof(rawBlob));
if (close(in) != 0) {
Port to binderized keymaster HAL 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
2016-10-13 19:43:45 +02:00
return ResponseCode::SYSTEM_ERROR;
}
// find salt at EOF if present, otherwise we have an old file
uint8_t* salt;
if (length > SALT_SIZE && rawBlob.info == SALT_SIZE) {
salt = (uint8_t*)&rawBlob + length - SALT_SIZE;
} else {
salt = nullptr;
}
size_t masterKeySize = MASTER_KEY_SIZE_BYTES;
if (rawBlob.type == TYPE_MASTER_KEY) {
Fix handling of user password changes. A bug introduced in a patch intended to upgrade keystore master keys to use AES-256 and SHA-256 instead of AES-128 and SHA1 causes the newly-updated master key to fail to be retrievable ever again. Making this worse, after five successive failures, keystore decided that all the data is bad and wipes the user's keystore. This problem happens on every password change if the master key is 128 bits. Luckily, since the introduction of synthetic passwords to support escrow tokens, the password presented to keystore is the synthetic password, which never changes. So this problem only crops up in devices that did not have synthetic passwords (launched with Android N or earlier), were not upgraded to O DR1 (when synthetic passwords were enabled by default), were never factory reset or had their password removed and re-added during all of that time and were then upgraded to P or Q, when the master key upgrade code was present. This CL fixes the upgrade process so that updated master keys can be used. It doesn't change the key size, the keys stay 128 bits, but now they're readable and usable. Factory resetting allows an entirely new master key to be generated, which will be AES-256. Note that the keystore master key is not really essential to the security of Keystore keys. They're also encrypted by the secure world (TEE or SE), which is their primary protection. The master key just provides a cryptographic dependency on the user's password, so that in the event of a secure world break the attacker still has to brute force the user's password to recover the key material, or use of the protected keys. Bug: 129970023 Test: Manual Change-Id: I8ce2bb2359cf822039c137bb6bb1fc225da47c29
2019-10-02 01:43:43 +02:00
masterKeySize = kAes128KeySizeBytes;
}
std::vector<uint8_t> passwordKey(masterKeySize);
generateKeyFromPassword(passwordKey, pw, salt);
Multithreaded Keystore 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
2018-10-08 16:15:09 +02:00
Blob masterKeyBlob, dummyBlob;
ResponseCode response;
std::tie(response, masterKeyBlob, dummyBlob) =
lockedEntry.readBlobs(passwordKey, STATE_NO_ERROR);
Port to binderized keymaster HAL 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
2016-10-13 19:43:45 +02:00
if (response == ResponseCode::SYSTEM_ERROR) {
return response;
}
size_t masterKeyBlobLength = static_cast<size_t>(masterKeyBlob.getLength());
if (response == ResponseCode::NO_ERROR && masterKeyBlobLength == masterKeySize) {
// If salt was missing, generate one and write a new master key file with the salt.
if (salt == nullptr) {
if (!generateSalt()) {
Port to binderized keymaster HAL 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
2016-10-13 19:43:45 +02:00
return ResponseCode::SYSTEM_ERROR;
}
response = writeMasterKey(pw);
}
Port to binderized keymaster HAL 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
2016-10-13 19:43:45 +02:00
if (response == ResponseCode::NO_ERROR) {
mMasterKey = std::vector<uint8_t>(masterKeyBlob.getValue(),
masterKeyBlob.getValue() + masterKeyBlob.getLength());
setupMasterKeys();
}
return response;
}
LOG(ERROR) << "Invalid password presented";
return ResponseCode::WRONG_PASSWORD_0;
}
bool UserState::reset() {
Multithreaded Keystore 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
2018-10-08 16:15:09 +02:00
DIR* dir = opendir(mMasterKeyEntry.user_dir().c_str());
if (!dir) {
// If the directory doesn't exist then nothing to do.
if (errno == ENOENT) {
return true;
}
ALOGW("couldn't open user directory: %s", strerror(errno));
return false;
}
struct dirent* file;
while ((file = readdir(dir)) != nullptr) {
// skip . and ..
if (!strcmp(".", file->d_name) || !strcmp("..", file->d_name)) {
continue;
}
unlinkat(dirfd(dir), file->d_name, 0);
}
closedir(dir);
return true;
}
void UserState::generateKeyFromPassword(std::vector<uint8_t>& key, const android::String8& pw,
uint8_t* salt) {
size_t saltSize;
if (salt != nullptr) {
saltSize = SALT_SIZE;
} else {
// Pre-gingerbread used this hardwired salt, readMasterKey will rewrite these when found
salt = (uint8_t*)"keystore";
// sizeof = 9, not strlen = 8
saltSize = sizeof("keystore");
}
const EVP_MD* digest = EVP_sha256();
// SHA1 was used prior to increasing the key size
Fix handling of user password changes. A bug introduced in a patch intended to upgrade keystore master keys to use AES-256 and SHA-256 instead of AES-128 and SHA1 causes the newly-updated master key to fail to be retrievable ever again. Making this worse, after five successive failures, keystore decided that all the data is bad and wipes the user's keystore. This problem happens on every password change if the master key is 128 bits. Luckily, since the introduction of synthetic passwords to support escrow tokens, the password presented to keystore is the synthetic password, which never changes. So this problem only crops up in devices that did not have synthetic passwords (launched with Android N or earlier), were not upgraded to O DR1 (when synthetic passwords were enabled by default), were never factory reset or had their password removed and re-added during all of that time and were then upgraded to P or Q, when the master key upgrade code was present. This CL fixes the upgrade process so that updated master keys can be used. It doesn't change the key size, the keys stay 128 bits, but now they're readable and usable. Factory resetting allows an entirely new master key to be generated, which will be AES-256. Note that the keystore master key is not really essential to the security of Keystore keys. They're also encrypted by the secure world (TEE or SE), which is their primary protection. The master key just provides a cryptographic dependency on the user's password, so that in the event of a secure world break the attacker still has to brute force the user's password to recover the key material, or use of the protected keys. Bug: 129970023 Test: Manual Change-Id: I8ce2bb2359cf822039c137bb6bb1fc225da47c29
2019-10-02 01:43:43 +02:00
if (key.size() == kAes128KeySizeBytes) {
digest = EVP_sha1();
}
PKCS5_PBKDF2_HMAC(reinterpret_cast<const char*>(pw.string()), pw.length(), salt, saltSize, 8192,
digest, key.size(), key.data());
}
bool UserState::generateSalt() {
return RAND_bytes(mSalt, sizeof(mSalt));
}
bool UserState::generateMasterKey() {
mMasterKey.resize(MASTER_KEY_SIZE_BYTES);
if (!RAND_bytes(mMasterKey.data(), mMasterKey.size())) {
return false;
}
if (!generateSalt()) {
return false;
}
return true;
}
void UserState::setupMasterKeys() {
setState(STATE_NO_ERROR);
}
Multithreaded Keystore 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
2018-10-08 16:15:09 +02:00
LockedUserState<UserState> UserStateDB::getUserState(uid_t userId) {
std::unique_lock<std::mutex> lock(locked_state_mutex_);
decltype(mMasterKeys.begin()) it;
bool inserted;
std::tie(it, inserted) = mMasterKeys.emplace(userId, userId);
if (inserted) {
if (!it->second.initialize()) {
/* There's not much we can do if initialization fails. Trying to
* unlock the keystore for that user will fail as well, so any
* subsequent request for this user will just return SYSTEM_ERROR.
*/
ALOGE("User initialization failed for %u; subsequent operations will fail", userId);
}
}
return get(std::move(lock), &it->second);
}
LockedUserState<UserState> UserStateDB::getUserStateByUid(uid_t uid) {
return getUserState(get_user_id(uid));
}
LockedUserState<const UserState> UserStateDB::getUserState(uid_t userId) const {
std::unique_lock<std::mutex> lock(locked_state_mutex_);
auto it = mMasterKeys.find(userId);
if (it == mMasterKeys.end()) return {};
return get(std::move(lock), &it->second);
}
LockedUserState<const UserState> UserStateDB::getUserStateByUid(uid_t uid) const {
return getUserState(get_user_id(uid));
}
} // namespace keystore