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
This reverts commit 87efe74e092236c372d3b6909009641123aa416a.
This should be fine now with all the dependency CLs +2-ed
Change-Id: I96ad14ad5ff81e6b5391035cb6c5a62339c6cc40
Trusted credentials for both the primary user and its managed profiles are shown
on the Trusted Credentials fragment. All functionalities (e.g. disabling/enabling
of certificates) remain available.
Bug: 16029580
Change-Id: Ia92ae02d8c572bf4a3be172f6c255726cefc0fa1
Exposes these methods:
- hasCaCertInstalled
- hasAnyCaCertsInstalled
- installCaCert
- uninstallCaCert
Allows device and profile owners to perform some certificate management
including querying for and enabling/disabling specific CA certificates.
Change-Id: I4aa8a1a8601b234e30acde99dfa382e04cb62495
Before there was only one key type supported, so we didn't need to query
a key type. Now there is DSA, EC, and RSA, so there needs to be another
argument.
Bug: 10600582
Change-Id: I9fe9e46b9ec9cfb2f1246179b2c396216b2c1fdb
Guard install/uninstall by enforcing that the caller have the new system-only permission MANAGE_CA_CERTIFICATES.
Also include API methods for asking whether there are any User CA certs
installed, or if one by a particular name is installed in the keystore.
CA certs will be installed via KeyChain into the TrustedCertificateStore.
Bug: 8232670
Change-Id: I17b47a452e72eb4fe556dc6db823a46c6e854be8
The API documentation says it will return null if the key isn't found.
We get null back from the keystore daemon when it can't retrieve the
data, so just return null back to the API caller.
Change-Id: I42248bd50cbc5f76864bd762aae3faab1c50529d
