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
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
getUniqueAliases may return a null if an error occurred. This would lead
to a NPE in engineAliases.
This patch makes getUniqueAliases return an empty HashSet instead.
Test: atest KeystoreTests
Change-Id: I387d90ea851a8b9c18bb2b20d1a0bfc1ab76c99f
Mirror KeyProtection.setCriticalToDeviceEncryption so
the flag can also be set on keys generated by keystore.
Bug: 72178550
Test: atest android.security.keystore.KeyGenParameterSpecTest
Test: atest android.security.ParcelableKeyGenParameterSpecTest
Change-Id: I7f102c82e60f211028c694d499ffd2838b89bb2b
Due to an oversight, some of the key generation parameters that are set
in KeyGenParameterSpec were not preserved when parceling the object
(they should have been added to ParcelableKeyGenParameterSpec but were
not).
This means these parameters will be ignored when generating keys using
the DevicePolicyManager.generateKeyPair method, leading to an
inconsistent key generation behaviour between the DevicePolicyManager
and KeyStore.
In particular, this would prevent callers from using StrongBox when
generating keys for use in the KeyChain.
Fix the issue by simply persisting these parameters in
ParcelableKeyGenParameterSpec and making sure that the Builder copies
them too from the source KeyGenParameterSpec.
Left to do is put in place an automated measure to find out
discrepancies between the two classes.
Bug: 110915980
Bug: 110882855
Bug: 109953656
Test: atest KeystoreTests
Change-Id: Ic64bd2921b6dfc97ea34ecba55f532312963ffcb
If the KeyGenParameterSpec passed into
DevicePolicyManager.generateKeyPair contains an attestation challenge,
request an attestation record for the newly-generated key with the
challenge provided.
This particular implementation was chosen, rather than letting the
attestation record be generated at the same time as key generation, to
avoid having the attestation chain stored in Keystore and associated
with the generated alias.
The rationale is that this is a key that is potentially accessible by
multiple applications and the attestation chain may end up being sent
as a TLS client certificate chain, for example.
As the attestation challenge should be unique per device, to avoid
the potential of sending / sharing unique device information, by
explicitly requesting an attestation record after key generation, the
attestation record is only returned to the generateKeyPair client and
not persistend in Keystore.
Bug: 63388672
Test: New CTS test to be run with: 'cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG'
Change-Id: I95a9aef179173b571b533301ac438c675e8fe702
This is the crux of the Verified Access feature implementation:
Adding the ability to generate KeyChain keys directly by the
secure hardware, rather than installing software-generated keys
into KeyChain.
Add generateKeyPair to the DevicePolicyManager, which delegates key
generation (via the DevicePolicyManagerService) to the KeyChainService.
Design highlights:
* The key generation is delegated via the DevicePolicyManagerService to
check that only authorized callers request key generation in KeyChain.
* KeyChainService performs the actual key generation so it owns the key
in Keystore outright.
* DevicePolicyManagerService then grants the calling app access to the
Keystore key, so it can actually be used.
* Loading the public/private key pair, as well as attestation
certificate chain, is done in the client code (DevicePolicyManager)
to save parceling / unparceling those objects across process
boundaries twice (for no good reason).
NOTE: The key attestation functionality (that includes Device ID) is
missing/untested. Will be added in a follow-up CL as this one is quite
big already.
HIGHLIGHT FOR REVIEWERS:
* API: New API in DevicePolicyManager.
Bug: 63388672
Test: cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG; adb shell am instrument 'android.security.tests/android.support.test.runner.AndroidJUnitRunner' (After building the KeystoreTests target and installing the apk)
Change-Id: I73762c9123f32a94d454ba4f8b533883b55c44cc
These depended on internal implementation details of Conscrypt that are
changing. Delete these tests since they're not included in builds any
more.
Test: make checkbuild
Change-Id: I6ddf832c30bcf49e940c55aa81534c3d987393fb
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 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 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
Output parameters are gone from begin, instead they will returned in the
OperationResult and begin, update, and finish may return output
parameters.
Change-Id: I072afeb6c65f6c512b40603824c25686ac44e7c8
begin now returns OP_AUTH_REQUIRED for per operations with per op
authorization instead of NO_ERROR.
(cherry-picked from commit b0addbaaf2)
Change-Id: I1f472125f46155833e03ab30bf18363ff51b2c58
This moves the non-public API classes backing Android Keystore from
android.security to android.security.keystore, a package specially
created for Android Keystore.
Bug: 18088752
Change-Id: Ibf04d6a26c54d310b0501fc5e34f37b1176324ad
This CL addresses the comments from API Council about Android KeyStore
KeyPairGeneratorSpec, KeyGeneratorSpec and KeyStoreParameter:
1. These abstractions should not take or hold references to Context.
2. The Builders of these abstractions should take all mandatory
parameters in their constructors rather than expose them as
setters -- only optional paratemers should be exposed via setters.
These comments cannot be addressed without deprecation in the already
launched KeyPairGeneratorSpec and KeyStoreParameter. Instead of
deprecating just the getContext methods and Builder constructors, this
CL goes for the nuclear option of deprecating KeyPairGeneratorSpec and
KeyStoreParameter as a whole and exposing all of the AndroidKeyStore
API in the new package android.security.keystore. This enables this CL
to correct all of the accrued design issues with KeyPairGeneratorSpec
(e.g., naming of certificate-related methods) and KeyStoreParameter.
This also makes the transition to API Level M more clear for existing
users of the AndroidKeyStore API. These users will only have to deal
with the new always-mandatory parameters (e.g., purposes) and
sometimes-mandatory (e.g., digests, block modes, paddings) if they
switch to the new API. Prior to this CL they would've had to deal with
this if they invoked any of the new methods of KeyPairGeneratorSpec
or KeyStoreParameter introduced in API Level M.
This CL rips out all the new API introduced into KeyPairGeneratorSpec
and KeyStoreParameter classes for Android M, thus reverting these
classes to the API launched in L MR1. This is because the new API is
now in android.security.keystore.KeyGenParameterSpec and KeyProtection
respectively.
Bug: 21039983
Change-Id: I59672b3c6ef7bc25c40aa85f1c47d9d8a05d627c
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 c5e4d7af22)
Bug: 19509156
Change-Id: Ibc665fbc893766a683a4aadc97a64ffdf2d0d85f
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
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
This removes the need to specify the three parameters of the
self-signed certificate (serial number, subject, validity range) when
generating key pairs in AndroidKeyStore. This is achieved by
providing sensible defaults for these parameters:
* serial number: 1
* subject: CN=fake
* validity range: Jan 1 1970 to Jan 1 2048.
Bug: 18088752
Change-Id: I5df918b1ef8b26ed3ddd43828c4c78c9fa58cd43
Now that auth token checks are in keystore keys without any auth tags
are invalid.
Also adds a test to check that a key with auth required fails when none
is present.
Change-Id: I0d5d44d70a849978e9b2e809675b8343c6650ff2
generateKey and begin can now optionally take an array of bytes to add
to the rng entropy of the device before the operation. If entropy is
specified and the device does not support add_rng_entropy or the call
fails then that device will not be used, leading to fallback or error
depending on the situation.
Change-Id: Id7d33e3cc959594dfa5483d002993ba35c1fb134
AES and HmacSHA256 symmetric keys can now be imported into
AndroidKeyStore. These keys cannot yet be used.
Bug: 18088752
Change-Id: Iad2fd49d15ac4c2d676abe1153f5b5f0b6ff496c
Having it as a raw byte[] caused issues in keystore because keymaster
handles a null blob differently than a blob with null contents. Make
this explicit in the API.
Change-Id: Ifcf550f438608b8f09fc589d00d06fffa6ee463b
The test is sending too much data to be signed, which should actually
fail, and does on Volantis. Apparently the other keymaster implementors
do something to pass it, because shamu and hammerhead pass, but the test
is wrong.
Change-Id: Ic616a551567d64f5d87d9607ceb08afa7be74f9d
Add the encrypted flag for the KeyPairGenerator and the KeyStore so that
applications can choose to allow entries when there is no lockscreen.
(partial cherry pick from commit 2eeda7286f)
Bug: 8122243
Change-Id: I5ecd9251ec79ec53a3b68c0fff8dfba10873e36e
Remove the call sites that don't have the flags specified. This is to
ensure that callers know what flags they're setting.
Bug: 8122243
Change-Id: Ifbd178fddbf8dbd8f7b821ea739a20d056ef9fa7
Add the encrypted flag for the KeyPairGenerator and the KeyStore so that
applications can choose to allow entries when there is no lockscreen.
Bug: 8122243
Change-Id: Ia802afe965f2377ad3f282dab8c512388c705850
After discussion, it was determined that duplicate would be less
disruptive and it still fit in the current HAL model.
Change-Id: I2f9cae48d38ec7146511e876450fa39fc92cda55
To support the WiFi service, we need to support migration from the
system UID to the wifi UID. This adds a command to achieve the
migration.
Bug: 8122243
Change-Id: I65f7a91504c1d2a2aac22b9c3051adffd28d66c1
