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
Enable requesting inclusion of device identifiers in the attestation
record issued for keys generated by generateKeyPair.
This is done by passing an array of flags with values indicating which
identifiers should be included.
Since the attestation record will include sensitive identifiers, it can
only be requested by the DPC in Device Owner mode or by the Delegated
Cert Installer in Device Owner mode.
Design note:
DevicePolicyManager defines its own set of constants for the different
identifier types (ID_TYPE_*) and prior to calling
DevicePolicyManagerService it translates them to the values defined by
AttestationUtils (which is not a public class).
The reason is to allow re-use of code in AttestationUtils for preparing
the attestation arguments.
In theory, these constants could be moved from AttestationUtils to
DevicePolicyManager, however that would create a dependency on DPM from
Keystore, which logically does not make sense as Keystore is independent
of the DPM (and in a lower level of the system, conceptually).
Bug: 63388672
Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement; runtest frameworks-services -c com.android.server.devicepolicy.DevicePolicyManagerTest#testTranslationOfIdAttestationFlag
Change-Id: Ifb42e8e813fa812a08203b4a81d15b1f91152354
Add a new method in the DevicePolicyManager to associate certificates (and
set the user-visibility) with a given key alias.
Conceptually, the new method, setKeyPairCertificate is very similar to
installKeyPair, except it does not install a key, only certificates.
(The new setKeyPairCertificate, together with generateKeyPair is
functionally equivalent to installKeyPair, except the keys are generated
in hardware rather than supplied externally).
Bug: 63388672
Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG
Change-Id: Idbfe151f6e5311766decbc1a010bff78dc60249f
If the KeyGenParameterSpec passed into
DevicePolicyManager.generateKeyPair contains an attestation challenge,
request an attestation record for the newly-generated key with the
challenge provided.
This particular implementation was chosen, rather than letting the
attestation record be generated at the same time as key generation, to
avoid having the attestation chain stored in Keystore and associated
with the generated alias.
The rationale is that this is a key that is potentially accessible by
multiple applications and the attestation chain may end up being sent
as a TLS client certificate chain, for example.
As the attestation challenge should be unique per device, to avoid
the potential of sending / sharing unique device information, by
explicitly requesting an attestation record after key generation, the
attestation record is only returned to the generateKeyPair client and
not persistend in Keystore.
Bug: 63388672
Test: New CTS test to be run with: 'cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG'
Change-Id: I95a9aef179173b571b533301ac438c675e8fe702
This is the crux of the Verified Access feature implementation:
Adding the ability to generate KeyChain keys directly by the
secure hardware, rather than installing software-generated keys
into KeyChain.
Add generateKeyPair to the DevicePolicyManager, which delegates key
generation (via the DevicePolicyManagerService) to the KeyChainService.
Design highlights:
* The key generation is delegated via the DevicePolicyManagerService to
check that only authorized callers request key generation in KeyChain.
* KeyChainService performs the actual key generation so it owns the key
in Keystore outright.
* DevicePolicyManagerService then grants the calling app access to the
Keystore key, so it can actually be used.
* Loading the public/private key pair, as well as attestation
certificate chain, is done in the client code (DevicePolicyManager)
to save parceling / unparceling those objects across process
boundaries twice (for no good reason).
NOTE: The key attestation functionality (that includes Device ID) is
missing/untested. Will be added in a follow-up CL as this one is quite
big already.
HIGHLIGHT FOR REVIEWERS:
* API: New API in DevicePolicyManager.
Bug: 63388672
Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG; adb shell am instrument 'android.security.tests/android.support.test.runner.AndroidJUnitRunner' (After building the KeystoreTests target and installing the apk)
Change-Id: I73762c9123f32a94d454ba4f8b533883b55c44cc
With this API, the system can determine whether a CA cert was
installed by the user or the user's DO/PO.
Bug: 32692748
Test: unit tests (see DevicePolicyManagerTest.java for invocation)
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases
Change-Id: I3bcae5ac18ec2b110154184fc515df804fd73da6
Both inherit from package private BaseParceledListSlice.
This is still bad, but it's not as bad. The existing code that uses
this can just do Foo.bar().getList() now instead of having to marshal
to and from an oddball type at either end as well.
In the longer term ParceledListSlice<> should be eliminated, but it's
not clear how far into the future that is going to happen.
Test: runtest -x services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerTest.java
Test: runtest -x core/tests/coretests/src/android/content/pm/ParceledListSliceTest.java
Change-Id: Ie69b96b5215d6e04990f6d31345772cdfee21d78
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
The keypair is specified by alias and removed via a call to the
KeyChainService, which will have installed the pair in the first place.
Bug: 22541933
Change-Id: I37317e7c22e89816156e6e9a7abf4c5a59e8440a
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
Change the keystore to keep the private keys in keystore. When returned,
it uses the OpenSSL representation of the key to allow users to use it
in various operations through the OpenSSL ENGINE that connects to
keystore.
Change-Id: I3681f98cb2ec49ffc4a49f3821909313b4ab5735
frameworks/base
Remove getCaCertificates and findIssuer from IKeyChainService,
these are now done via libcore's TrustedCertificateStore (as part
of the default TrustManager implementation)
keystore/java/android/security/IKeyChainService.aidl
Simplify KeyChain API. Now that the CA certificates are visible
through the default TrustManager, the KeyChain is solely focused on
retrieving PrivateKeys and their associated certificates. The
calling API for KeyChain to simply a single KeyChain.get() call
that returns a KeyChainResult, removing the need for a KeyChain
instance that needs to be closed.
keystore/java/android/security/KeyChain.java
keystore/java/android/security/KeyChainResult.java
master/libcore
Remove getDefaultIndexedPKIXParameters and
getIndexedPKIXParameters which was used as part of the prototype
of looking up CAs via the KeyChain but is obsoleted by the new
default TrustManager implementation.
luni/src/main/java/org/apache/harmony/xnet/provider/jsse/SSLParametersImpl.java
luni/src/main/java/org/apache/harmony/xnet/provider/jsse/TrustManagerImpl.java
packages/apps/KeyChain
Tracking simplified IKeyChainService, removing now unneeded
implementation, updating tests.
src/com/android/keychain/KeyChainService.java
tests/src/com/android/keychain/tests/KeyChainServiceTest.java
tests/src/com/android/keychain/tests/KeyChainTestActivity.java
Change-Id: I847b28c2f467c85f24d2b693a2fecc1cb46426b4
frameworks/base
Adding IKeyChainService APIs for CertInstaller and Settings use
keystore/java/android/security/IKeyChainService.aidl
libcore
Improve exceptions to include more information
luni/src/main/java/javax/security/auth/x500/X500Principal.java
Move guts of RootKeyStoreSpi to TrustedCertificateStore, leaving only KeyStoreSpi methods.
Added support for adding user CAs in a separate directroy for system.
Added support for removeing system CAs by placing a copy in a sytem directory
luni/src/main/java/org/apache/harmony/xnet/provider/jsse/RootKeyStoreSpi.java
luni/src/main/java/org/apache/harmony/xnet/provider/jsse/TrustedCertificateStore.java
Formerly static methods on RootKeyStoreSpi are now instance methods on TrustedCertificateStore
luni/src/main/java/org/apache/harmony/xnet/provider/jsse/TrustManagerImpl.java
Added test for NativeCrypto.X509_NAME_hash_old and X509_NAME_hash
to make sure the implementing algortims doe not change since
TrustedCertificateStore depend on X509_NAME_hash_old (OpenSSL
changed the algorithm from MD5 to SHA1 when moving from 0.9.8 to
1.0.0)
luni/src/test/java/org/apache/harmony/xnet/provider/jsse/NativeCryptoTest.java
Extensive test of new TrustedCertificateStore behavior
luni/src/test/java/org/apache/harmony/xnet/provider/jsse/TrustedCertificateStoreTest.java
TestKeyStore improvements
- Refactored TestKeyStore to provide simpler createCA method (and
internal createCertificate)
- Cleaned up to remove use of BouncyCastle specific X509Principal
in the TestKeyStore API when the public X500Principal would do.
- Cleaned up TestKeyStore support methods to not throw Exception
to remove need for static blocks for catch clauses in tests.
support/src/test/java/libcore/java/security/TestKeyStore.java
luni/src/test/java/libcore/java/security/KeyStoreTest.java
luni/src/test/java/org/apache/harmony/xnet/provider/jsse/NativeCryptoTest.java
packages/apps/CertInstaller
Change CertInstaller to call IKeyChainService.installCertificate
for CA certs to pass them to the KeyChainServiceTest which will
make them available to all apps through the
TrustedCertificateStore. Change PKCS12 extraction to use AsyncTask.
src/com/android/certinstaller/CertInstaller.java
Added installCaCertsToKeyChain and hasCaCerts accessor for use by
CertInstaller. Use hasUserCertificate() internally. Cleanup coding
style.
src/com/android/certinstaller/CredentialHelper.java
packages/apps/KeyChain
Added MANAGE_ACCOUNTS so that IKeyChainService.reset
implementation can remove KeyChain accounts.
AndroidManifest.xml
Implement new IKeyChainService methods:
- Added IKeyChainService.installCaCertificate to install certs
provided by CertInstaller using the TrustedCertificateStore.
- Added IKeyChainService.reset to allow Settings to remove the
KeyChain accounts so that any app granted access to keystore
credentials are revoked when the keystore is reset.
src/com/android/keychain/KeyChainService.java
packages/apps/Settings
Changed com.android.credentials.RESET credential reset action to
also call IKeyChainService.reset to remove any installed user CAs
and remove KeyChain accounts to have AccountManager revoke
credential granted to private keys removed during the RESET.
src/com/android/settings/CredentialStorage.java
Added toast text value for failure case
res/values/strings.xml
system/core
Have init create world readable /data/misc/keychain to allow apps
to access user added CA certificates installed by the CertInstaller.
rootdir/init.rc
Change-Id: I2e4b169cbb35d32d97f5d6a00d988fa389eadcb2
