Since the keystore alias prefix USERSKEY was deprecated
Credentials.deleteUserKeyTypeForAlias tried to delete key the
remaining prefix first and if that failed tried to delete the
legacy prefix.
However, KeyStore.delete returns true if the key was deleted or
did not exist. So the first call to delete would return true
whether the key existed or not and the legacy alias would never be
deleted.
This patch introduces a new flavor of KeyStore.delete, that returns an
error code instead of a boolean. The caller can now distinguish
the nature of the failure. Credentials.deleteUserKeyTypeForAlias now
checks this return code and attempts to delete the legacy variant if
KEY_NOT_FOUND was returned.
Bug: 117818447
Change-Id: Ifae1f3dbb07d85d94f430ead2cdd3e39d22436a4
The legacy support importKey method uses the wrong method to add date
fields to the import keymaster arguments.
Bug: 119549023
Change-Id: Iff841086f6616303b365ad28aae429ccae1f3406
API stubs generation implicitly made any types used by an API also part
of that API. This has caused DeviceIdAttestationException and
ImsFeature.Capabilities to become implicit APIs, so they are added to
the API files.
After this, using non-API types in APIs will become an error to prevent
implicit APIs occuring in the future.
Bug: 119556446
Test: METALAVA_PREPEND_ARGS="--error ReferencesHidden" make
Change-Id: I5fe4f20502b8d4e287b28e9f07139456d4191e22
listUidsForAuthBoundKeys was added to IKeyStoreService.
This CL exposes this method in KeyStore for system apps.
This method will be hidden for non system apps.
Bug: b/112321280
Test: listUidsForAuthBoundKeys in IKeyStoreService has its own tests
Test: This method cannot be tested directly from CTS
Change-Id: Iac9e863079a1367ddb3a599bc3825baea96a1c31
This patch makes the framework use the asynchronous keystore api model.
Bug: 111443219
Test: Ran full keystore cts test suite
Change-Id: I8d1fdc70cb9eb501d3f22a97d1221904c2ef8f9a
In preparation for making the keystore service asynchronous we remove
redundant legacy functionality from the protocol.
This patch removes the functions get_pubkey, sign, verify, generate,
and import_key. Which have long been superseded by exportKey
(get_pubkey), begin/update/finish (sign, verify), generateKey
(generate), and importKey (import_key).
This patch also removes isOperationAuthorized.
Test: KeyStore CTS tests
Bug: 111443219
Change-Id: Ib3bd6f40b4e948e5ad6b2ef5278b18ff46201d71
In preparation to the async keystore interface we change the semantics
form unconditionally overwriting existing keys to reporting that the key
exists. For compatibility we reimplement the same semantic in the
calling code.
Bug: 111443219
Test: KeyStore CTS test
Change-Id: I1fa5428fa7ada97d5068778cd4590593c992554d
Biometrics are now generic from KeyStore point of view
Bug: 113624536
Test: Unable to create keys when no templates enrolled
Test: Able to create keys when templates are enrolled
Test: No regression in Fingerprint
Keys are invalidated after enrolling another FP
Change-Id: I6bdc20eb58c8a0c10a986519d4ba9e1843ebc89d
The caller to KeyChain.choosePrivateKeyAlias can restrict the set of
aliases that are displayed to the user to select from by specifying the
issuers that the associated certificates should be issued by or the key
types that these certificates should contain.
Until now this functionality was not implemented. This was mostly
affecting Chrome
(https://bugs.chromium.org/p/chromium/issues/detail?id=753756).
Support this functionality by passing the issuers and key types into the
KeyChainActivity (from KeyChain) and, prior to displaying the aliases
associated with the certificates, check if each certificate adheres to
the criteria (key type, issues) specified.
Bug: 62910781
Test: m -j RunKeyChainRoboTests
Change-Id: I75e071545699891cfbd77d4f706fc5ef35b85516
Check for brand parameter specified in config file. Implementing suggestion that was added to the original CL (ag/4791307) after it was submitted.
Bug: 69471841
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testKeyManagement
Change-Id: I9b257f406d5b47265db4dbf022df75865f496cdd
Some Pixel devices had a wrong brand value provisioned into keymaster.
Due to this misprovisioning those devices fail device ID attestation because it includes a check for the correct brand value.
This is now solved by re-trying Device ID attestation if we are running on a potentially misprovisioned device, allowing for the known incorrect brand value.
Bug: 69471841
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testKeyManagement
Change-Id: Ia0da5478d6092c1927d26600a6893ae8ce53da51
Some Pixel devices had a wrong brand value provisioned into keymaster.
Due to this misprovisioning those devices fail device ID attestation because it includes a check for the correct brand value.
This is now solved by re-trying Device ID attestation if we are running on a potentially misprovisioned device, allowing for the known incorrect brand value.
Bug: 69471841
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testKeyManagement
Change-Id: If715ebdd4ab6d7fcfffab60b40fd2dc8fa1fda44
Merged-In: Ia0da5478d6092c1927d26600a6893ae8ce53da51
An Android-O timeframe refactor removed all use of keystore "skey"
aliases. Creating one not only partially reverses that refactor, but
it also results in a key alias which cannot be deleted in some cases,
causing AndroidKeyStoreTest failures during the second run of CTS.
Bug: 80228327
Test: CTS tests ImportWrappedKeyTest and AndroidKeyStoreTest, in that order
Change-Id: I348ba421f29cdf6c65fc98be3a25d19938d559c1
For packages:
android.security.net.config
android.security.keystore
android.security.keymaster
android.security
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: Ifed4da56531195f64fd53d84f14b4e8298843b2c
Merged-In: I7762dd647bede8abc9be2c538af3a3a99a25a73e
For packages:
android.security.net.config
android.security.keystore
android.security.keymaster
android.security
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I7762dd647bede8abc9be2c538af3a3a99a25a73e
@UnsupportedAppUsage annotations are added automatically, but this does
not work when there are multiple definitions on the same line.
Test: m
Bug: 110868826
Change-Id: I2c26c136cdfa557e45cf1ee0b39dab9c17abde56
The strongbox flag was not passed to keystore by
AndroidKeyStoreKeyGeneratorSpi. As a result keys, that were supposed to
be generated in strongbox would silently be generated in TEE.
Test: There is no reliable way to test this other than instrumenting or
debugging the strongbox implementation. This was done by the
author of this patch.
Bug: 109769728
Change-Id: I8a08838440030fab7b774762c3d6af0d3b6a4ad8
Merged-In: I8a08838440030fab7b774762c3d6af0d3b6a4ad8
The strongbox flag was not passed to keystore by
AndroidKeyStoreKeyGeneratorSpi. As a result keys, that were supposed to
be generated in strongbox would silently be generated in TEE.
Test: There is no reliable way to test this other than instrumenting or
debugging the strongbox implementation. This was done by the
author of this patch.
Bug: 109769728
Change-Id: I8a08838440030fab7b774762c3d6af0d3b6a4ad8
When the caller attempts to generate a key via DevicePolicyManager
(using DevicePolicyManager.generateKeyPair), and specifies that
StrongBox should be used, throw the right exception indicating
StrongBox unavailability - the same one that is thrown if the same
parameters were passed to the KeyStore's key generation method.
This is achieved by catching the StrongBoxUnavailableException in
KeyChain, returning an error code indicating this particular failure
to the DevicePolicyManagerService, which then propagates it by
throwing a service-specific exception with a value indicating
StrongBox unavailability.
The DevicePolicyManager then raises StrongBoxUnavailableException.
Prior to this change the exception propagated from KeyChain would be
a generic failure so the caller would simply get a null result.
Bug: 110882855
Bug: 111183576
Bug: 111322478
Test: atest CtsDevicePolicyManagerTestCases:com.android.cts.devicepolicy.MixedDeviceOwnerTest#testKeyManagement
Change-Id: I9abe3f449b48eb5a960fafbc15c59b9b4ce7a966
Due to an oversight, some of the key generation parameters that are set
in KeyGenParameterSpec were not preserved when parceling the object
(they should have been added to ParcelableKeyGenParameterSpec but were
not).
This means these parameters will be ignored when generating keys using
the DevicePolicyManager.generateKeyPair method, leading to an
inconsistent key generation behaviour between the DevicePolicyManager
and KeyStore.
In particular, this would prevent callers from using StrongBox when
generating keys for use in the KeyChain.
Fix the issue by simply persisting these parameters in
ParcelableKeyGenParameterSpec and making sure that the Builder copies
them too from the source KeyGenParameterSpec.
Left to do is put in place an automated measure to find out
discrepancies between the two classes.
Bug: 110915980
Bug: 110882855
Bug: 109953656
Test: atest KeystoreTests
Change-Id: Ic64bd2921b6dfc97ea34ecba55f532312963ffcb
