Legacy keystore is a old relic that was suppoed to be
disabled a while ago. It has enabled functionality that was
supposed to be removed but wasn't because it would break
changes in the VPN and WIFI code. This would begin the
process of permanently removing it.
Test: atest CtsKeystoreTestCases
Change-Id: Iedc1dca24a40eb0cf30c5280fc2842ff79cf7f17
This flag was defined as a regular flag and then was later changed to a
fixed_read_only flag. This scenario is currently "unsupported" by the
flags infrastructure; an error occurs when trying to advance the flag to
staging. Work around this by renaming the flag so that the flags
infrastructure sees it as an entirely new flag. This cl adds this flag
to the legacykeystore code as well.
Bug: 296464083
Bug: 311648623
Test: m keystore2
Change-Id: If62a5fac2404113ca0bbc0807f154401c4241bf1
This cl moves the RPC name searching logic inside the attestation
key fetch function to fix the failing tests.
Test: atest keystore2_test
Bug: 310047761
Change-Id: Ied5fbd3248cae6aec230cacfa6807b3cb2b7cf4b
This flag was defined as a regular flag and then was later changed to a
fixed_read_only flag. This scenario is currently "unsupported" by the
flags infrastructure; an error occurs when trying to advance the flag to
staging. Work around this by renaming the flag so that the flags
infrastructure sees it as an entirely new flag.
Bug: 296464083
Bug: 311648623
Test: build
Change-Id: Iafde2d63578bf65b3f5a08ab57561eadbe8f6b7a
certificate serial number. Test generates a key and verifies the
specified key characteristics.
Bug: 279721870
Test: atest keystore2_client_tests
Change-Id: I3ea356da8ca3404a94081a680210a9f426a2b908
1. Test to verify Device-Unique-Attestation is not supported on
`TRUSTED_ENVIRONMENT` security level. Test shoould fail to generate a
key with device-unique-attestation with `INVALID_ARGUMENT` error code.
2. Generate EC/RSA keys with `DEVICE_UNIQUE_ATTESTATION` using `STRONGBOX`
security level. Test should generate akey and verify key
characteristics and cert-chain signatures. Test should be able to
perform an operation using the generated key successfully.
3. Try to generate a device unique attested key with attestation of
invalid device's identifiers. Test should fail to generate a key with
error code `CANNOT_ATTEST_IDS`.
4. Generate a device unique attested key with attestation of the
device's identifiers. Test should succeed in generating a attested
key with attestation of device identifiers. Test might fail on
devices which don't support device id attestation with error response
code `CANNOT_ATTEST_IDS`. Separate test is added for each attestation
id with RSA and EC keys.
Bug: 279721870
Test: atest keystore2_client_tests
Change-Id: I627a01dc44558a4393d14f9931b1708196ee6ff9
The security improvements to UnlockedDeviceRequired in Android 12
regressed its behavior by making it no longer work for unsecured users,
e.g. users with a Swipe lock screen. Two different things broke it:
1. Keystore started enforcing that a HardwareAuthToken be present for
all keys that use UnlockedDeviceRequired.
2. Keystore started superencrypting all keys that use
UnlockedDeviceRequired. Previously, only keys that used
UserAuthenticationRequired were superencrypted.
The above changes apparently resulted from a misconception that for the
device to be unlocked, the user must have authenticated. However,
unsecured users cannot authenticate and cannot have HardwareAuthTokens,
yet the device is always considered unlocked for them.
This change first fixes cause (1) by making Keystore allow keys that use
UnlockedDeviceRequired to be used without a HardwareAuthToken, provided
that they don't also use UserAuthenticationRequired (which is the
protection that actually requires a HardwareAuthToken).
Regarding cause (2), superencryption is an important security
enhancement for UnlockedDeviceRequired, so it's not being removed.
Instead, the real problem is in the way that Keystore unnecessarily ties
superencryption to the existence of the LSKF. That is, Keystore creates
a user's super keys only when an LSKF is set, and Keystore deletes all
the user's super keys and superencrypted keys when the LSKF is removed.
Therefore, this change, in coordination with the corresponding
LockSettingsService change, makes each user's Keystore super keys have
the same lifetime as the user's synthetic password. That basically
means they are created when the user is created and are deleted only
when the user is deleted. In addition, when a user's LSKF is removed,
Keystore now deletes *only* the user's auth-bound keys.
The fix for cause (1) is entirely in Keystore and is guarded by the
fix_unlocked_device_required_keys flag. The fix for cause (2) consists
of two new IKeystoreMaintenance methods, initUserSuperKeys() and
onUserLskfRemoved(), that are called by LockSettingsService and are
flagged at the LockSettingsService level. Note that once the flag is
removed, it will be possible to remove superseded code, including the
onUserPasswordChanged() method of IKeystoreMaintenance and the
init_user() and reset_user() functions that it calls.
Bug: 296464083
Test: # Did the following with and without the flag enabled:
atest com.android.server.locksettings \
&& atest -p --include-subdirs system/security/keystore2 \
&& atest CtsKeystoreTestCases
Change-Id: If12824369fbad4a90e5cd0427e792655fd233b96
This allows rkpd_client to be reused by both keystore2 and
AVF pVM remote attestation.
Test: atest keystore2_test librkpd_client.test
Bug: 241428146
Change-Id: Ibdf95c4deb2ba499daaecd170c2971cda4e80bba
This reverts commit f84c46c3b3.
Reason for revert: Reland the original cl aosp/2821995
with an adjustment about the Timeout error type in order
to maintain the original ResponseCode.
Test: atest RkpdAppIntegrationTests
Bug: 310139666
Change-Id: Id4ee05eb616c125f9d28b25f4668ca3071ccb26c
This reverts commit 2dbabf3b72.
Reason for revert: DroidMonitor revert for b/310139666
Bug: 310139666
Change-Id: I1213940cc4e3112038c1cc66f5a218a9378d6b0f
