| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
Android Keystore provider's KeyFactory and SecretKeyFactory
implementations were throwing UnsupportedOperationException instead of
InvalidKeyException/InvalidKeySpecException from their
translateKey/generateKey methods.
Bug: 22459811
Change-Id: I6d5a5dc1bed724e858ad324d558b7480b9b848da
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This makes Android Keystore Cipher implementations reject rather than
ignore AlgorithmParameters of wrong algorithm type. The danger in not
doing so is that a Cipher will produce output that does not actually
depend on the provided AlgorithmParameters.
Bug: 22330716
Change-Id: Ifa9de2c74f2fe4b738a3731c895059dddd075a13
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Due to a bug, Android Keystore failed to load AES keys authorized for
use with one or more digests. This CL fixes this bug.
Bug: 22300737
Change-Id: Ia49e27833dddb526565e4dc4977ed1e352e5836b
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This avoids IllegalStateException when generating/importing keys which
require user authentication when the system is not configured to
generate/import such keys (e.g., secure lock screen not set up).
The documentation states that before generating/importing such keys
apps should check (using public API) whether the system is in a
suitable state. However, some apps are not doing that and instead
catching the IllegalStateException thrown during key
generation/import. This is a bad practice because this exception is an
undocumented implementation detail and should thus not be depended
upon.
This CL addresses this issue as follows:
1. Key(Pair)Generator.init now throws a checked
InvalidAlgorithmParameterException when the system is in a wrong
state. Because in most uses of Key(Pair)Generator .init is
immediately followed by .generate, this prevents .generate from
encountering this state and does so using a checked exception
which is part of public API.
2. Key import rethrows the IllegalStateException as a checked
KeyStoreException which is meant to be thrown if the key cannot be
imported for any reason. Key(Pair)Generator.generate unfortunately
cannot throw any checked exceptions and thus has to continue
throwing unchecked exceptions.
Bug: 22262809
Change-Id: Ic0f7b7a90e0ba63df9139c79b80a8649d2645d2a
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Several methods need to be called off the main UI thread. This is
the first documentation of that requirement.
Bug: 19440165
Change-Id: I0303011c0ded6ec1efa92119c1e02a8a39b14a59
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This enforces the randomized encryption requirement (IND-CPA), if
requested, when generating asymmetric key pairs. Whether randomized
encryption is used depends on the encryption padding modes authorized
for the key pair. Thus, if randomized encryption is required, the
KeyPairGenerator must reject attempts to generate keys authorized for
encryption using non-compliant padding schemes.
This is similar to the existing check in AndroidKeyStoreImpl during
asymmetric key import.
Bug: 22179911
Change-Id: I3d85367259c17bd44198a736ace853d0d3567d5e
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Android Keystore cannot offer crypto operations for public keys of
trusted certificate entries (entries without a private key). Prior to
this CL it accidentally tried to do so, causing crypto operations on
these keys to fail.
The fix is for Android Keystore to offer crypto operations only for
public keys for which there is a corresponding private key in the
keystore. Crypto operations on public keys from trusted certificate
entries will be handled by other installed crypto providers. Those
providers don't need a private key to carry out these operations on
public keys.
Bug: 22091725
Bug: 21835320
Change-Id: Ib7d92b067711e4c57128d0db72c08bf288a45ce1
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some apps such as OpenVPN Connect for some reason generate
PKCS#1-padded RSA signatures using Cipher (initialized in
Cipher.ENCRYPT_MODE with private key!) instead of using Signature.
Unfortunately, RI supports this strange behavior and previous releases
of Android Keystore did the same. So, we have to continue supporting
this craziness.
Bug: 22083023
Change-Id: Ife3950d0d4ceb4e44e08014635312c1252878b69
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Keymaster's implementation of ECDSA with digest NONE rejects input
longer than group size in bytes. RI's NONEwithECDSA accepts inputs
of arbitrary length by truncating them to the above size. This CL
makes Android Keystore's NONEwithECDSA do the truncation to keep
the JCA and Keymaster happy.
The change is inside AndroidKeyStoreECDSASignatureSpi$NONE. All other
small modifications are for supporting that change by making it
possible for AndroidKeyStoreSignatureSpiBase to pass in the signature
being verified into KeyStoreCryptoOperationStreamer. This in turn is
needed to make it possible for NONEwithECDSA implementation to provide
a wrapper streamer which truncates input.
Bug: 22030217
Change-Id: I26064f6df37ef8c631d70a36a356aa0b76a9ad29
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 CL makes Android Keystore framework code add
KM_TAG_ACTIVE_DATETIME, KM_TAG_ORIGINATION_EXPIRE_DATETIME, and
KM_TAG_USAGE_EXPIRE_DATETIME tags to the authorizations set only
if the corresponding time instants were specified through the
framework-level API. This is fine because these tags are optional as
it turns out.
Bug: 18088752
Change-Id: I6a5ae4cadb441e61576231815e6bec6e9248bc72
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This makes Android Keystore's KeyPairGenerator fall back to generating
a self-signed certificate with an invalid/fake signature when the
attempt to generate a self-signed certificate with a valid signature
fails.
There is a growing number of reasons/authorizations due to which the
generated private key cannot be used to sign the self-signed
certificate. It's safer for KeyPairGenerator to succeed than to fail.
Bug: 22033161
Change-Id: I1ecbd421346166bfd536b5cfbaea169b11f0b1c8
|
|/
|
|
|
|
|
|
| |
The typo was pointed out by kroot@ in code review of
4ecd092226fbd748b4a26f3bbb5c4d25a3488fff after it was submitted.
Bug: 18088752
Change-Id: I50d2fa93e1a2d352fe432e34ce98add82a71c483
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This raises the space overhead estimate by one byte, due to me having
originally forgotten that when signing using RSA PKCS#1 padding
scheme, the plaintext of the RSA operation needs a leading 0 byte.
Bug: 21955742
Change-Id: If78efcd375afd8902a14a2217ddedfea87d4d337
|
|/
|
|
|
|
|
|
| |
RSA encryption/decryption keys used with RSA OAEP padding scheme now
require the key to be authorized for the digest used by OAEP.
Bug: 21998286
Change-Id: I1f5eb1b30a1b574c45ffcabed6096de8671882d3
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The variant of CipherSpi.engineUpdateAAD which takes ByteBuffers
delegated to a byte[]-taking variant of superclass instead of its own
class.
Bug: 18088752
Change-Id: I3b426bbdca54bbf7f6f3939589da07b24db14d0d
|
|/
|
|
|
|
|
|
|
|
|
|
| |
This adds support obtaining RSAPublicKeySpec, ECPublicKeySpec,
X509EncodedKeySpec from Android Keystore public keys.
Using a KeyFactory to obtain such specs is the endorsed way for
obtaining algorithm-specific parameters or X.509 encoding of PublicKey
instances.
Bug: 18088752
Change-Id: I2c653238e3c89d9cfc97bea6c8a0ef0c6d039385
|
|
|
|
|
|
|
|
|
|
| |
Should be "with" and not "With". Has the side effect of fixing
a test that assumes that these names are case-sensitive. While the
test must be fixed separately, this is still good for consistency.
bug: 21870226
Change-Id: I884b4abdbb18be064210555aec8e0cd16b0d0bcb
|
|
|
|
|
|
|
|
|
| |
There is no need to authorize PKCS#1 signature padding scheme when
NONE padding scheme is authorized. NONE authorizes the use of any
padding scheme.
Bug: 18088752
Change-Id: I73ccb373d577c988acde372d972092278923c4e4
|
|\ |
|
| |
| |
| |
| |
| | |
Bug: 21786749
Change-Id: If3824d1321ef1d8730d4384717b0c25d43518fe4
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| | |
Bug: 18088752
Change-Id: I24eeb33790a74d8d81d10fcdb1eb058d47144c44
|
|\ \ |
|
| |/
| |
| |
| |
| |
| | |
Bug: 18088752
Bug: 21786749
Change-Id: Ica90491037d2920f7635195894ba18882fc4406d
|
|/
|
|
|
|
|
|
| |
The minimum EC keys size is now 224 bit. This is because keymaster 1.0
does not support EC keys smaller than 224 bit.
Bug: 18088752
Change-Id: I8010ff2d6ccaeea7dcf86f697aee1d9ebd683cb2
|
|
|
|
|
|
|
| |
This ensures that KeyInfo instances are truly immutable.
Bug: 18088752
Change-Id: Ic157d3b928b129a02c3cab9dd20ba9936a005813
|
|
|
|
|
|
|
|
| |
This ensures that instances of this class are immutable and cleans up
some flawed logic discovered when writing up CTS tests.
Bug: 18088752
Change-Id: If9cc33192ada5a8982a2b200ab24cb18331cf958
|
|
|
|
|
|
|
|
| |
This ensures that instances of this class are immutable and cleans up
some flawed logic discovered when writing up CTS tests.
Bug: 18088752
Change-Id: I7a27dbfc3445599bccabbd26e39535ce988a2ab2
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When Android Keystore generates an asymmetric key pair, it needs to
create a self-signed certificate for that pair, in order to expose
the key pair in the JCA KeyStore abstraction through which keys are
later retrieved. The self-signed certificate is normally signed with
the private key.
This CL avoids using the private key to sign the certificate if the
private key can be used only once the user has been authenticated.
For such keys, a fake (non-verifying) signature is used on the
certificate, same as for cases where the key is not authorized for
signing.
Bug: 21852844
Change-Id: Id78bc1f51d12950db4e37c1e0da6c60057d4e693
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
This class was added in Android M to enable us to expose ECIES. ECIES
is not going to happen in Android M. I'm thus removing this unused
class until such time when it's needed.
Bug: 18088752
Change-Id: I16ab1bbd0b4334419c9a8f29d64661c150aa8d32
|
|/
|
|
|
|
|
|
|
|
| |
This updates the Javadocs of Android Keystore to explain what key
authorizations are needed for the self-signed cert create at key
generation time to have a valid signature.
Bug: 18088752
Bug: 21777596
Change-Id: Id02425133f094a0c5a02e96f4c63aab7175cba5b
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes a bug where key pair generation fails for RSA signing keys
which are not authorized for PKCS#1 signature padding, such as keys
authorized only for the RSA PSS signature padding scheme.
The issue was that the KeyPairGenerator was failing when attempting to
sign the self-signed certificate (needed by Android Keystore) using
PKCS#1 padding for which such keys are not authorized. The solution is
to not attempt to sign these certificates and instead use a fake
signature.
Bug: 21809600
Change-Id: I4f04fcf78174937046d2534e0485c6940eae673f
|
|\ \
| | |
| | |
| | | |
mnc-dev
|
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
This also adds information about what digests and paddings may need to
be specified for keys used in TLS/SSL for client or server
authentication.
Bug: 21777596
Change-Id: Icd495458c38c4f912b21a64ca7aab2c88d76461c
|
|/
|
|
|
|
|
|
|
|
| |
This makes Android Keystore crypto operations defer pulling entropy
from provided SecureRandom until KeyStore.finish, where appropriate.
Such as when performing asymmetric encryption or generating
signatures.
Bug: 18088752
Change-Id: I4a897754e9a846214cf0995c5514f98cf0edd76b
|
|\
| |
| |
| | |
into mnc-dev
|
| |
| |
| |
| |
| | |
Bug: 20912868
Change-Id: I633d3caa3f40dd0b038b2f7e75825614bed2c0f5
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|