This is useful when the caught exceptions are not informative and they
act as a red herring in the adb logs.
Bug:109791294
Test: call this method in the VpnSettings and manually navigate to
adding a new VPN by searching for VPN in settings and then pressing '+'.
Change-Id: I4bc86e3ea5b11027090fd3a27dc7455557cf66ab
Merged-In: I4bc86e3ea5b11027090fd3a27dc7455557cf66ab
If a certificate is self signed, then currently KeyStore will still
attempt to find the CA certificate. When it obviously fails to find it,
a key not found exception is propagated up and thrown. This CL
suppresses that exception, as it seems to exclusively be thrown in this
condition, which is WAI. Having the stack trace show up can be very
misleading to developers.
Test: atest cts/tests/tests/keystore/src/android/keystore/cts
Change-Id: I192f54d3d8355c183e830ab09314932e8800f7ed
For packages:
android.security
android.service.dreams
android.service.euicc
android.service.vr
android.service.wallpaper
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
Merged-In: I1c8ae08f8d3b4b2f5bf365468f22155f8def09fe
Change-Id: I09850a52193a28b0f884cfa01b564c29d25d41ed
This is to keep it in sync with response codes in keystore.h.
This commit also adds the KeyPermanentlyInvalidatedException to all the
methods that could receive this error code out of KeyStore.
Bug: 118883532
Test: atest cts/hostsidetests/appsecurity/src/android/appsecurity/cts/AuthBoundKeyTest.java
Change-Id: I878a628824e2eeb639ec5678b1a5d3d10428a918
Merged-In: I878a628824e2eeb639ec5678b1a5d3d10428a918
Previously the framework would accept any key size that was a multiple
of 8 for the KeyGenerator.
Bug: 117509689
Bug: 122274787
Test: atest cts/tests/tests/keystore/src/android/keystore/cts/KeyGeneratorTest.java
Change-Id: I60b52f6062a41ae52486bae0ae36616f4b532b37
Add the Android Enterprise Security team as OWNERS for KeyChain and
KeyChain-related code.
The KeyChain code currently lives under keystore/, which means every
change requires Keystore owners approval, but it does not make sense for
KeyChain as KeyChain is a Keystore client and is developed
independently.
Test: Gerritt upload.
Bug: 33166666
Change-Id: Idfedda9553add303439179ce10a1e75e437bbe83
Members modified herein are suspected to be false positives: i.e. things
that were added to the greylist in P, but subsequent data analysis
suggests that they are not, in fact, used after all.
Add a maxTargetSdk=P to these APIs. This is lower-risk that simply
removing these things from the greylist, as none of out data sources are
perfect nor complete.
For APIs that are not supported yet by annotations, move them to
hiddenapi-greylist-max-p.txt instead which has the same effect.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Change-Id: Ia937d8c41512e7f1b6e7f67b9104c1878b5cc3a0
Merged-In: I020a9c09672ebcae64c5357abc4993e07e744687
engineInit() for AndroidKeyStoreKeyGeneratorSpi does not make a call
into the backing Keymaster implementation until generate is called on it
to actually create the key. If a disallowed spec for StrongBox is passed
in, the backing StrongBox implementation won't be able to revoke it
until engineGenerateKey() is called, which will create different
behaviors between TEE backed implementations (which support a wider
range of algorithm spec parameters) and StrongBox implementations from a
public API perspective. This change will make sure HMAC is the same for
StrongBox.
This is also being done for EC keys in
AndroidKeyStoreKeyPairGeneratorSpi.java
Bug: 113525261
Bug: 114487149
Test: atest cts/tests/tests/keystore/src/android/keystore/cts/KeyGeneratorTest.java
Test: atest
cts/tests/tests/keystore/src/android/keystore/cts/KeyPairGeneratorTest.java
Change-Id: I728bb5222c9bf0ad84cdf2b8c0b78a4dd99f7186
Why?: 1) Returning an array list is unsafe because it must be allocated in Java and C++ must not change the size. 2) List<Integer> is not supported by AIDL, but List<String> is. I decided it was simpler to pass back integers encoded as strings than to create yet another parcelable.
Bug: b/119616956
Test: ./list_auth_bound_keys_test.sh
Test: Temporarily modified settings app to call listUidsOfAuthBoundKeys
Change-Id: I3bf7578c96e800c8d35fba897f52220136dcd657
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
Exempt-From-Owner-Approval: Identical CL has been approved on other branch
Change-Id: I5fe4f20502b8d4e287b28e9f07139456d4191e22
Merged-In: I5fe4f20502b8d4e287b28e9f07139456d4191e22
(cherry picked from commit 8f91e5fde8272e2040c60222d6a5ba0314fa44ac)
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
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 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
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
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
(cherry picked from commit 3f821a8e17f97a6f0b3ae408b2e7f2bfde666df4)
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
@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
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
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
Improve the choosePrivateKeyAlias documentation by:
(1) removing reference to host+port when a URI is being passed in.
(2) Clearing up the language about what a DPC can do.
Test: N/A
Bug: 81522642
Change-Id: I12fbf675536ea5d843dd2eec4f0379daad764bb6
Get unwrapping params from WrappedKeyEntry
Add @hide API for StrongBox-backed imported keys (as opposed to wrapped or generated)
Enable 3DES conditionally based on a system property.
Bug: b/79986479
Bug: b/79986680
Test: CTS
Change-Id: If6beedc203337027576ecd3555d11ed2874f9768
Both the code and docstring support this, but the parameters weren't
annotated.
Test: it builds locally
Change-Id: I16beddcd74a86047ce9aaf37007d96f3e8e0d4e0
Merged-In: I16beddcd74a86047ce9aaf37007d96f3e8e0d4e0
Fix: 78868934
(cherry picked from commit b7c5eddc53c3872b661222ae30270d95cfe63b4e)
Rather than rely on getDeviceId to provide the MEID, explicitly use
getMeid to get it.
For MEID attestation to work, the right identifier needs to be passed in
for attestation by Keymaster.
AttestationUtils currently gets this identifier by calling getDeviceId.
This would only yield the MEID if the device does not have an IMEI
provisioned, which means it'll get the IMEI for devices that have both
(like Pixel 2).
According to bartfab@ that is the correct way (see b/77584730#13).
Bug: 77584730
Bug: 73284024
Test: runtest --path cts/tests/tests/keystore/src/android/keystore/cts/KeyAttestationTest.java
Change-Id: I98f6c2e2a9835bf2fd681cfb4ff74fc3984c3a8e
Add @TestApi to allow CTS tests to use that call.
Encryption and decryption are reversed in some documentation.
Test: CtsKeystoreTestCases
Bug: 77596526
Change-Id: Ifaf8b3fa0e231eef256451a2514219fff1b16699
The existing name is misleading, because it can be read as requiring
that a trusted user be present, rather than the intended meaning of
requiring trusted proof of user presence. Since this is all about
TEE/SE-based keys, the "trusted" part is implied, so the simple
"userPresenceRequired" name makes more sense.
Bug: 77151288
Test: Keystore CTS tests
Change-Id: If8b533b9f34a1875eaf35cdd1bb8f3709da9761b
The call the framework uses to get the current user ID requires the
INTERACT_ACROSS_USERS permission, which not a lot of apps will have.
Find a better way to do that.
Bug: 76430246
Test: CtsKeystoreTestCases
Change-Id: I8a0637d351fff9cfbf40e02946325f90466b68c5
