SIDs were not being properly applied to key parameters under the new
authentication rework. Now that biometric/credential unlocks are valid
for either auth-per-op or timeout auth bound keys, the SIDs need to be
tacked on appropriately in each authentication flow.
Bug: 148425329
Test: CtsVerifier
Change-Id: I73733b00d2da5ac78db6d77c53de144f4473bb54
The default timeout and authentication type is being updated to offer a
correct default that matches the old behavior.
Bug: 148425329
Bug: 149931201
Test: CtsVerifier
Test: atest KeyguardLockedTests
Change-Id: Id20097b04ce881e7028609d2ba1c30c26ba3c8cf
This is a completely new API so callers can follow the new pattern of
using 0 to require auth for every use of the key.
Supporting both -1 and 0 to require auth for every use of the key
increases CtsVerifier complexity exponentially (strongbox,
invalidated by enrollment, etc).
Fixes: 150823346
Test: builds
Change-Id: Ieef53a8b50f5119c5e52656e930bf16b1e8e3d89
The default timeout and authentication type is being updated to offer a
correct default that matches the old behavior.
Bug: 149931201
Test: CtsVerifier
Change-Id: I3f3d4f8d5b02455c285a882933fd6c37739ee44a
Fix the documentation for USE_INDIVIDUAL_ATTESTATION which was
copy-pasted from another attestation ID type.
Bug: 149475774
Test: That it compiles.
Change-Id: I9366870c8875997321c93fe1db216e91f374b1db
1) BiometricService / AuthService always need to be started, since on
Android 11 and later, the public credential auth API comes through this
path.
2) Consolidate getAuthenticatorId() and expose via AuthService. This is
used only by the platform during key generation. Instead of asking
each individual service, AuthService will return a list of IDs for
sensors which are enrolled and meet the required strength.
Test: atest com.android.server.biometrics
Test: fingerprint device, CtsVerifier biometric section
Test: face unlock device, CtsVerifier biometric section
Test: remove biometrics from device, CtsVerifier biometric section
Bug: 148419762
Bug: 149795050
Change-Id: I2c5385b1cd4f343fabb0010e1fe6fb1ea8283391
Previously, auth per operation keystore keys could only be authorized
with biometrics. There is no reason to restrict this functionality to
biometrics. This change slightly refactors the key parameter builder
interface to allow the caller to specify which authentication types
should be allowed for an auth per op key.
Bug: 147693375
Bug: 140256692
Test: atest keystore
Change-Id: I5cbf3d4e3f0e84d577dbf6b4cb356b1010100925
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
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv
Change-Id: I4bc8c9482e4bb1af21363f951affff7ee3fefeab
Properly define the constant for requesting the use of device individual
attestation certificate and use it in AttestationUtils.
This lets callers to DevicePolicyManager.generateKeyPair request the use
of device-unique attestation certificate, on Keymaster implementations
that support this.
Bug: 140193672
Bug: 136494773
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testKeyManagement
Change-Id: I74de89e4c121a27b0495dcb99b0775445c3d4eaf
Only send updates when a configurable threshold is met.
For some scenarios this results in a significant performance
improvement. Specifically sign operations should be 10-40% faster.
Bug: 139891753
Test: atest CtsKeystoreTestCases
Change-Id: I233679d4f8582eeaaa6f21e3102cce08110f0482
This additional input will be unused for now, but future changes are
expected to utilize it.
Test: Keystore CTS Tests
Change-Id: I5c388032e3710e3825bdb06b26443a5ae2c034a3
Two @SystemApi's being added to allow wifi mainline module to access
formal API's:
a) KeyGenParameterSpec.Builder.setUid() to allow wifi to create/store keys
with WIFI_UID.
b) AndroidKeyStoreProvider.getKeyStoreForUid() to allow wifi to get/put
any keys stored with WIFI_UID.
Both of these API's are already permission protected in the lower
layers. There is a map of euid's stored in the native keystore which
limits which uid is allowed to access which other uid's data.
Bug: 142089671
Test: make system-api-stubs-docs-update-current-api
Change-Id: I39b92d2293bcdc26bb0a4a48a1d1e4cc0b20ad0b
In order to keep conformity across the ecosystem, keystore will enforce
that HMAC key sizes coming in through the framework must be limited to
the range of 64-512 bits, inclusive. This will be the case for both TEE
and StrongBox Keymaster implementations.
Bug: 143404829
Test: atest CtsKeystoreTestCases
Change-Id: I2ea867392060f4478b5a01bd747a4345e1fded4c
Introduce a new API to request use of individual attestation
certificate for attesting keys generated by the
DevicePolicyManager.generateKeyPair method.
It builds on existing device ID attestation capabilities in two ways:
(1) Eligibility check: Assuming similar privacy requirements for the use
of individual attestation certificates, enforce the same conditions
for using them as the conditions for requesting device identifiers
in the attestation record.
(2) Keymaster interaction: Passing the right Keymaster tag to the
attestKey call, which is easily done in AttestationUtils.
Bug: 136494773
Test: CTS test to be added.
Change-Id: Idb5cee66d986a521c17e1955532d0bfae66c035d
There's a long-standing bug (since ~Marshmallow) that causes
AndroidKeyStore to truncate large (>64 KiB) blocks of data. This can
be avoided by callers by processing data in smaller chunks, and
smaller chunks are more memory-efficient while not being much (if any)
more time-efficient. But, Keystore should handle large blocks
correctly. This CL adds a test to all block cipher tests that
attempts to encrypt and then decrypt a 100 KiB block.
Bug: 123391046
Test: CtsKeystoreTestCases
Change-Id: I0c0286fd5360d4fe62cbd8130aa0c17f97318801
If a certificate is self signed, then currently KeyStore will still
attempt to find the CA certificate. When it obviously fails to find it,
a key not found exception is propagated up and thrown. This CL
suppresses that exception, as it seems to exclusively be thrown in this
condition, which is WAI. Having the stack trace show up can be very
misleading to developers.
Test: atest cts/tests/tests/keystore/src/android/keystore/cts
Change-Id: I192f54d3d8355c183e830ab09314932e8800f7ed
Mark the c'tor parameters as nullable to comply with Exception's
behaviour.
Bug: 126702366
Test: That it compiles
Change-Id: I96a7c03cb79e7180872de02bee143b67f7a408ec
If they were null, then the Parcelable would fail to work.
Bug: 126726802
Test: manual
Change-Id: I7929ffa2f20e5de1c8e68e8263cca99496e9d014
Exempt-From-Owner-Approval: Trivial API annotations
This is to keep it in sync with response codes in keystore.h.
This commit also adds the KeyPermanentlyInvalidatedException to all the
methods that could receive this error code out of KeyStore.
Bug: 118883532
Test: atest cts/hostsidetests/appsecurity/src/android/appsecurity/cts/AuthBoundKeyTest.java
Change-Id: I878a628824e2eeb639ec5678b1a5d3d10428a918
Merged-In: I878a628824e2eeb639ec5678b1a5d3d10428a918
This is to keep it in sync with response codes in keystore.h.
This commit also adds the KeyPermanentlyInvalidatedException to all the
methods that could receive this error code out of KeyStore.
Bug: 118883532
Test: atest cts/hostsidetests/appsecurity/src/android/appsecurity/cts/AuthBoundKeyTest.java
Change-Id: I878a628824e2eeb639ec5678b1a5d3d10428a918
Previously the framework would accept any key size that was a multiple
of 8 for the KeyGenerator.
Bug: 117509689
Bug: 122274787
Test: atest cts/tests/tests/keystore/src/android/keystore/cts/KeyGeneratorTest.java
Change-Id: I60b52f6062a41ae52486bae0ae36616f4b532b37
engineInit() for AndroidKeyStoreKeyGeneratorSpi does not make a call
into the backing Keymaster implementation until generate is called on it
to actually create the key. If a disallowed spec for StrongBox is passed
in, the backing StrongBox implementation won't be able to revoke it
until engineGenerateKey() is called, which will create different
behaviors between TEE backed implementations (which support a wider
range of algorithm spec parameters) and StrongBox implementations from a
public API perspective. This change will make sure HMAC is the same for
StrongBox.
This is also being done for EC keys in
AndroidKeyStoreKeyPairGeneratorSpi.java
Bug: 113525261
Bug: 114487149
Test: atest cts/tests/tests/keystore/src/android/keystore/cts/KeyGeneratorTest.java
Test: atest
cts/tests/tests/keystore/src/android/keystore/cts/KeyPairGeneratorTest.java
Change-Id: I728bb5222c9bf0ad84cdf2b8c0b78a4dd99f7186
API stubs generation implicitly made any types used by an API also part
of that API. This has caused DeviceIdAttestationException and
ImsFeature.Capabilities to become implicit APIs, so they are added to
the API files.
After this, using non-API types in APIs will become an error to prevent
implicit APIs occuring in the future.
Bug: 119556446
Test: METALAVA_PREPEND_ARGS="--error ReferencesHidden" make
Exempt-From-Owner-Approval: Identical CL has been approved on other branch
Change-Id: I5fe4f20502b8d4e287b28e9f07139456d4191e22
Merged-In: I5fe4f20502b8d4e287b28e9f07139456d4191e22
(cherry picked from commit 8f91e5fde8)
API stubs generation implicitly made any types used by an API also part
of that API. This has caused DeviceIdAttestationException and
ImsFeature.Capabilities to become implicit APIs, so they are added to
the API files.
After this, using non-API types in APIs will become an error to prevent
implicit APIs occuring in the future.
Bug: 119556446
Test: METALAVA_PREPEND_ARGS="--error ReferencesHidden" make
Change-Id: I5fe4f20502b8d4e287b28e9f07139456d4191e22
