This is useful when the caught exceptions are not informative and they
act as a red herring in the adb logs.
Bug:109791294
Test: call this method in the VpnSettings and manually navigate to
adding a new VPN by searching for VPN in settings and then pressing '+'.
Change-Id: I4bc86e3ea5b11027090fd3a27dc7455557cf66ab
Merged-In: I4bc86e3ea5b11027090fd3a27dc7455557cf66ab
This is to keep it in sync with response codes in keystore.h.
This commit also adds the KeyPermanentlyInvalidatedException to all the
methods that could receive this error code out of KeyStore.
Bug: 118883532
Test: atest cts/hostsidetests/appsecurity/src/android/appsecurity/cts/AuthBoundKeyTest.java
Change-Id: I878a628824e2eeb639ec5678b1a5d3d10428a918
Merged-In: I878a628824e2eeb639ec5678b1a5d3d10428a918
Members modified herein are suspected to be false positives: i.e. things
that were added to the greylist in P, but subsequent data analysis
suggests that they are not, in fact, used after all.
Add a maxTargetSdk=P to these APIs. This is lower-risk that simply
removing these things from the greylist, as none of out data sources are
perfect nor complete.
For APIs that are not supported yet by annotations, move them to
hiddenapi-greylist-max-p.txt instead which has the same effect.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Change-Id: Ia937d8c41512e7f1b6e7f67b9104c1878b5cc3a0
Merged-In: I020a9c09672ebcae64c5357abc4993e07e744687
Why?: 1) Returning an array list is unsafe because it must be allocated in Java and C++ must not change the size. 2) List<Integer> is not supported by AIDL, but List<String> is. I decided it was simpler to pass back integers encoded as strings than to create yet another parcelable.
Bug: b/119616956
Test: ./list_auth_bound_keys_test.sh
Test: Temporarily modified settings app to call listUidsOfAuthBoundKeys
Change-Id: I3bf7578c96e800c8d35fba897f52220136dcd657
Since the keystore alias prefix USERSKEY was deprecated
Credentials.deleteUserKeyTypeForAlias tried to delete key the
remaining prefix first and if that failed tried to delete the
legacy prefix.
However, KeyStore.delete returns true if the key was deleted or
did not exist. So the first call to delete would return true
whether the key existed or not and the legacy alias would never be
deleted.
This patch introduces a new flavor of KeyStore.delete, that returns an
error code instead of a boolean. The caller can now distinguish
the nature of the failure. Credentials.deleteUserKeyTypeForAlias now
checks this return code and attempts to delete the legacy variant if
KEY_NOT_FOUND was returned.
Bug: 117818447
Change-Id: Ifae1f3dbb07d85d94f430ead2cdd3e39d22436a4
The legacy support importKey method uses the wrong method to add date
fields to the import keymaster arguments.
Bug: 119549023
Change-Id: Iff841086f6616303b365ad28aae429ccae1f3406
listUidsForAuthBoundKeys was added to IKeyStoreService.
This CL exposes this method in KeyStore for system apps.
This method will be hidden for non system apps.
Bug: b/112321280
Test: listUidsForAuthBoundKeys in IKeyStoreService has its own tests
Test: This method cannot be tested directly from CTS
Change-Id: Iac9e863079a1367ddb3a599bc3825baea96a1c31
This patch makes the framework use the asynchronous keystore api model.
Bug: 111443219
Test: Ran full keystore cts test suite
Change-Id: I8d1fdc70cb9eb501d3f22a97d1221904c2ef8f9a
In preparation to the async keystore interface we change the semantics
form unconditionally overwriting existing keys to reporting that the key
exists. For compatibility we reimplement the same semantic in the
calling code.
Bug: 111443219
Test: KeyStore CTS test
Change-Id: I1fa5428fa7ada97d5068778cd4590593c992554d
In preparation for making the keystore service asynchronous we remove
redundant legacy functionality from the protocol.
This patch removes the functions get_pubkey, sign, verify, generate,
and import_key. Which have long been superseded by exportKey
(get_pubkey), begin/update/finish (sign, verify), generateKey
(generate), and importKey (import_key).
This patch also removes isOperationAuthorized.
Test: KeyStore CTS tests
Bug: 111443219
Change-Id: Ib3bd6f40b4e948e5ad6b2ef5278b18ff46201d71
For packages:
android.security.net.config
android.security.keystore
android.security.keymaster
android.security
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: Ifed4da56531195f64fd53d84f14b4e8298843b2c
Merged-In: I7762dd647bede8abc9be2c538af3a3a99a25a73e
@UnsupportedAppUsage annotations are added automatically, but this does
not work when there are multiple definitions on the same line.
Test: m
Bug: 110868826
Change-Id: I2c26c136cdfa557e45cf1ee0b39dab9c17abde56
The call the framework uses to get the current user ID requires the
INTERACT_ACROSS_USERS permission, which not a lot of apps will have.
Find a better way to do that.
Bug: 76430246
Test: CtsKeystoreTestCases
Change-Id: I8a0637d351fff9cfbf40e02946325f90466b68c5
Add a keymaster parameter for keys that should be inaccessible when
the device screen is locked. "Locked" here is a state where the device
can be used or accessed without any further trust factor such as a
PIN, password, fingerprint, or trusted face or voice.
This parameter is added to the Java keystore interface for key
creation and import, as well as enums specified by and for the native
keystore process.
This reverts commit da82e2cb71.
Test: CTS tests in I8a5affd1eaed176756175158e3057e44934fffed
Bug: 67752510
Merged-In: Ia162f1db81d050f64995d0360f714e79033ea8a5
Change-Id: Ia162f1db81d050f64995d0360f714e79033ea8a5
(cherry picked from d7c961ee91)
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
This adds the API methods and values for keyguard-bound keys, but
contains none of the actual functionality.
Test: CTS tests in CtsKeystoreTestCases
Bug: 67752510
Merged-In: Iccd7dafd77258d903d11353e02ba3ab956050c40
Change-Id: Iccd7dafd77258d903d11353e02ba3ab956050c40
(cherry picked from commit fd75c7232a)
Add a keymaster parameter for keys that should be inaccessible when
the device screen is locked. "Locked" here is a state where the device
can be used or accessed without any further trust factor such as a
PIN, password, fingerprint, or trusted face or voice.
This parameter is added to the Java keystore interface for key
creation and import, as well as enums specified by and for the native
keystore process.
Test: CTS tests in I8a5affd1eaed176756175158e3057e44934fffed
Bug: 67752510
Change-Id: I314b848f6971d1849a7a6347d52e41d9604639ae
Add a keymaster parameter for keys that should be inaccessible when
the device screen is locked. "Locked" here is a state where the device
can be used or accessed without any further trust factor such as a
PIN, password, fingerprint, or trusted face or voice.
This parameter is added to the Java keystore interface for key
creation and import, as well as enums specified by and for the native
keystore process.
Test: go/asym-write-test-plan
Bug: 67752510
Change-Id: I8b88ff8fceeafe14e7613776c9cf5427752d9172
•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
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
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 d07d338427)
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
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
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
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
Was: result = True iff nDeleted != 0
Now: result = True iff nDeleted == nExisted
The most common reason you'd want to delete all credentials under an
alias is to be sure they no longer exist. The new contract gives a
way to do this without multiple IPCs to the same service.
Bug: 27335182
Change-Id: I8762b9b4fcc48037387dd805dbd0dbbe141d5b24
This is meant for exposing the pre-existing cross-UID access to keys
backed by the keystore service via higher-level JCA API. For example,
this lets system_server use Wi-Fi or VPN UID keys via JCA API.
To obtain a JCA AndroidKeyStore KeyStore for another UID, use the
hidden system API AndroidKeyStoreProvider.getKeyStoreForUid(uid).
To generate a key owned by another UID, invoke setUid(uid) on
KeyGenParameterSpec.Builder.
This CL does not change the security policy, such as which UID can
access/modify which UIDs' keys. The policy is that only certain system
UIDs are permitted to access keys of certain other system UIDs.
Bug: 23978113
Change-Id: Ie381530f41dc41c50d52f675fb9e68bc87c006de
This expands get, getmtime, exportKey, getKeyCharacteristcs and begin to
accept a uid to run as. This is only for system to use keys owned by
Wifi and VPN, and not something that can be used to do operations as
another arbitrary application.
Bug: 23978113
Change-Id: I06aa089859edc934a5415e3b184b917d6d171ae2
This CL ensures that Android Keystore framework code complies with
signedness of keymaster tags. In particular:
* INT tags are unsigned 32-bit numbers, and
* LONG and DATE tags are unsigned 64-bit numbers.
The ensure compliance, KeymasterArguments and KeyCharacteristics
classes through which Android Keystore interacts with Keymaster tags
have been modified as follows:
* ENUM and INT tags which used to be conflated are now added/queried
via separate methods, because ENUM can remain represented as an int
data type whereas INT is now represented as a long data type with
permitted range being [0; 2^32).
* Methods for adding/quering LONG tags have been switched from the long
data type to the BigInteger data type and now ensure that the value
is in the permitted [0; 2^63).
* Methods for adding/querying DATE tags now ensure the Date value is
in the permitted range [0; 2^63) ms since Unix epoch.
* Methods for adding tags throw an IllegalArgumentException if the tag
type is unsuitable for the method. This is to ensure that tags with
invalid values cannot be added through similar methods (e.g., INT tag
added via an ENUM tag addition method invoked with a negative value).
Bug: 22008538
Change-Id: I6eefd5cbb561cc52d27de952691af4d9d5e1af1e
This removes the requirement to hold the USE_FINGERPRINT permission
to successfully invoke FingerprintManager.getAuthenticatorId().
This is needed because Android Keystore classes which run inside app
processes occasionally need to access this authenticator ID. The
access however is not necessarily triggered by the developer using
APIs to do with fingerprints. Thus, if an app does not hold the
USE_FINGERPRINT permission and uses Android Keystore API, it may
unexpectedly encounter a SecurityException.
It's OK to provide access to authenticator ID without requiring
USE_FINGERPRINT permission because there are other ways to access
this ID without holding that permission, such as though hidden
KeyStore API.
Once Android Keystore code is restructured to no longer require
access to authenticator ID, this CL can be reverted.
Bug: 21030147
Change-Id: I9af29830abce34c46e29e5c1682cc3ab88c95c00
This switches Android Keystore asymmetric keys from being backed by
Conscrypt (via keystore-engine which is an OpenSSL/BoringSSL ENGINE
which talks to keystore via the old KeyStore API) to being backed by
the AndroidKeyStore Provider which talks to keystore via the new
KeyStore API. In effect, this switches asymmetric crypto offered by
Android Keystore from old Keystore API to new KeyStore API, enabling
all the new features such as enforcement of authorizations on key use.
Some algorithms offered by Android Keystore, such as RSA with OAEP
or PSS padding schemes, are not supported by other providers. This
complicates matters because Android Keystore only supports public key
operations if the corresponding private key is in the keystore. Thus,
Android Keystore can only offer these operations for its own public
keys only. This requires AndroidKeyStore to use its own subclasses of
PublicKey everywhere. The ugliest place is where it needs to return
its own subclass of X509Certificate only to be able to return its
own subclass of PublicKey from Certificate.getPublicKey().
Bug: 18088752
Bug: 19284418
Bug: 20912868
Change-Id: Id234f9ab9ff72d353ca1ff66768bd3d46da50d64
This makes Android Keystore's asymmetric key generation and import
use the new KeyStore API (similar to keymaster 1.0 API).
Because the resulting private keys will be used through
Conscrypt/keystore-engine which uses the old Keystore API, this CL
implements a temporary workaround where all generated and imported
keys are authorized for padding NONE and digest NONE, in addition to
padding schemes and digests requested by the user of the Android
Keystore API. This workaround is needed because keystore-engine uses
digest NONE and padding NONE for all its crypto operations.
Bug: 18088752
Bug: 20912868
Change-Id: Idc709039d091294265bd000160b5507f13825849
This is bad API. There was never a guarantee that when this method
returns true for a key algorithm (e.g., RSA or EC), then all keys of
that type will be imported into secure hardware. For example, the
secure hardware may reject a key if it's of unsupported size or uses
an unsupported public exponent or EC curve. In that case, the key
will be imported into keystore/KeyChain without being backed by secure
hardware.
Bug: 18088752
Change-Id: I8daa574a2e703a347d09d93401cd1ea2d0162ed9
