| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When Android KeyStore loads an HMAC key, it needs to compose the JCA
key algorithm name (e.g., HmacSHA256) based on the digests the key is
authorized for. A key can be authorized for multiple digests. Thus,
the approach is to use the first one for constructing the JCA key
algorithm name.
This CL ensures that when importing HMAC keys the first KM_TAG_DIGEST
tag is set to the digest of the JCA key algorithm name.
Bug: 18088752
Change-Id: I911ca7427b249ee823d06e988687af6146ebaff8
|
|/
|
|
|
|
| |
(cherry-picked from commit 31c2897105e6d71f8e6edeab312d2147bbdbaeb1)
Change-Id: I73fe9344ec5660e58425d5c85d14381820533d57
|
|
|
|
|
|
|
|
|
| |
This moves constants/flags declared in inner classes of
KeyStoreKeyProperties into KeyStoreKeyProperties, as requested by API
Council.
Bug: 21039983
Change-Id: I84a3c983e13644a027bed9f605ab8044220a352c
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This updates the Javadocs of AndroidKeyStore methods which take
constants defined in KeyStoreKeyProperties to contain a link to
the corresponding set of constants and an example of a couple of
accepted constants, to make it easier to understand and find out
what constants to use.
Bug: 18088752
Change-Id: I338134ef136db62a7caca782cb59dbebdc996670
|
| |
| |
| |
| |
| |
| |
| |
| | |
This gets rid of EcIesParameterSpec.PointFormat by moving the
constants into EcIesParameterSpec, prefixed with POINT_FORMAT_.
Bug: 21039983
Change-Id: I7a76bb84e0394db9c7f5b0d53526915d5bbdd511
|
|\ \
| |/
|/|
| | |
into mnc-dev
|
| |
| |
| |
| |
| |
| |
| |
| | |
By convention, these annotation classes should remain hidden API.
Bug: 18088752
Bug: 21039983
Change-Id: Ifb5d2910c7dae4e0fd809876eb641f1aaf7a00a6
|
|\ \ |
|
| |/
| |
| |
| | |
Change-Id: If14fe3c3c7ed123b0fa9d5874db2ad8844e49671
|
|/
|
|
|
|
|
|
| |
This is to enable Android Lint and Android Studio to flag nullness
issues at compile time.
Bug: 18088752
Change-Id: I21033b8fcdd989d08c89b50685e47fbb9c74acbf
|
|
|
|
|
|
|
|
|
|
|
| |
Keystore's begin operation now requires parameters which describe the
operation (e.g., algorithm, block mode, padding). This adjusts
KeyStoreTest to provide the necessary parameters.
(cherry-picked from commit c5e4d7af22793072a2620805f5e0e23bf15e7110)
Bug: 19509156
Change-Id: Ibc665fbc893766a683a4aadc97a64ffdf2d0d85f
|
|
|
|
|
|
|
|
|
| |
This also drops the boolean parameter from
KeyGeneratorSpec.Builder.setEncryptionRequired to match the already
launched KeyPairGeneratorSpec.Builder.setEncryptionRequired.
Bug: 18088752
Change-Id: I91a3e8c77958971b1bda8329319f1a0d8043b669
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This adds more detailed class-level Javadocs (incl. examples) for the
following public API of Android KeyStore facility:
* KeyPairGeneratorSpec,
* KeyGeneratorSpec,
* KeyStoreParameter,
* KeyStoreKeySpec.
This also clarifies what encryption at rest means.
Bug: 18088752
Change-Id: I9951a528c34dea322534763b596902a2b6ac64f9
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add KeyStore.onUserPasswordChanged for the lockscreen to call when
the user changes their password. Keystore will then handle the logic of
deleting keys. Instead of calling Keystore.password_uid for both
unlocking and password changes the behavior has been split into
Keystore.unlock and onUserPasswordChanged.
Change-Id: I324914c00195d762cbaa8c63084e41fa796b7df8
|
| |
| |
| |
| |
| |
| |
| | |
This is to make the Android KeyStore API more generic.
Bug: 18088752
Change-Id: I18bcc96db4af17127e5dc038becc9deb85bb48aa
|
|\ \
| | |
| | |
| | | |
mnc-dev
|
| | |
| | |
| | |
| | |
| | | |
Bug: 18088752
Change-Id: Idfcf57251e76185425b9271d6a2001c5556f9f59
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
KeyGenerator.init is supposed to check whether all provided parameters
are OK. This is because KeyGenerator.generateKey cannot throw checked
exceptions. This CL makes AndroidKeyStore KeyGenerator implementation
do just that. Unfortunately, keymaster/kestore doesn't provide a way
to check whether all the parameters are OK without actually generating
a key. Thus, this KeyGenerator does its best inside init method
(before Keymaster is called), and then surfaces any remaining issues
(flagged by Keymaster/keystore) as unchecked IllegalStateException.
Bug: 18088752
Change-Id: I9a04da880dcbe26c37f41d1477e41bdc74db04c9
|
|\ \ \
| |/ /
|/| | |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This switches to ProviderException in most places in AndroidKeyStore
primitives where checked exceptions cannot be thrown. This is to
follow JCA design.
KeyStoreKeyGeneratorSpi is not touched by this CL because there's
another CL already doing that.
Bug: 18088752
Change-Id: If7e93042f973334b9bba004f5a330f831c1e77c1
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This makes AndroidKeyStore Cipher and KeyGenerator implementations mix
in additional entropy into keymaster's RNG regardless of whether they
were provided with a SecureRandom instance.
In practice, they are always provided with a SecureRandom instance.
However, to be safe, when no SecureRandom instance is provided the
code now uses a platform-default SecureRandom implementation.
Bug: 18088752
Change-Id: I85bca30d7bdc82c2a342094dcbe6044e48a63dca
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
The Javadoc incorrectly stated that:
* 0 means authentication required for every use.
* -1 means that timeout is not specified and the key can be any time.
Bug: 18088752
Change-Id: Ie5f37e74dc207f23443527ac1725ae8a37213d75
|
|/
|
|
|
|
|
|
|
|
| |
This defines the String enum values based on JCA standard names for
key algorithm, block mode, padding schemes, and digests. This should
make it safer to interact with AndroidKeyStore code that uses JCA
strings. This was requested by API Council.
Bug: 18088752
Change-Id: I241d9225a13b85479d0a84e49d0a98cbc77e5817
|
|
|
|
|
|
|
|
| |
This propagates the concept that 0 is an invalid crypto operation
handle to the outside of AndroidKeyStore abstraction.
Bug: 20864436
Change-Id: I1e5abb66c5d41d8fc32aac44372495a708c2b6e2
|
|
|
|
|
|
|
|
|
| |
This converts KM_ERROR_CALLER_NONCE_PROHIBITED into
InvalidAlgorithmParameterSpec, as expected by the contract of JCA
Cipher.
Bug: 18088752
Change-Id: I6a01e2d7118c478b27a0d7a5a14a127de8913755
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
FingerprintService is a lower layer of abstraction which should
ideally be accessed only via FingerprintManager from
AndroidKeyStore.
The main issue with the switch is that it requires a reference to a
Context. This is now obtained using ActivityThread's hidden API.
Change-Id: If921e169838ee2cc5c7690b8c8d8ea95c33248aa
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| | |
This streamlines the exception throwing logic for per-op auth keys of
AndroidKeyStore.
Change-Id: I7e27c17fd89d5a7f71f5d7578f584189c5236fb8
|
|\ \ |
|
| |/
| |
| |
| | |
Change-Id: I24e697e989b5f88c3f5e61343fbff60a09aa4c12
|
|/
|
|
|
|
|
|
| |
* MAC length is now specified as a parameters to the begin operation
instead of as a parameter at key generation/import time.
* KM_TAG_MAC_LENGTH is now in bits instead of in bytes.
Change-Id: I752fe232d11d3ac39a575a48948215d84ded8fb9
|
|\
| |
| |
| | |
mnc-dev
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Bouncy Castle JCA provider incorrectly declares that its Cipher, Mac,
Signature, and KeyAgreement implementations accept arbitrary keys (
including AndroidKeyStore keys). As a result, when a Cipher, Mac,
Signature, or KeyAgreement instance is requested from JCA without
explicitly specifying the provider (which follows best practices)
and then initialied with an AndroidKeyStore key, JCA chooses the
BouncyCastle's implementation, which in turn blows up because it
can't handle such keys.
The workaround is to install Cipher, Mac, Signature, and
KeyAgreement implementations backed by AndroidKeyStore as a
higher-priority JCA provider than the Bouncy Castle one. This is
achieved by splitting out the above implementations from
AndroidKeyStoreProvider into AndroidKeyStoreBCWorkaroundProvider
and installing the AndroidKeyStoreProvider at the usual priority
(below Bouncy Castle) and the AndroidKeyStoreBCWorkaroundProvider
at above Bouncy Castle priority.
Bug: 20691708
Change-Id: I336464f4a49bc30c6845ddc4e84b07f4105424dd
|
| |
| |
| |
| |
| | |
Bug: 20642549
Change-Id: Ibda270921f13a1fd695264583b0e4bd255f63aed
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This makes symmetric Cipher and Mac implementations backed by
AndroidKeyStore succeed in their initialization when the key is
configured to require user authentication for every use. Users
of such keys should obtain an instance of Cipher or Mac, initialize
it with the key, and then authorize the operation by passing this
Cipher or Mac instance to FingerprintManager.authenticate.
Bug: 18088752
Change-Id: Ia15a1e5f8274c3623f665dae1f400ff539639ab1
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This enables users of AndroidKeyStore crypto to differentiate between
the key being unusable until the user is authenticated
(UserNotAuthenticatedException) and the key being permanently unusable
(KeyPermanentlyInvalidatedException). The latter is the case when the
secure lock screen has been disabled or reset, and, for keys that
require user authentication for every use, when a new fingerprint is
enrolled or all fingerprints are unenrolled.
NOTE: The KeyPermanentlyInvalidatedException subsumes/replaces the
NewFingerprintEnrolledException which has thus been removed. There
is no way to find out whether a key was permenently invalidated
specifically because a new fingerprint was added.
Bug: 20642549
Bug: 20526234
Change-Id: I0206cd99eef5c605c9c4d6afc5eea02eb3b1fe6b
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
OP_AUTH_NEEDED will be returned from begin when an operation needs
a per operation authentication before calling update. Note that the
begin call succeeds when this error is returned, the token and handle
are valid.
(cherry picked from commit dabe520a3e6b0d0c40adfd748483fa336c43c366)
Change-Id: I0ba4e997360843b5eb6c1db9c5fcd1c4d5a2c717
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This simplifies the AndroidKeyStore API around user authentication: no
more explicit control over which user authenticators are bound to
which keys.
User-authenticated keys with timeout are unlocked by whatever unlocks
the secure lock screen (currently, password/PIN/pattern or
fingerprint). User-authenticated keys that need authentication for
every use are unlocked by fingerprint only.
Bug: 20526234
Bug: 20642549
Change-Id: I1e5e6c988f32657d820797ad5696797477a9ebe9
|
|\
| |
| |
| |
| |
| |
| | |
using NativeConstants."
* commit '6c1af7ea497b1a2f04bdf45a19d2147f5b9665b9':
frameworks/base: switch to using NativeConstants.
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
NativeCrypto is a conscrypt class that contained several OpenSSL
constants. NativeConstants is the new class that contains the same
thing, but the latter is automatically generated and thus won't drift
from the C headers.
Bug: 20521989
Change-Id: I45c7b9a6844a06e3ffd09be692ebf733e1ebbbcc
|
|\ \ \
| |/ /
| | |
| | | |
Change-Id: Ifa29891b8ad7979cbc28c54180b9606bb1319ff0
|