•Add FLAG_STRONGBOX when the generator spec requires it.
•Throw StrongBoxUnavailableException when the request
fails due to HARDWARE_UNAVAILABLE.
•Add PackageManager.FEATURE_STRONGBOX_KEYSTORE
Test: KeyStore CTS tests under development on an emulator
Bug: 63931634
Change-Id: I42d32b22981e43e504d30e5657d21ac555c71ebe
Import Wrapped Key:
Applications can import keys in a wrapped, encrypted format. Wrapped keys are
unwrapped inside of a Keymaster device.
Strongbox:
Applications can import and generate keys in secure hardware.
3DES:
Add KeyProperties and KeymasterDefs
Add AndroidKeyStore3DESCipherSpi and provider registrations
Bug: 63931634
Test: Keystore CTS tests in progress
Change-Id: I80b6db865b517fa108f14aced7402336212c441b
Remove the duplicate() method from KeyStore.
It is backed by dead code in the Keystore service, which (as far as I
can tell) is not doing the right thing.
Previous conversations with Keystore team members suggested this API
should not be used and it is marked for removal in the Keystore service.
Bug: 72037261
Test: That it compiles.
Change-Id: I7f8af95473c876340cbd5c73dd88c5d0282897b3
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
In anticipation of the availability of Keymaster implementations with
multiple security levels this patch adds the additional
keystore flags FLAG_SOFTWARE and FLAG_STROGBOX.
Also, the IKeystore method addRngEntropy got a new flags parameter
for the caller to express which implementation shall be awarded the
precious entropy.
Test: Keystore CTS tests
Bug: 63931634
Change-Id: I4a4eafbdbe1290f0c7bd2bfa2ce3e5fbb06c2dd8
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
Currently, the keystore SPI assigns different prefixes to user key
entries depending on the algorithm. Symmetric keys (secret keys) get
the prefix USERSKEY_ and asymmetric keys (private keys) get the
prefix USERPKEY_. This distinction is superfluous, as the information
can always be retrieved from the key characteristics. Also moving
forward it is desirable to be able to import keys the nature
of which is not known a priori. In these cases the prefix cannot be
chosen meaningfully.
This patch deprecates one of the prefixes (i.e. USERSKEY_) and uses
the other for both types of keys. Legacy keys with the old prefix
can still be used, but all new keys will have the prefix USERPKEY_.
Bug: 63931634
Test: CTS test and Manual upgrade test with KeyStoreTool app
Also performed upgrade test with device PIN set
Change-Id: I5b4bb0b0d2b82c276659d55b862150326bb68d5d
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
Fix the way KeyGenParameterSpec is parceled, by correctly handling
default and null values for some of the fields.
A recent CL added the ability to parcel/unparcel KeyGenParameterSpec (by
a separate class).
Due to refactoring late in the CL review cycle, the parceling code did
not take into account a few edge cases.
Unit tests:
m -j KeystoreTests && adb install -r out/target/product/marlin/data/app/KeystoreTests/KeystoreTests.apk
adb shell am instrument 'android.security.tests/android.support.test.runner.AndroidJUnitRunner'
CTS tests:
cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG
Bug: 69337278
Test: Keystore unit tets (see instructions above) and cts Key Management test.
Change-Id: Ie08f42b07fb55b6fa1d8fb73c89d69687c97e214
Behaves pretty much the same as @IntDef, but now supports "suffix"
in addition to "prefix" when matching constants.
Test: manual docs output looks sane
Bug: 70406696
Change-Id: I35064b0f9f36f1f13ccdb40302d818a004014f15
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
The guide within the KeyGenParameterSpec class now uses the correct
method (init() instead of initialize()) to initialize the key
generator in the examples that show how to create AES and HMAC keys.
Test: make ds-docs -j8
Bug: 69093664
Change-Id: I6a9cbe6decd895c2505538f6ad4be91cd9133714
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
Java/aidl side changes necessary to generate IKeystoreService.cpp
Generated C++ service currently doesn't support null parameters, so lots
of parameters were updated to pass default value instead of null.
Test: cts-tradefed run cts -m CtsKeystoreTestCases
Bug: 68389643
Change-Id: Ifaf2ab48b2bcd7b081e4b336aa279fa8ba4fbbbf
When an auth-bound key is used after the screen lock has been removed by
the user, KeyStore.begin retruns UNINITIALIZED.
This patch adds handling for this error code, indicating that the key
that was to be used was permanently invalidated.
Bug: 65200397
Test: CtsVerifier ScreenLockBoundKeysTest:
1. Run test
2. with CtsVerifier in the background remove the screen lock
through the settings dialog
3. Select VtsVerifier in 'recents'
4. Run test again
Change-Id: If68ba0eb2f9c04655fe8c9eea28c4491eae8e92f
(cherry picked from commit d07d3384279c0c07c5c6747ea8d0c5684264c9d0)
When an auth-bound key is used after the screen lock has been removed by
the user, KeyStore.begin retruns UNINITIALIZED.
This patch adds handling for this error code, indicating that the key
that was to be used was permanently invalidated.
Bug: 65200397
Test: CtsVerifier ScreenLockBoundKeysTest:
1. Run test
2. with CtsVerifier in the background remove the screen lock
through the settings dialog
3. Select VtsVerifier in 'recents'
4. Run test again
Change-Id: If68ba0eb2f9c04655fe8c9eea28c4491eae8e92f
Keystore stores key blobs in with filenames that include the symbolic
name and the uid of the owner. This behaviour should have been
completely opaque to the user keystore. However, the granting mechanism,
by which an app can allow another app to use one of its keys, leaked the
internal structure in that the grantee had to specify the key name with
the granter's uid prefix in order to use the granted key. This in turn
collided with prefix handling in other parts of the framework.
This patch refurbishes the granting mechanism such that keystore can
choose a name for the grant. It uses the original symbolic key name as
prefix and appends _KEYSTOREGRANT_<grant_no> where the grant_no is
chosen as first free slot starting from 0. Each uid has its own grant_no
space.
This changes the grant call such that it now returns a string, which is
the alias name of the newly created grant. The string is empty if the
grant operation failed.
As before apps can still mask granted keys by importing a key with the
exact same name including the added suffix. But everybody deserves the
right to shoot themselves in the foot if they really want to.
Bug: 37264540
Bug: 62237038
Test: run cts-dev --module CtsDevicePolicyManagerTestCases --test
com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement
because it grants a key
Merged-In: I047512ba345c25e6e691e78f7a37fc3f97b95d32
Change-Id: I047512ba345c25e6e691e78f7a37fc3f97b95d32
Keystore stores key blobs in with filenames that include the symbolic
name and the uid of the owner. This behaviour should have been
completely opaque to the user keystore. However, the granting mechanism,
by which an app can allow another app to use one of its keys, leaked the
internal structure in that the grantee had to specify the key name with
the granter's uid prefix in order to use the granted key. This in turn
collided with prefix handling in other parts of the framework.
This patch refurbishes the granting mechanism such that keystore can
choose a name for the grant. It uses the original symbolic key name as
prefix and appends _KEYSTOREGRANT_<grant_no> where the grant_no is
chosen as first free slot starting from 0. Each uid has its own grant_no
space.
This changes the grant call such that it now returns a string, which is
the alias name of the newly created grant. The string is empty if the
grant operation failed.
As before apps can still mask granted keys by importing a key with the
exact same name including the added suffix. But everybody deserves the
right to shoot themselves in the foot if they really want to.
Bug: 37264540
Bug: 62237038
Test: run cts-dev --module CtsDevicePolicyManagerTestCases --test
com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement
because it grants a key
Merged-In: I047512ba345c25e6e691e78f7a37fc3f97b95d32
Change-Id: I047512ba345c25e6e691e78f7a37fc3f97b95d32
Cherry-pick note:
testCACertLoader() was flaky, so this cherry-pick contains
two attempted fixes and a CL that disables the test. The original commit
messages of the squashed CLs are below.
Merged-In: I3b9cc3d85c9f49d0a892613b63d1fba184ab647e
Implement CACert queries in SecurityController
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
Increase timeout for flaky testCACertLoader()
Bug: 37535489
Bug: 38045871
Test: runtest --path frameworks/base/packages/SystemUI/tests/src/com/android/systemui/statusbar/policy/SecurityControllerTest.java
Change-Id: I5778082973af7c6d4d719b83e334fec552b0a89e
Fix flaky SecurityControllerTest.testCaCertLoader
Fixes: 38108698
Test: runtest -c .statusbar.policy.SecurityControllerTest systemui
Change-Id: I6029a09984b72599622f0df57187a20aba4dab30
Disable flaky test
Test: treehugger
Bug: 38118260
Change-Id: I05c6504acee6a787e1cc5071bed0118388963212
(cherry picked from commit e375fc441cc889890d1cff5bc771039bb65f08ef)
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
Device ID attestation consists of three steps:
* Generate a temporary key
* Attest the key and desired device IDs
* Delete the temporary key
Rather than being spread over three keymaster APIs, these operations
should happen automatically in a single keymaster method.
Bug: 34734938
Test: GTS com.google.android.gts.security.DeviceIdAttestationHostTest
Change-Id: Ifabb5163b9e4d12cb309a6b0ca8e5f2f92d212f4
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
This flag is used by system server to mark keys used during the
synthetic password auth flow. keys marked with this flag will not
be super encrypted because super encryption requires knowledge of
the synthetic password, causing a chicken-and-egg problem.
Bug: 35849499
Bug: 34600579
Test: cts-tradefed run cts-dev -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.MixedProfileOwnerTest#testResetPasswordWithToken
Change-Id: I474822f2e026f24ce6f6de1aa58b5012922f7b13
Add support for AnyThread, CallSuper, and UiThread.
Another related CL started documenting @RequiresPermission, so remove
duplicated information in existing APIs.
Suppress auto-doc on a handful of classes that are already
well-documented.
Test: make -j32 offline-sdk-docs
Bug: 37526420
Change-Id: I791437dccec0f11d5349a23b982ba098cb551af8
Discussions have shown that in addition to brand, device and product,
we should also allow devices to attest their manufacturer and model.
Bug: 36433192
Test: GTS com.google.android.gts.security.DeviceIdAttestationHostTest
Change-Id: Idd48929d6a0c9fe6656c6d2656e2c3f6f370a21e
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
This reverts commit eb30e64f3fac192404a6ae3c162a0770201a7dc2.
Reason for revert: Remove partial support for wrapped key import
Test: CTS tested
Change-Id: I8008494860534257fa983e1a5169d0ed034621f7
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
So it can be sent from devicepolicymanager (system_server) to keychain
(a system_app) without waiting on the response and having to do
everything in a background thread.
Side-effect: the regular keychain => app callback is slightly more
efficient now too. in case anyone particularly needs blazing fast
private key user selections.
Fix: 35675253
Test: cts-tradefed run cts --abi=arm64-v8a --skip-device-info --module CtsDevicePolicyManagerTestCases --test 'com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement' </dev/null 2>&1
Change-Id: I6e9d96ca3c42e6489d879d8cfb0507eb94838bf1
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
Allows the caller to specify which SID the given key
should be bound to, overriding the default rule of
binding to the current root/fingerprint SID.
This is a prerequsite for introducing synthetic password
based authentication flow.
Test: cts-tradefed run cts -m CtsKeystoreTestCases
Bug: 33126414
Change-Id: Ide03c0f4fd33ecca7a169ea763c3d4d0b173d1dd
