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
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
This switches Android Keystore asymmetric keys from being backed by
Conscrypt (via keystore-engine which is an OpenSSL/BoringSSL ENGINE
which talks to keystore via the old KeyStore API) to being backed by
the AndroidKeyStore Provider which talks to keystore via the new
KeyStore API. In effect, this switches asymmetric crypto offered by
Android Keystore from old Keystore API to new KeyStore API, enabling
all the new features such as enforcement of authorizations on key use.
Some algorithms offered by Android Keystore, such as RSA with OAEP
or PSS padding schemes, are not supported by other providers. This
complicates matters because Android Keystore only supports public key
operations if the corresponding private key is in the keystore. Thus,
Android Keystore can only offer these operations for its own public
keys only. This requires AndroidKeyStore to use its own subclasses of
PublicKey everywhere. The ugliest place is where it needs to return
its own subclass of X509Certificate only to be able to return its
own subclass of PublicKey from Certificate.getPublicKey().
Bug: 18088752
Bug: 19284418
Bug: 20912868
Change-Id: Id234f9ab9ff72d353ca1ff66768bd3d46da50d64
This is bad API. There was never a guarantee that when this method
returns true for a key algorithm (e.g., RSA or EC), then all keys of
that type will be imported into secure hardware. For example, the
secure hardware may reject a key if it's of unsupported size or uses
an unsupported public exponent or EC curve. In that case, the key
will be imported into keystore/KeyChain without being backed by secure
hardware.
Bug: 18088752
Change-Id: I8daa574a2e703a347d09d93401cd1ea2d0162ed9
Uri provides a stronger guarantee of well-formedness and lets apps do
nice extra things like specifying scheme etc. without twisting any
expectations.
Bug: 20820034
Change-Id: Ia6bbedb74765444920b667d643fb7e1eb6a7292b
This CL addresses the comments from API Council about Android KeyStore
KeyPairGeneratorSpec, KeyGeneratorSpec and KeyStoreParameter:
1. These abstractions should not take or hold references to Context.
2. The Builders of these abstractions should take all mandatory
parameters in their constructors rather than expose them as
setters -- only optional paratemers should be exposed via setters.
These comments cannot be addressed without deprecation in the already
launched KeyPairGeneratorSpec and KeyStoreParameter. Instead of
deprecating just the getContext methods and Builder constructors, this
CL goes for the nuclear option of deprecating KeyPairGeneratorSpec and
KeyStoreParameter as a whole and exposing all of the AndroidKeyStore
API in the new package android.security.keystore. This enables this CL
to correct all of the accrued design issues with KeyPairGeneratorSpec
(e.g., naming of certificate-related methods) and KeyStoreParameter.
This also makes the transition to API Level M more clear for existing
users of the AndroidKeyStore API. These users will only have to deal
with the new always-mandatory parameters (e.g., purposes) and
sometimes-mandatory (e.g., digests, block modes, paddings) if they
switch to the new API. Prior to this CL they would've had to deal with
this if they invoked any of the new methods of KeyPairGeneratorSpec
or KeyStoreParameter introduced in API Level M.
This CL rips out all the new API introduced into KeyPairGeneratorSpec
and KeyStoreParameter classes for Android M, thus reverting these
classes to the API launched in L MR1. This is because the new API is
now in android.security.keystore.KeyGenParameterSpec and KeyProtection
respectively.
Bug: 21039983
Change-Id: I59672b3c6ef7bc25c40aa85f1c47d9d8a05d627c
This moves constants/flags declared in inner classes of
KeyStoreKeyProperties into KeyStoreKeyProperties, as requested by API
Council.
Bug: 21039983
Change-Id: I84a3c983e13644a027bed9f605ab8044220a352c
This is to enable Android Lint and Android Studio to flag nullness
issues at compile time.
Bug: 18088752
Change-Id: I21033b8fcdd989d08c89b50685e47fbb9c74acbf
This defines the String enum values based on JCA standard names for
key algorithm, block mode, padding schemes, and digests. This should
make it safer to interact with AndroidKeyStore code that uses JCA
strings. This was requested by API Council.
Bug: 18088752
Change-Id: I241d9225a13b85479d0a84e49d0a98cbc77e5817
Support for certificate chooser (keychain) to first query a profile
owner (if one exists) for a silent credentials grant which will be
passed back to the caller as an alias.
Bug: 15065444
Change-Id: I0729b435c218b7991e6cb5faedefb7900577afcc
