For now just returns raw key material. In the future we will need to
change this to use the KeyStore move api. (Once that has been
implemented.)
Test: adb shell am instrument -w -e package com.android.server.locksettings.recoverablekeystore com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Change-Id: I8aee4da81f0f853503f570dae8d74e1d29f124cc
This is a temporary solution, while the KeyStore team works on adding a
move API to KeyStore. (At which point this will be updated to instead
return 'move tokens', allowing the user to move the key from the system's
keystore to their own, without ever seeing the raw material.)
Test: adb shell am instrument -w -e package com.android.server.locksettings.recoverablekeystore com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Change-Id: I2241a6da15d50c26a7b384d4e5b6f78366fb9300
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
1) Methods to get key status.
2) Register pending intent to get notification about new recovery
snapshots.
Test: none
Bug: 66499222
Change-Id: I4d5f8c1a6581b5e08f4589e19961d93c499689e1
1) Updates to ILockSettings.aidl
Since we can't pass arbitrary exception using IPC, Serrvice
converts them to ServiceSpecificException with an error code.
2) Added RecoverableKeyStoreManager class which is used as interface
between RecoverableKeyStoreLoader implementation and
LockSettingsService.
Test: none
Bug: 66499222
Change-Id: I03b695bc0ced1a91ea7ca5de179e121053dfe416
Includes parcelables for
1) KeyDerivation
2) User Secret together with its type.
3) Application key entry
4) KeystoreRecoveryData block with all data necessary to recover
keys later.
Test: none
Bug: 65979689
Change-Id: If59842a92ebbc0e77f95d6a2e5503943e2835062
As part of the RecoverableKeyStoreLoader, we need to be able to generate new
256-bit AES keys, sync them with AndroidKeyStore, and persist them, wrapped
to disk. This allows us to recover them later, using a Platform key, and
sync them with remote storage.
Test: manual for now (how do we do automated tests on Framework?)
Change-Id: I32e0beabaecc9bea9f95ca2beea851e9be833358
It turns the version code into almost a 64-bit integer, with the
new major part being the upper 32 bits.
The only tricky part about this is the backup manager, since it
stored 32-bit version codes in its backup data sets. This is dealt
with by, when the major version code is not 0, writing MIN_INT as
the version code and following that by the full long version code,
which we can detect when reading. Note that this makes backup sets
containing apps with major version codes incompatible with older
versions of the platform.
Bug: 64459786
Test: Added in Change-Id: Iab8a682b62103babd6c16a56b8dc1e97d7078658
Change-Id: Ibfffe235bbfcf358b3741abd3f7197fdb063d3f3
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
No change to logic, docs change only.
WebView added support for android:usesCleartextTraffic for apps
targeting O and above (API level 26). This CL clarifies WebView's
support in the Android documentation.
This also fixes a preexisting presubmit error in
NetworkSecurityPolicy.java (unused import).
Bug: 67714197
Test: N/A
Change-Id: If6bfd36bc65926a1b032813598c85146ccfde969
For applications targeting P and above the network security
config's cleartextTrafficPermitted will default to false instead of
the previous true.
Bug: 63931636
Test: network security config cts tests
Change-Id: Ia697358ad84e2092443c3eff518003c6a11e4630
Privileged applications provide core system functionality and as such a
MiTM in one can put the entire system at risk. These applications should
not be trusting user added CAs by default.
Bug: 65406503
Test: runtest --path framework/base/tests/NetworkSecurityConfigTest
Change-Id: I033258fe1c66ad245d172899df52e9cd02e9ca75
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
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
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
This reverts commit eb30e64f3f.
Reason for revert: Remove partial support for wrapped key import
Test: CTS tested
Change-Id: I8008494860534257fa983e1a5169d0ed034621f7
The new attribute allows both ephemeral and non-ephemeral apps to
opt into a new, tighter security model.
Test: Manual; built app w/ targetSandboxVersion and verified the security domain
Change-Id: I8fcaf84e25f0519b438ba51302f79790e680e025
This adds a new public API for attesting the device's hardware ids
(e.g. serial number and IMEI).
Bug: 34597337
Test: CTS CtsKeystoreTestCases and GTS DeviceIdAttestationHostTest
Change-Id: I2e9c1b4f8eb24afa4a09c71c137ce33a6b87eb27
This is necessary for allowing the KeyStore to lock keys that remain
authorized as long as the device is on-body.
Bug 28911985
Change-Id: If50bc84d5a1cb23f9b01b1950c3676d1519cc4f5
Skip certificates in a DirectoryCertificateSource that cannot be read to
due IOExceptions or CertificateExceptions, this prevents a NPE but
connections will still fail due to the certificate being unusable and no
valid trust-anchor existing.
This also logs the error since this really shouldn't happen.
Bug: 29997695
Change-Id: I9f7327efc302a259fb951f1f61f7fc4d647821fa
Add getKeyAttestationApplicationId and the Parcelables
KeyAttestationPackageInfo and KeyAttestationApplicationId,
needed by keystore.
Bug: 22914603
Change-Id: I89a88cd9cd80e9b132ca67fc452e9cae8b8ad241
This CL flushes the trusted cert cache of all active Network Security
Configs and their TrustManagers. Previously CA addition mostly worked
however removed CAs would remain cached in the X509TrustManager causing
the removed CA to still be trusted.
Change-Id: I0f5fd39932f8f8ed3ec5dfd088a82e982b366c43
getApplicationConfigForPackage will be used by system components that
need to make connections for apps, e.g. DownloadManager, so that their
secure connections have the same configuration as those from the app
itself.
Bug: 29505888
Change-Id: Idf1cac6307431911eda34529d3fd50f9ca0da314
The static instances of SystemCertificateSource and
UserCertificateSource depend on the current user, avoid triggering their
static initializer when preloaded.
Bug: 29258379
Change-Id: I5088366ae67145b8bc928d6c04118529c82a7fc3
ApplicationInfo is mutable and unfortunately some apps do actually
modify the flags. Due to the lazy loading nature of the network security
config this may lead to issues. Instead cache the needed flags and
resources at application startup.
Bug: 29063413
(cherry picked from commit 276ee969be)
Change-Id: If638a716fd903b4e9dbabcbecb38bd4e26fef08c
Originally we went with the meta-data approach to make unbundling
easier, however with the amount of platform changes that the config
ended up relying on it would be better to focus on exposing it through
the platform.
Bug:28763009
Change-Id: Iaf80001b1980220cd2e1e05faf2dc86af41700e1
