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
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
This makes rkpd_client independent of keystore2 and facilitates
the extraction of rkpd_client as a standalone library later.
Test: atest keystore2_test
Bug: 241428146
Change-Id: I3bcf0afdb587b2e95bd9a970631c29696f57ed4f
If a device has upgraded Android versions then the KeyMint device
may also have been upgraded. If that's the case, then there may
be keyblobs that were created in software on the old device, because it
didn't support some feature.
Watch out for these keys, and if encountered, try to import them into
the current KeyMint device:
- extract the key material from the key blob
- add PKCS#8 wrapping for import
Bug: 283077822
Bug: 296403357
Test: tested with ARC upgrade, see b/296403357
Change-Id: I146f7cfdaac9fe22b7bb6850b7e48ea113945902
CLOCK_BOOTTIME is more correct because it includes time spent
while the device is suspended.
This also fixes an issue when comparing the times resulting from the
get_last_auth_time() API in the Java world, because we want to use
SystemClock.elapsedRealtime(), which uses CLOCK_BOOTTIME.
Bug: 309686873
Test: atest keystore2_client_tests
Change-Id: I89d71ccfcfe4f8b3495fede40ae26ad6fa2b0118
This cl moves watchdog calls to keystore2 to make rkpd_client
less dependent on keystore2, this allows us to make rkpd_client
an independent library more easily later.
Test: atest keystore2_test
Bug: 241428146
Change-Id: Ic3040ad65356aa7e25d38f36d453a258caf28403
This simplifies the task of creating an independent library of
rkpd_client later.
Test: atest keystore2_test
Bug: 241428146
Change-Id: Idddf37d14580e691fde5a494e54297465cb693b6
This will facilitate the extraction of rkpd_client as a standalone
library later.
Test: atest keystore2_test
Bug: 241428146
Change-Id: Icff6f88f2c3cc3dc50dd126067ed5f10c8aa7b29
This simplifies the task of creating an independent library of
rkpd_client later.
Test: atest keystore2_test
Bug: 241428146
Change-Id: I2834c9be9f5100d52829e6392f0dd48e7c76beb1
Log an informational message when creating each of a user's super keys,
as these are significant events.
Bug: 296464083
Test: atest -p --include-subdirs system/security/keystore2
Flag: exempt, just adds a log message
Change-Id: I9d76a0ec06fae208412f4c6cf1b7dd739b023a61
Currently the UnlockedDeviceRequired super keys are created by
get_or_create_super_key(), while the AfterFirstUnlock super key is
created by separate code in init_user(). The super key creation code in
get_or_create_super_key() is generic enough to work for all super keys,
however. This CL factors this code out into a new function
create_super_key(), which a later CL will use for the AfterFirstUnlock
super key. No change in behavior.
Bug: 296464083
Test: atest -p --include-subdirs system/security/keystore2
Flag: exempt, mechanical refactoring
Change-Id: I88779273efef6cb925152381c07549e1f49daecf
This returns the time (from CLOCK_MONOTONIC_RAW) that the specified user
last authenticated using the given authenticator.
Bug: 303839446
Test: atest keystore2_client_tests
Change-Id: Idd4c477365ffa556b7985d1d926dfa554680ff28
Adding a 'static bound for a binder Interface Implementation.
This is now needed to allow new code used to cast a Binder
Native object back to the original object that implements the
Binder Interface.
Test: CI
Bug: 278780666
Change-Id: Ifa1ec4d4c6692d75ada6c58cb97e6c82b791be04
1. Generate a key with application-data and use the generated key to
create an operation using the same application-data. Test should
create an operation successfully.
2. Generate a key with application-data and use the generated key to
create an operation using different application-data. Test should
fail to create an operation with `INVALID_KEY_BLOB` error code.
3. Generate a key with application-id and use the generated key to
create an operation using the same application-id. Test should
create an operation successfully.
4. Generate a key with application-id and use the generated key to
create an operation using different application-id. Test should
fail to create an operation with `INVALID_KEY_BLOB` error code.
5. Generate an attestation key without app-id and app-data. Test should
generate a new key with specifying app-id, app-data and using
previously generated attestation key. Test should be able to generate
a new key successfully.
6. Generate an attestation key with app-id and app-data. Test should try
to generate an attested key using previously generated attestation
key without specifying same app-id, app-data. Test should fail to
generate a new key with an error code `INVALID_KEY_BLOB`. It is an
oversight of the Keystore API that `APPLICATION_ID` and
`APPLICATION_DATA` tags cannot be provided to generateKey for
an attestation key that was generated with them.
Bug: 279721870
Test: atest keystore2_client_tests
Change-Id: I56fad4806c6d96c5994f4affdd7aa6620b1f1be8
Rename the ScreenLockBound superencryption keys and superencryption type
to UnlockedDeviceRequired. This avoids confusion about what "screen
lock bound" means and makes the terminology consistent with the
UnlockedDeviceRequired key parameter in the API.
Bug: 296464083
Test: atest -p --include-subdirs system/security/keystore2
Test: atest CtsKeystoreTestCases
Flag: exempt, mechanical refactoring and comment changes
Change-Id: I98f7716d05c06f8c6db0f3eb616fb6e780407c2d
Rename the LskfBound superencryption key and superencryption type (also
known as per-boot) to AfterFirstUnlock.
This makes it much clearer what the protection of this key is. This
includes avoiding the misleading use of "LSKF"; the secret that's
actually relevant is the user's synthetic password, which is most
commonly unlocked with the LSKF but can potentially be unlocked in other
ways. This is also helpful for the planned change to make the user's
super keys exist even while the user doesn't have an LSKF.
Bug: 296464083
Test: atest -p --include-subdirs system/security/keystore2
Test: atest CtsKeystoreTestCases
Flag: exempt, mechanical refactoring and comment changes
Change-Id: I9b16934f37222fef2bf01830f521928ef2c1853a
Rename UserState::LskfLocked to UserState::BeforeFirstUnlock, and
rename UserState::LskfUnlocked to UserState::AfterFirstUnlock.
This makes it much clearer what these states are. This includes
avoiding the misleading use of "LSKF"; the secret that's actually
relevant is the user's synthetic password, which is most commonly
unlocked with the LSKF but can potentially be unlocked in other ways.
This is also helpful for the planned change to make the user's super
keys exist even while the user doesn't have an LSKF.
Bug: 296464083
Test: atest -p --include-subdirs system/security/keystore2
Test: atest CtsKeystoreTestCases
Flag: exempt, mechanical refactoring and comment changes
Change-Id: I78f15e2165876951c98e22e577fc4c92a3602b3b
