| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
https://android.googlesource.com/platform/system/security into HEAD
Android 9.0.0 Release 51 (5948683)
* tag 'android-9.0.0_r51' of https://android.googlesource.com/platform/system/security:
Encrypt AES-256 keystore master keys.
Fix keystore wifi concurrency issue.
keystore: abort if verification token generation fails
Revert "Restore "Add "Unlocked device required" parameter to keys""
Revert "Add "Unlocked device required" parameter to keys"
Disable CFI for the keystore unit tests.
Change-Id: I079714aa7e711782741acbc249dd5e12bdc4dead
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
ag/5984229 that added support for AES-256 master keys inadvertently
caused them not to be encyrpted by the user's password. This is less
damaging to security than it might appear because these keys are also
encrypted by Keymaster, in the TEE or StrongBox.
Bug: 141955555
Test: Manually verify password is encryption on a userdebug build.
Change-Id: Ic5e82546df67346e4c348273cf4fe2bac382c9dc
Merged-In: Ie44a4097e058bd5b9e45aa73115c266b9570a4fc
(cherry picked from commit 58e675567c446b77c6ec83d8e07fecbd829f60ae)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
NIAP certification finds that the 128 bit key size is insufficient
and requires a 256 bit key size. This change increases the
size of new master keys to 256 bits. Any existing master keys are
not changed and continue to be supported.
A new BlobType, TYPE_MASTER_KEY_AES256, is used to signal when a
key is the new larger size.
Bug: 121272336
Test: (1) Ran Keystore CTS tests against Walleye,
no new test failures observed.
(2) Created keys in build without change, moved to build
with change and verified old key could be loaded and
used. Also, a new key could be created with the
increased size and could be reloaded after a reboot.
Change-Id: Ie120f514bc1db7a8a9eeaaf842178bafe128ee19
Merged-In: If00331c303e6cc7bc95a2ab624d0e19bec4e587e
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In the future the key size for new master keys will increase.
To maintain backwards compatibility the size of the key
can no longer be assumed. To help communicate the actual
size of the key, it will be passed around in a vector.
Bug: 121272336
Test: Ran Keystore CTS tests against Walleye,
no new test failures observed
Change-Id: Ie74eaf5226398e2300eb266ddda269473593e9d4
Merged-In: I4c05acb15b77959f2bf89abbdc325904fffb497a
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
/dev/urandom is not an approved random number generator
for NIAP certification. Changing to use BoringSSL's
RAND_bytes(), which is approved.
Bug: 121272336
Test: Ran Keystore CTS tests against Walleye, no new
test failures observed.
Change-Id: I0fb87c955512074fa714c1986ce99063ab430470
Merged-In: I579d140ef56c90b477b0d8989e3b02375681aee8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Logs key integrity violation in two cases:
1. software-detected corruption of key blob.
2. keymaster operation returning INVALID_KEY_BLOB
Changed AES_gcm_decrypt to return VALUE_CORRUPTED on decryption errors
to be consistent with digest check for older version blob.
Bug: 70886042
Test: manual, by patching some bytes in the blob.
Test: cts-tradefed run cts -m CtsKeystoreTestCases
Change-Id: Ic8f6b7a2a49aee01253b429644af409e568d7deb
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Keymaster4 introduces security levels. Android devices
may have multiple keymaster implementations, one for each
possible security level, where the presence of a strong
security level implies the presence of all lower levels.
This patch adds code that enumerates all keymaster device
implementations available from ServiceManager and populates
Keystore's keymaster device database with at most one keymaster
implementation per security level. It gives precedence to
newer versions if multiple implementations exist for the same security
level.
The security level is chosen by a set of flags passed to the keystore
operations generate, import, addRngEntropy.
For existing keys the right security level is chosen by the blob flags.
To that end a new flag KEYSTORE_FLAG_STRONGBOX was added, and the
security level is expressed through a combination of
KEYSTORE_FLAG_FALLBACK (F) and KEYSTORE_FLAG_STRONGBOX (S).
Encoding is as follows:
F S
Software 1 X (don't care)
TEE 0 0
Strongbox 0 1
Some operations in keystore cli2 where amended with the optional
--seclevel flags. Allowing the user to chose the security level for the
given operation. Possible options are "software", "strongbox", and "tee"
where tee is the default value.
Test: Existing KeyStore CTS tests run
Change-Id: I01ef238f5e7067e480cf9b171630237236046bb1
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When auth-bound keys are used after the screen lock has been removed it
is expected that getKeyCharacteristics still succeeds. However, when the
super encrypt feature was introduced the key blob is no longer
accessible, and thus, the retrieving the key characteristics fails.
This patch retrieves the key characteristics from the characteristics
cache file, which is not super encrypted. Using such a key still fails
but in ways expected by the framework.
Bug: 65200397
Test: CtsVerifier ScreenLockBoundKeysTest:
1. Run test
2. with CtsVerifier in the background remove the screen lock
through the settings dialog
3. Select VtsVerifier in 'recents'
4. Run test again
Change-Id: Ifa88c58a41c376e4f800a76114d4cf9149506ac0
|
| |
|
|
|
|
| |
Bug:35849499
Test: None required.
Change-Id: Iadee02a253b491f192c4a8b1cf3e57125ad866a6
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Keystore currently uses AES-CBC to encrypt keystore blobs, plus an MD5
digest for authentication. This scheme is mildly broken (b/26804580),
but has not been replaced because keystore encryption was slated for
removal. In order to support cryptographic binding of keys to user
authentication on devices with trusted secure computing modules,
keystore encryption has temporarily become relevant again, until a
better solution can be constructed. Thus there's a motivation to
replace the broken scheme with a proper authenticated encryption mode.
Along the way, this CL also fixes a low-priority security vulnerability,
b/31824325.
Bug: 26804580
Bug: 31824325
Bug: 35849499
Test: Manually tested the new scheme and upgrading from the old scheme
Change-Id: I139f2a7b7a3c01eade4e2d2a674d49d027179d43
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It's clashing with synthetic password flow due to the fact that
synthetic password flow requires an auth-bound key in keystore,
but when the key is being requested, keystore is yet to receive
the synthetic password so it can't encrypt the auth-bound key
Bug: 37474130
Bug: 35849499
Test: cts-tradefed run cts-dev -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.MixedProfileOwnerTest#testResetPasswordWithToken
Change-Id: I58b05f1464d2c85a30ce17fbf5d7eca5da114173
|
| |
|
|
|
|
|
|
|
| |
This fixes a bug introduce in ag/2108644. That CL added automatic
super-encryption of authentication-bound keys, but missed the necessary
change to decrypt them when needed.
Test: Manually tested
Change-Id: I84693b145a6d57d5957aa40d10236e1a0610d12c
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
This CL isn't nearly as big as it looks. It doesn't change keystore
functionality, it just moves all of the classes out of the former
keystore.cpp into their own .h and .cpp files.
Note that this is a cherry-pick from:
https://android-review.googlesource.com/#/c/194971
Change-Id: Ide326c4f1d03984994d1bd9a76fa68d37da230dc
|
