| Age | Commit message (Collapse) | Author |
|---|
|
Test: atest KeystoreTests
Change-Id: If663677b01738025dca01bf209b634c1d04c6be4
|
|
Mirror KeyProtection.setCriticalToDeviceEncryption so
the flag can also be set on keys generated by keystore.
Bug: 72178550
Test: atest android.security.keystore.KeyGenParameterSpecTest
Test: atest android.security.ParcelableKeyGenParameterSpecTest
Change-Id: I7f102c82e60f211028c694d499ffd2838b89bb2b
|
|
See go/jetpack-test-android-migration
Exempt-From-Owner-Approval: automated package name refactoring
Test: m m -j BroadcastRadioTests KeystoreTests mediaframeworktest ActivityManagerPerfTests AppLaunch AppLaunchWear BackgroundDexOptServiceIntegrationTests AppCompatibilityTest DynamicCodeLoggerIntegrationTests FlickerLibTest InternalTests PackageWatchdogTest RcsTests RollbackTestAppAv1 RollbackTestAppAv2 RollbackTestAppACrashingV2 RollbackTestAppBv1 RollbackTestAppBv2 RollbackTestAppASplitV1 RollbackTestAppASplitV2 RollbackTest ServiceCrashTest UsageStatsPerfTests UsbTests WindowAnimationJank
Change-Id: I32fe3297656eec6060da6c7e24582bcd5315fb16
|
|
Due to an oversight, some of the key generation parameters that are set
in KeyGenParameterSpec were not preserved when parceling the object
(they should have been added to ParcelableKeyGenParameterSpec but were
not).
This means these parameters will be ignored when generating keys using
the DevicePolicyManager.generateKeyPair method, leading to an
inconsistent key generation behaviour between the DevicePolicyManager
and KeyStore.
In particular, this would prevent callers from using StrongBox when
generating keys for use in the KeyChain.
Fix the issue by simply persisting these parameters in
ParcelableKeyGenParameterSpec and making sure that the Builder copies
them too from the source KeyGenParameterSpec.
Left to do is put in place an automated measure to find out
discrepancies between the two classes.
Bug: 110915980
Bug: 110882855
Bug: 109953656
Test: atest KeystoreTests
Change-Id: Ic64bd2921b6dfc97ea34ecba55f532312963ffcb
|
|
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
|
