KeyChain supports device id attestation through KeyGenParameterSpec now.
No need to call attest key individually. Also calling attest key
individually is no longer supported by Keystore 2.0 and KeyMint.
Also isBoundKeyAlgorithm returns true.
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Bug: 171305387
Merged-In: I759fe245b48fe435153fded2c74c9ae99634c146
Change-Id: I759fe245b48fe435153fded2c74c9ae99634c146
KeyChain supports device id attestation through KeyGenParameterSpec now.
No need to call attest key individually. Also calling attest key
individually is no longer supported by Keystore 2.0 and KeyMint.
Also isBoundKeyAlgorithm returns true.
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Bug: 171305387
Change-Id: I759fe245b48fe435153fded2c74c9ae99634c146
* KeyChain API to check if the caller is the
credential management app.
* KeyChain API to get the authentication policy
if the caller is the credential management app.
* KeyChain createManageCredentialsIntent docs
mention startActivityForResult should be used
Bug: 177979648
Test: atest android.devicepolicy.cts.CredentialManagementAppTest
Change-Id: Ia5125adb677ec103a9d5a5318edf95050e74916e
* Add setCredentialManagementApp and
removeCredentialManagementApp
to KeyChain
* Add permission to manage credential
management app, which is to be used in
CTS tests
Bug: 165641221
Test: atest android.devicepolicy.cts.CredentialManagementAppTest
Change-Id: I8487ebc13758a31639d55c8e380faa51d1cfd843
KeyChain.bindAsUser() couldn't be called on the main thread because
it was using the main thread to handle service connection callback.
Add an overload of KeyChain.bindAsUser() that accepts an alternative
handler to process the connection callback, which makes it possible
to call KeyChain from the main UI thread directly.
Bug: 165641221
Test: atest KeyChainTests
Test: m RunKeyChainRoboTests
Change-Id: I4290bccf5ae04de0d84c7091729e86704b937295
- This is part of the work to support
a credential management app on
unmanaged devices.
- Add intent and method in KeyChain to allow
an app to request to become the credential
management app.
- Add the class CredentialManagementApp to store the
current credential management app.
- Add the class AppUriAuthenticationPolicy and an
extra in KeyChain to allow an app to set an
authentication policy.
- Add API methods to KeyChainService to set, get
and retrieve the credential management app.
Bug: 165641221
Test: atest CredentialManagementAppTest
atest AppUriAuthenticationPolicyTest
adb shell am start -n com.android.keychain.tests/.KeyChainTestActivity
Change-Id: I1e57ed9c18a1ada463c55dbf17ce30e31aa7bad2
Update the KeyChain.createInstallIntent method documentation to reflect
the change where CA certificates can no longer be installed using
this intent.
Bug: 156941631
Test: m docs
Change-Id: I3cf2c677c4c772698c8df5f25224dd67d12b5606
This stops KeyChain from throwing AssertionError when binding to
service fails due to user being locked, which would have crashed
the entire system server.
Bug: 149912024
Test: atest KeyChainTests
Change-Id: Ie110a4210e157cc9b111d845478bdf21e948ba4f
BlockingQueue does not accept null values, change to CountDownLatch for
synchronization.
Bug: 144477553
Test: Enable multiple managed profiles, and run
`atest UserLifecycleTests#managedProfileStopped`
Change-Id: I1a003568896ce7983a5ac14a710944d914c86bac
Binding to keychain can fail, for example when the target user
is being removed. Handle this case gracefully and do not block
the system server.
Bug: 139554671
Test: none
Change-Id: Ib68c873e367428b82f3cb2a81cafe1a59776336c
Add KEY_ALIAS_SELECTION_DENIED contant to flag that no private key alias has
been chosen in onChoosePrivateKeyAlias, but no KeyChainActivity selection dialog
should be presented to the user.
Bug: 136649900
Test: run cts --test MixedManagedProfileOwnerTest#testDelegationCertSelection
Change-Id: I9aeea7be0c2a6172ca054f91d49183c843ecfa6e
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
Improve the documentation on the case of key override: When a new key is
generated/installed using an alias that already exists.
In particular, clarify that grants are lost and that a new call to
KeyChain.choosePrivateKeyAlias must be issued in this case.
Bug: 123563258
Test: that it builds.
Change-Id: I055e95f57b9576883736ca0cfa6a998dec08a6c2
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
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
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
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 b7c5eddc53)
As KeyChain reports detailed error codes about failure to generate keys
or attestation records for them, log these detailed errors and throw an
exception if the hardware does not support Device ID attestation.
Bug: 72642093
Bug: 73448533
Test: cts-tradefed run commandAndExit cts-dev -s 127.0.0.1:50487 -a x86_64 -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG
Change-Id: Ib12efcf48c158373e1fc28cc51d67e70282d029e
In order for the DevicePolicyManager to provide key generation
functionality, it has to return both the private and public keys
in form of a KeyPair.
Since the KeyChainService will perform the key generation on behalf
of the DevicePolicyManager (so that KeyChain will be the owner of
the generated keys outright), the DevicePolicyManager needs a way
to get both the private and public key representations from KeyChain.
A getKeyPair method is added that gets the private and public
key pair associated with a given alias from Keystore.
The getPrivateKey now delegates to the getKeyPair method and returns
only the private key.
Tested using existing CTS tests.
Bug: 63388672
Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement
Change-Id: I06b8511acd2049a0053ec8893de6de7429f7c92e
Queries are run (on a AsyncTask) when user is switched and when
ACTION_TRUST_STORE_CHANGED is broadcasted. Otherwise, the result is cached
in the SecurityController.
Bug: 37535489
Test: runtest --path frameworks/base/packages/SystemUI/tests/src/com/android/systemui/statusbar/policy/SecurityControllerTest.java
Change-Id: I3b9cc3d85c9f49d0a892613b63d1fba184ab647e
Add missing API annotations for permissions and SdkConstants, and
invoke doclava with new "-android" flag.
Test: make -j32 offline-sdk-docs
Bug: 37526420
Change-Id: I970bb2655eb568fd25004636f134c794663a6c33
Added a test to validate that it still works the way it should before
and after the change.
Bug: 33258404
Bug: 35196414
Fix: 35129745
Test: runtest -x services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerTest.java
Test: also manual, instructions:
Test: (1) Disable software.device_admin from tablet_core_hardware, rebuild.
Test: (2) Install CA cert. Notification should appear.
Test: (3) Reboot. Notification should still be there.
Change-Id: Id992725c1844a2fffbde4d8acaba531e99f853ad
In N, passing a null context to getPrivateKey provoked a
NullPointerException, which is validated by a CTS test. In commit
28d68b1 this behavior was changed (inadvertently, I believe) causing
getPrivateKey to wrap the NPE in a KeyChainException. This CL restores
the previous behavior, fixing the test and avoiding breaking any apps
that were catching the NPE.
Test: Fixing broken test
Change-Id: Icb0c75b03efc478b7310998cf3e7108a2c419107
To protect system stability, any Binder calls leaving the
system_server must carefully be performed using FLAG_ONEWAY (or
the 'oneway' verb in AIDL) which prevents the call from blocking
indefinitely on the remote process.
In this CL, the system_server uses the new Binder.setWarnOnBlocking()
method to enable detection by default for all remote Binder
interfaces. It can also use Binder.allowBlocking() to allow
blocking calls on certain remote interfaces that have been
determined to be safe.
This CL adds the 'oneway' verb to several interfaces and methods
where it should have been added, and marks a handful of system
ContentProviders as being safe to call into. Also, we assume that
any services obtained from ServiceManager are part of the core
OS, and are okay to make blocking calls to.
Test: builds, boots, runs with minimal logs triggered
Bug: 32715088
Change-Id: Ide476e120cb40436a94b7faf7615c943d691f4c0
It's better to use an Application Context rather than hoping the
activity won't be destroyed in another thread (because it will).
Change-Id: I9bf842d0d7dbedcc509a4a314d23a9a6cfca4d48
Fix: 29873669
This leaves the binder connection open for far too long, which keeps
the keychain app alive longer than necessary.
Bug: 29873669
Change-Id: I037c2b91400202ba6a474819867df16b6342ec0d
ACTION_STORAGE_CHANGED is too noisy and fires on too many events. It has
been split into ACTION_KEYCHAIN_CHANGED for
addition/modification/removal of user certificates and keys,
ACTION_TRUST_STORE_CHANGED for changes the the user added and system CA
stores on the device and ACTION_KEY_ACCESS_CHANGED for changes to key
grants.
ACTION_STORAGE_CHANGED will only be sent to applications targeting N
and below. Applications targeting future releases should use the new
broadcasts.
Bug:28450538
Change-Id: I34ff838e9858db65f7308ca2b0f7d652c48fae17
When installing a keypair the caller will have the option to specify a
certificate chain which will later be returned to whoever requests access
to the keypair via KeyChain.
Bug: 18239590
Change-Id: Id21ef026e31537db38d891cb9b712dd4fe7159c7
If keychain is removed from a device, there will be no sensible
resolution and client apps will bind to whatever is available.
Doesn't affect system apps which are forcibly prevented from wildcard
binding.
Bug: 27475655
Change-Id: Ide1aab3778e12f0b9a96662deb297a76d2f4997f
According to documentation:
Returns the {@code PrivateKey} for the requested alias, or null if
there is no result.
@throws KeyChainException if the alias was valid but there was some
problem accessing it.
@throws IllegalStateException if called from the main thread.
In this case the alias doesn't exist or isn't visible to the caller so
they should get null back instead of KeyChainException.
Change-Id: Ied5603ac6aefbcef79050f24c2aa7ee8f386be0b
The body of {@code} must not be HTML escaped. This is one of
several changes that fix the source in conjunction with a
doclava fix.
Bug: 25757239
Change-Id: Ib38a0fa2dd2a3d68e467f78a812071e763d7e881
This is meant for exposing the pre-existing cross-UID access to keys
backed by the keystore service via higher-level JCA API. For example,
this lets system_server use Wi-Fi or VPN UID keys via JCA API.
To obtain a JCA AndroidKeyStore KeyStore for another UID, use the
hidden system API AndroidKeyStoreProvider.getKeyStoreForUid(uid).
To generate a key owned by another UID, invoke setUid(uid) on
KeyGenParameterSpec.Builder.
This CL does not change the security policy, such as which UID can
access/modify which UIDs' keys. The policy is that only certain system
UIDs are permitted to access keys of certain other system UIDs.
Bug: 23978113
Change-Id: Ie381530f41dc41c50d52f675fb9e68bc87c006de
Several methods need to be called off the main UI thread. This is
the first documentation of that requirement.
Bug: 19440165
Change-Id: I0303011c0ded6ec1efa92119c1e02a8a39b14a59
