Added a KeyAgreement algorithm for X25519(XDH) in KeyProperties.
KM_ALGORITHM_EC is used for XDH because Keymint uses KM_ALGORITHM_EC along
with Curve25519 to differentiate X25519 and other EC keys.
Algorithm name XDH is set for X25519 private key.
Consilidated methods of Keymaster specific conversions of EC_CURVE into
KeymasterUtil.
Bug: 240682299
Test: run cts -m CtsKeystoreTestCases -t android.keystore.cts.Curve25519Test#x25519KeyImportAndAgreementTest
Change-Id: I3f95738194e62be0f1d821b1eb467ed810a5a175
If EC curves of Public and Private keys are different, an
InvalidKeyException is expected.
But the current implementation does not throw exception from doPhase method
and fails in generateSecret method.
The fix is in AndroidKeyStoreECPublicKey to provide
correct ECParameterSpec while creating a PrivateKey object.
Bug: 215175472
Test: run cts -m CtsKeystoreWycheproofTestCases -t com.google.security.wycheproof.JsonEcdhTest#testSecp224r1
Test: run cts -m CtsKeystoreWycheproofTestCases -t com.google.security.wycheproof.JsonEcdhTest#testSecp256r1
Test: run cts -m CtsKeystoreWycheproofTestCases -t com.google.security.wycheproof.JsonEcdhTest#testSecp384r1
Test: run cts -m CtsKeystoreWycheproofTestCases -t com.google.security.wycheproof.JsonEcdhTest#testSecp521r1
Test: run cts -m CtsKeystoreTestCases -t android.keystore.cts.KeyAgreementTest#testDoPhase_withDifferentCurveKey_fails
Change-Id: Ie221926d8a3be3fe6679e723575c5021cafba98e
As per Keymint documentation EC key import has to provide EC_CURVE tag.
This is required for Strongbox implementation test using wycheproof test
cases.
Also added a support to get KEY_SIZE based on EC_CURVE, if it is not
included into Authorization list.
Bug: 237634216
Test: run cts -m CtsKeystoreWycheproofTestCases
Change-Id: Ie981721c38477e74da3cba6613dc0b34e453609c
Included KM_TAG_RSA_OAEP_MGF_DIGEST for RSA keys generation and import
if supported padding is defined as OAEP. All supported digest are added
as KM_TAG_RSA_OAEP_MGF_DIGEST and also default MGF1-SHA1 digest is added
because crypto operations could fail is MGF1ParameterSpec is not provided.
Note this includes additional Attestation parameter in returned
certificate and need to handle accordingly.
Bug: 203688354
Test: run cts -m CtsKeystoreTestCases -t android.keystore.cts.CipherTest#testKatBasicWithDifferentProviders
Change-Id: I2086f2520667ccac9116e04de39f6328a0d3fc5b
The keystore2 binder API supports rollback resistance when KeyMint
supports it, but until now this wasn't exposed to Java code that uses
AndroidKeyStore. Add support for rollback-resistant keys to
KeyProtection and AndroidKeyStoreSpi.setSecretKeyEntry() so that
LockSettingsService can request it for SP protector keys.
This CL does *not* do any of the following:
- Add any non-hidden APIs. KeyMint implementations only support a
limited number of rollback-resistant keys; currently the available
space is reserved for platform use only. Note that other examples of
"hidden", platform-only key properties are
isCriticalToDeviceEncryption() and getBoundToSpecificSecureUserId().
- Support rollback resistance with keys directly generated by Keystore.
This isn't currently needed. Note that this would require changes
KeyGenParameterSpec and AndroidKeyStoreKeyGeneratorSpi.
- Allow querying the rollback resistance property of keys. This isn't
currently needed. Note that this would require changes to KeyInfo and
AndroidKeyStoreSecretKeyFactorySpi.
Bug: 239632930
Test: see I05f3b7e5c139471febe5c266a39e3dc3bca4831f
Change-Id: Ifcfd0b8f1bf440ef1ac80a9ac2b0e9c7f62106dd
Previously, the key pair generation would error out even if we
successfully provisioned attestation keys. Instead, we should retry
key generation after the GenerateRkpKeyService reports an OK status.
Bug: 231495834
Test: RemoteProvisionerUnitTests
Change-Id: I049294cbc7119de55b5de02499bf4609d4c6de5d
Implement support for the X25519 key agreement functionality.
Similar to Ed25519, two new classes are added:
* AndroidKeyStoreXDHPrivateKey
* AndroidKeyStoreXDHPublicKey
The private key class is simply a handle to the KeyMint key.
The public key class implements XECPublicKey, the interface
needed for using this key in a platform-backed key agreement.
Because of Conscrypt API boundaries, the functionality of Conscrypt's
OpenSSLX25519PublicKey is duplicated here - namely, matching the
prefix of the encoded key.
Bug: 194359292
Test: atest android.keystore.cts.Curve25519Test
Change-Id: Ifc12be528ab544fd6909bb0dd6224a0a4dd400c6
Wire Ed25519 signing into Keystore. This consists of registering a
provider for Ed25519.
Ed25519 has its own digest scheme, so the caller should specify "none"
as the digest scheme, and that's the tag that's going to be passed into
KeyMint.
However, unlike other uses of the "NONE" digest scheme, the input to the
signature algorithm should not be truncated.
Bug: 194359292
Test: atest android.keystore.cts.Curve25519Test
Change-Id: Icce4f7f2f8fa10081a9c6beff4813c2d91756469
Implement support for Ed25519 signing keys in Android Keystore.
Because Conscrypt does not yet handle those keys, the Keystore classes
implement EdECPublicKey directly and parse the keys.
Specifically, AndroidKeyStoreEdECPublicKey can take an encoded X.509 key
specification, validate the encoding is of an Ed25519 key, then parse
the oddity and Y point on the curve.
RFC8032 describes EdDSA signature scheme, particularly Ed25519.
RFC8410, Section 3, defines the OID for Ed25519 keys (1.3.101.112).
RFC8410, Section 4, describes the encoding of the public key.
Bug: 195309719
Bug: 194359292
Bug: 214203951
Test: atest android.security.keystore2.AndroidKeyStoreEdECPublicKeyTest
Change-Id: I07b793cbd5029630768368ad4a863bbc1c828ced
This change adds some integers to the AIDL interface in order to convey
status back to the caller of generateKey(). This will inform the caller
as to whether or not the errors that may occur during provisioning are
permanent, and if not, what to do with the transient error.
Bug: 227306369
Test: RemoteProvisionerUnitTests
Change-Id: I9202358a102b0fb0a104525632a005acb7355840
On systems that rely solely on remotely-provisioned keys (RKP),
the attestation keys may run out or be unavailable for attesting
a newly-generated key. This could happen when:
* the device first connects to the Internet
* The device had all the keys used and:
** It hadn't yet completed obtaining new ones.
** The RKP server declines to issue new keys.
In these cases, the caller must be informed that their key generation
request failed (likely temporarily), and that they should retry it.
The retry policy returned tells the caller when to re-try.
Bug: 227306369
Test: atest android.keystore.cts.KeyStoreExceptionTest
Merged-In: Ief30a3ab97da95b68d172e725c38acbefab92fa9
Change-Id: I0b2619fcbcb3ac4d94ed85f3ce5934e015c0828c
On systems that rely solely on remotely-provisioned keys (RKP),
the attestation keys may run out or be unavailable for attesting
a newly-generated key. This could happen when:
* the device first connects to the Internet
* The device had all the keys used and:
** It hadn't yet completed obtaining new ones.
** The RKP server declines to issue new keys.
In these cases, the caller must be informed that their key generation
request failed (likely temporarily), and that they should retry it.
The retry policy returned tells the caller when to re-try.
Bug: 227306369
Test: atest android.keystore.cts.KeyStoreExceptionTest
Change-Id: Ief30a3ab97da95b68d172e725c38acbefab92fa9
Ensure that the user gets an accurate error message when they try to
generate Curve 25519 keys according to JEP 324
(https://openjdk.java.net/jeps/324).
Android Keystore requires every key to have a name, so it is not
possible to generate a key using NamedParameterSpec only (with a
KeyPairGenerator).
Support this and throw an exception to the caller indicating how they
_can_ generate keys with this curve.
Bug: 222440855
Bug: 195309719
Bug: 194359292
Test: atest android.keystore.cts.KeyFactoryTest android.keystore.cts.Curve25519Test
Test: atest CtsLibcoreTestCases:libcore.java.security.ProviderTest
Change-Id: I5aa163f177507906c6482d079eb6cb55d93accf7
Do not register Curve 25519 algorithms as key factories, until we fix
the registration to be in compliance with JEP 324.
Bug: 222440855
Bug: 222194540
Test: atest android.keystore.cts.Curve25519Test android.keystore.cts.KeyFactoryTest#testAlgorithmList CtsLibcoreTestCases:libcore.java.security.ProviderTest#test_Provider_getServices
Merged-In: Ibd53070a890955affaff5e4e7213892afd423db7
Change-Id: I11b3574aeff54b3eb8bf496c4c14aa1338629ce5
Do not register Curve 25519 algorithms as key factories, until we fix
the registration to be in compliance with JEP 324.
Bug: 222440855
Bug: 222194540
Test: atest android.keystore.cts.Curve25519Test android.keystore.cts.KeyFactoryTest#testAlgorithmList CtsLibcoreTestCases:libcore.java.security.ProviderTest#test_Provider_getServices
Change-Id: Ibd53070a890955affaff5e4e7213892afd423db7
Add support for Curve 25519 in the public API.
This requires upgrading the keymint dependency to V2.
Note that this CL only passes tha tags to Keystore,
but does not yet let the caller use the generated keys
because of missing Conscrypt classes.
Bug: 194359292
Test: atest android.keystore.cts.Curve25519Test
Change-Id: I15223abec34b72c857e26fcc47d8ecf08c1f8c8d
Context.unbindService() should always be called even if the
previous bindService() call returns false. Otherwise the service
might be left dangling.
Bug: 211582968
Test: None
Change-Id: Ic1705096254afa12993d8992303432896bfecd57
Surface the service-specific error message. To avoid API changes, the
error message is surfaced in the toString / getMessage methods.
Test: atest android.security.keystore.KeyStoreExceptionTest
Bug: 217593122
Change-Id: Id4090564b46db9b3b10ea390390f6683f7314463
Report KeyStore/KeyMint error messages via public API.
This lets developers find out:
* Whether an error is transient or not.
* Whether a failure is due to a system error
(system configuration/state/capabilities), or a key-related error.
* Whether user authentication is required to use the key.
Test: atest CtsKeystorePerformanceTestCases CtsKeystoreTestCases
Bug: 197890905
Merged-In: I776d9e9cc01a9dc3542a63000ee0709847760963
Change-Id: Ica0c93fdd4b89255ee0a03a9b9b948202777d4d4
- Add a new boolean attribute `inheritKeyStoreKeys` to allow apps to
indicate whether they want keys to be transferred to the updated app
- Call the appropriate KeyStore method to migrate keys from the old
namespace to the new one
- Clear keys owned by the previous app ID if it is removed
Test: atest SharedUserMigrationTest#testKeyMigration
Test: atest AndroidPackageTest
Bug: 179284822
Change-Id: I321b85b88c150f17709a2270c0cbaf368ca035cc
Update the Java framework accordingly with the underlying keystore2
changes for key migration.
Test: atest SharedUserMigrationTest#testDataMigration (in internal)
Bug: 211665859
Change-Id: I26c817dffdf2e50a43373114a63242644ee7e712
Report KeyStore/KeyMint error messages via public API.
This lets developers find out:
* Whether an error is transient or not.
* Whether a failure is due to a system error
(system configuration/state/capabilities), or a key-related error.
* Whether user authentication is required to use the key.
Test: atest CtsKeystorePerformanceTestCases CtsKeystoreTestCases
Bug: 197890905
Change-Id: I776d9e9cc01a9dc3542a63000ee0709847760963
The default value for canUnlockViaBiometrics, which determines if we
are able to show a bio prompt, is true. However, if there are 0
biometric authenticator IDs, then it's impossible for the user to
satisfy a bio prompt. In this case, we should set canUnlockViaBiometrics
to false.
The loop that is normally expected to invert canUnlockViaBiometrics was
never run in the case of 0 bio authenticator ids, so we mistakenly
let the crypto init operation succeed when we should have blocked it.
Bug: 188864794
Test: Manual, using sample app that displays a biometric prompt.
Change-Id: Ib95b0564aa098157718b8d4a45b11baa69dad71b
This fixes the contract between equals and hashCode in
AndroidKeystorePublicKey. The previous fix made only a reference
comparisson between certificate blobs. In this patch java.util.Arrays is
used to compare and compute the hash of the array.
Bug: 196118021
Test: See following CL.
Change-Id: I2b8b7e740fb377de39fd21f763e15cb00024b2fc
Fix a NullPointerException when trying to insert SecretKey that already
exists.
Bug: 202146009
Test: atest android.keystore.cts.AndroidKeyStoreTest#testKeyStore_SetKeyEntry_ReplacedWithSameGeneratedSecretKey
Change-Id: If3a4bd6677ab3173c5c1a7c921ba567b7981662b
The code was doing a reference compare, not object value comparison,
resulting in failures in the KeyStore setEntry API.
Test: CtsKeystoreTestCases:android.keystore.cts.AndroidKeyStoreTest
Fixes: 197138784
Change-Id: I2c5e47283eed5694951869e9ea3853364ddef9d1
