Settings#CredentialStorage could be overlaid to
trick user into clearing all credentials.
Disallow non-system overlay on activity.
Test: Trigger the debug apk again, and no overlay
Bug: 176753731
Change-Id: I657de039d667f5aee0941336e9361ae04f056c33
Merged-In: I657de039d667f5aee0941336e9361ae04f056c33
This change includes the following commits from internal R branch
which are related to certificate management:
0206e76f46 CredentialStorage: Install keys using KeyChain
09ceea53d9 Added functionality to select type of certificate to be installed from the Settings app
3acf3f5433 WiFi certificates installable from Wifi sub-preference
8439fd15f7 Fix strings for certificate installation in Settings
Bug: 161347472
Test: builds & manual testing
Change-Id: Ia59dc4780254fab4f34c2f61b25f3b4e56ed7b77
We decided to punt extra certificate to post-R.
This reverts commit c8a1960cf4.
Test: Treehugger
Bug: 112038744
Change-Id: Ic53e58944faebe7aa427975ebd77ce783bdddaf2
The new certificate can be installed from Settings ("Install a
certificate > App Source certificate"). The installation flow includes
a warning with user authorization to proceed, then a prompt for reboot
(now or later).
Installed certificate can be managed in "User credentials". The name is
currently a hash of hex numbers.
Upon deletion, there will also be a promot for reboot (now or later).
Test: Only see the new setting entry if feature is enabled
Test: Install from Settings, see the expected file name in
/data/misc/keysetore/user_0. Reboot also works.
Test: Able to see the certificate in Settings after installed
Test: Able to delete the certificate, which triggers confirmation dialog
to reboot. Reboot works.
Test: add certificate, see dialog, "not now" / tapping elsewhere does
nothing
Test: atest RestrictedEncryptionPreferenceControllerTest
Bug: 112038744
Change-Id: I7a4494ea0f243730df2212076588074d8774ae23
This is part of the work to unify the manual certificate
installation flow (via "Install from storage" in the Settings
app) with the programmatic one (using
DevicePolicyManager.installKeyPair).
The change to CredentialStorage is the crux of this work, where
the key is no longer installed by calling Keystore directly.
Instead, a new AsyncTask, InstallKeyInKeyChain, was created, which
calls KeyChainService.installKeyPair with the key data and associated
certificates (as well as the UID of the designated service, to allow
installation into the WiFi Keystore).
Once that task completes, if the key was installed successfully,
then it is marked as user-selectable.
Test: Manual CtsVerifier tests: KeyChain Storage Test, CA Cert Notification Test
Test: cts-tradefed run commandAndExit cts-dev -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.MixedDeviceOwnerTest#testKeyManagement
Bug: 138375478
Change-Id: I7c4b4ea725a34307f58d27252c2958771001636f
Currently the code assumes that the user always has a pin or
password or pattern. If there's no password confirmKeyGuard() will
return false, so the acttivity will finish without doing anything.
With this change if there's no PIN/password/pattern, the credential
clearing task will be launched straightaway as the user presses "OK"
the confirmation prompt.
Bug: 127697771
Test: manual
Change-Id: Iac4af0abfc7430ed197e04f833bf203c3f66f52e
Additional clean-up work related to removal of screenlock dependency
from the credentials installation flow:
* Move the CredentialStorage class to security/ so that Enterprise team
owners could review changes to it.
* Remove the ConfigureKeyGuardDialog class as it is no longer used.
* Remove attempt to unlock KeyStore from VPN settings.
* Remove intents that will no longer be sent from the manifest.
Bug: 120901345
Test: m -j RunSettingsRoboTests
Test: Manual with CtsVerifier
Change-Id: Ia708ede3366892d74c148f3712a63858d5ab53b7
