67899de5ade4bc2a6ffae54f2e66cd5d99b67029 |
|
21-Apr-2017 |
Rubin Xu <rubinxu@google.com> |
Introduce KEYSTORE_FLAG_CRITICAL_TO_DEVICE_ENCRYPTION This flag is used by system server to mark keys used during the synthetic password auth flow. keys marked with this flag will not be super encrypted because super encryption requires knowledge of the synthetic password, causing a chicken-and-egg problem. Bug: 35849499 Bug: 34600579 Test: cts-tradefed run cts-dev -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.MixedProfileOwnerTest#testResetPasswordWithToken Change-Id: Ibd900e3ede1f51c476d462085caaf216d911d693
/system/security/keystore/include/keystore/keystore.h
|
d5a24e6745eb552c137cfdbb49e09e3db5701ad1 |
|
28-Feb-2017 |
Shawn Willden <swillden@google.com> |
Superencrypt authentication-bound keys. This CL causes keystore to automatically encrypt all newly-created keymaster key blobs which are authentication-bound. This appears on its face to be pointless, since the sensitive key material in the key blobs is already encrypted by the Trusted Execution Environment. It's not pointless because this adds a cryptographic dependency on the user's password, including any strengthening performed by LockSettingService... which may include the use of a separate hardware trusted module, separate from (and presumably more secure than) the TEE. A better solution is planned for the next release, but that requires changes to Gatekeeper and Keymaster. This superencryption will be removed when that work is done. Note that the encryption method used by keystore is weak. A separate CL will replace the weak method with a proper authenticated encryption. (cherry picked from commit 07aebe73053df12c21c7481a93146bd76add7fbd) Test: Manual testing. Bug: 35849499 Change-Id: I0c4910ea24b97bc8046f3d114bfb336670d03321
/system/security/keystore/include/keystore/keystore.h
|
c7a9fa29c185a8c1889486d4acf00fd59c513870 |
|
13-Oct-2016 |
Janis Danisevskis <jdanis@google.com> |
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
/system/security/keystore/include/keystore/keystore.h
|
aebbfc2ba548064e4f537154bab6ec60dfe4115e |
|
23-Apr-2015 |
Chad Brubaker <cbrubaker@google.com> |
Move auth token checking to begin Auth tokens will now be checked on begin and then used for all subsequent calls for that operation, this means that things like auth timeouts will only be checked on begin, and operation that starts at timeout - .00001 will now be able to be used to completion. One exception to this is keys that use per operation authorization. Begin for these operations must succeed so that the application gets a handle to authorize. For those keys if the application calls update before authorizing the operation the call will fail. For these keys begin will return OP_AUTH_NEEDED so let the caller know more work is needed before using the operation. Change-Id: I5dda40803e7b2aecac27defc64d6d3f630d3f0d0
/system/security/keystore/include/keystore/keystore.h
|
17208e0de5a42722901d803118745cca25fd10c1 |
|
04-Sep-2013 |
Kenny Root <kroot@google.com> |
Provide fallback for keymaster implementations Some implementations won't support ECDSA or DSA, so provide a fallback for them by using the softkeymaster implementation. This will allow us to universally support ECDSA and DSA on all platforms regardless of HAL version. Bug: 10600582 Change-Id: Ib842816cc1415ec00abb7d22c8e9b6bbe58f6a86
/system/security/keystore/include/keystore/keystore.h
|
0c540aad5915e6aa34345049be96f28b64d0e84c |
|
03-Apr-2013 |
Kenny Root <kroot@google.com> |
keystore: Add flag for blobs to be unencrypted In order to let apps use keystore more productively, make the blob encryption optional. As more hardware-assisted keystores (i.e., hardware that has a Keymaster HAL) come around, encrypting blobs start to make less sense since the thing it's encrypting is usually a token and not any raw key material. Bug: 8122243 Change-Id: I7d70122beb32b59f06a923ade93234393b75a2cd
/system/security/keystore/include/keystore/keystore.h
|
07438c8d7256d3788dac323b4d0055f201e0bec9 |
|
02-Nov-2012 |
Kenny Root <kroot@google.com> |
Switch keystore to binder Change-Id: I6dacdc43bcc1a56e47655e37e825ee6a205eb56b
/system/security/keystore/include/keystore/keystore.h
|