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
It's better to use an Application Context rather than hoping the
activity won't be destroyed in another thread (because it will).
Change-Id: I9bf842d0d7dbedcc509a4a314d23a9a6cfca4d48
Fix: 29873669
If any /data/system_[c|d]e folders were not erased
when the user was removed (maybe due to a reboot),
make sure they're cleaned up on restart as well
as when the userId is recycled later.
Mark the users' system folders with the correct
serial number for later verification.
AccountManager shouldn't be querying accounts of
partially created/destroyed users.
Change-Id: I4313756b7464f34cd5ce4fb296d61daa50b41fcb
Fixes: 29285673
Architectural changes from the Wear team have required changes to the
semantics of the Keystore on-body feature. Although no devices will
actually implement this feature until the release of new Wear devices
with the necessary sensors, we need to get the API documentation right
now.
Bug: 29369151
Change-Id: I857e00928f994a1337313123eae7e00534c53c3c
This undoes the automerger skip which occured in
commit e740c84dc32180214a7fd157105d6c18d30408ee and
replays it as a standard (NOT -s ours) merge.
Change-Id: If5a47be26f73d6a0735c425cd66310a3e2a89086
When installing a keypair the caller will have the option to specify a
certificate chain which will later be returned to whoever requests access
to the keypair via KeyChain.
Bug: 18239590
Change-Id: Id21ef026e31537db38d891cb9b712dd4fe7159c7
The Standard Names documentation says that "ECDSA" should not be used
due to its ambiguity. Bouncycastle has switched from "ECDSA" to
"SHA1withECDSA" so therefore we should switch this "workaround" Provider
to use the same name to keep it functioning correctly.
(cherry picked from commit 8a6c191094b3d1f74dbb71a7f262496377596ba8)
Bug: 27753949
Change-Id: I5acfca9d89c85bf005902a2f06cb5d7b1ef9dff2
If keychain is removed from a device, there will be no sensible
resolution and client apps will bind to whatever is available.
Doesn't affect system apps which are forcibly prevented from wildcard
binding.
Bug: 27475655
Change-Id: Ide1aab3778e12f0b9a96662deb297a76d2f4997f
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
The body of {@code} must not be HTML escaped. This is one of
several changes that fix the source in conjunction with a
doclava fix.
Bug: 25757239
(cherry-picked from commit 71fbb81b14958b80fe55738607740c6630e4e9da)
Change-Id: I19dafddc6501be6fee362c396ac5bbdc934ae39d
According to documentation:
Returns the {@code PrivateKey} for the requested alias, or null if
there is no result.
@throws KeyChainException if the alias was valid but there was some
problem accessing it.
@throws IllegalStateException if called from the main thread.
In this case the alias doesn't exist or isn't visible to the caller so
they should get null back instead of KeyChainException.
Change-Id: Ied5603ac6aefbcef79050f24c2aa7ee8f386be0b
The keypair is specified by alias and removed via a call to the
KeyChainService, which will have installed the pair in the first place.
Bug: 22541933
Change-Id: I37317e7c22e89816156e6e9a7abf4c5a59e8440a
The body of {@code} must not be HTML escaped. This is one of
several changes that fix the source in conjunction with a
doclava fix.
Bug: 25757239
Change-Id: Ib38a0fa2dd2a3d68e467f78a812071e763d7e881
This makes Android Keystore's Cipher implementation use a custom
implementation of engineUpdate(ByteBuffer, ByteBuffer) and
engineDoFinal(ByteBuffer, ByteBuffer). The implementation is
explicitly designed around the fact that Android Keystore transmits
input and receives output via Binder and thus there's no need to
attempt any optimizations to avoid copying input and output.
Bug: 25863382
Change-Id: I311072891f02f5e7a283628b51b8d6058b55231c
Security.insertProviderAt uses 1-based positions whereas the
AndroidKeyStoreProvider.install code was incorrectly passing in
0-based positions, thus installing the AndroidKeyStoreBCWorkaround
provider one level higher than intended. This change fixes the issue
in AndroidKeyStoreProvider.
Bug: 25399691
Change-Id: I4a66bf37c0d151edb9a2349db9d91939064c0574
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
Based on developer feedback, this updates Android Keystore Javadocs
with more examples of generating and importing keys of various
algorithms. This also clarifies that key use authorizations apply to
secret and private key and do no apply to public keys.
Bug: 23102874
Change-Id: If0dc20fda4836fd23b9cd9c92490a04e71b19fc0
This adjusts the public API documentation to no longer say that
digest/padding NONE means any digest/padding. This also changes the
implementation of legacy key generation and import to explicitly
list which digests/paddings the generated/imported key is authorized
for. Previously, such keys were simply authorized for digest NONE and
padding NONE.
Bug: 22556114
Change-Id: Id02d9450a07de16ccb795b76b6de0006dd49dcca
This makes Android Keystore's RSA/ECB/NoPadding Cipher implementation
rely on the underlying keystore/keymaster to left-pad the input (if
necessary) and to reject invalid input. Prior to this change the
Cipher implementation attempted to do it itself, but wasn't doing it
right anyway.
This fixes a regression where Android Keystore's raw RSA Cipher
("RSA/ECB/NoPadding") refused to encrypt plaintexts of the same length
(in bytes) as RSA modulus which were nevertheless numerically smaller
than the RSA modulus.
Bug: 22599805
Change-Id: I591a8115a574eaf8f6075f29b50d93a87532c5eb
This makes Android Keystore add the KM_MIN_MAC_LENGTH tag to generated
and imported HMAC and AES-GCM keys. This tag specifies the minimum
length of the MAC/authentication tag authorized to be used for the
key.
For HMAC keys the minimum MAC length is set to the length of the
digest associated with the key (HMAC keys are authorized for exactly
one digest). For AES keys the minimum authetication tag length is set
to 96 bit. This is the minimum supported by Android Keystore's AES-GCM
implementation.
Bug: 22337277
Change-Id: Ic6e47cf084734d1592788dc58088889f7fff74eb
Keymaster1 HAL permits the implementation of "update" operation to
leave some input unconsumed by the time "finish" operation neeeds to
be invoked. This needs to be treated as "invalid input" error rather
than a "can't happen" exception.
This CL was confirmed to fix the issue by the vendor who encountered
the issue.
Bug: 22512100
Change-Id: Ibb1a37d58f650d03605612559a154ce2416d147c
This is in preparation for enforcing the minimum length of MACs
which in the case of HMAC keys generated or imported by Android
Keystore will be set to the length of the digest for which the
key is authorized.
Bug: 22337277
Change-Id: I0255d5ba184dabfb6b45d8f32ddadeb84ab7fc19
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
