Some issues require a system error to be raised that
indicates we should retry the process. This adds a new
error and bumps the version of the api for future use.
Test: atest keystore2_test
Bug: 238619180
Change-Id: Iff8fa83f7b223e08de9fa31434e16aa3aa2153f6
avoid issues while linking shared libraries with Rust test binaries.
This change is made to avoid vts-tradefed failure to link the shared
library while running the Rust VTS `keystore2_client_tests` test
suite. As suggested in b/314110490#24 using the libkeystore-engine
static-library to run keystore2_client_tests.
Bug: 314110490, 298668920
Test: atest keystore2_client_tests; run vts -m keystore2_client_tests
Change-Id: If956865eeb4af908f33b1ad81a2b2e26300aae0e
When a database is set once it will still maintain that
setting even if on the next connection it is not specified.
Any databases that set the wal flag will need to turn the
database back to its default when the flag is disabled or
there will be an error in the access of the database.
Bug: 314419678
Test: atest keystore2_test && atest legacykeystore_test
Change-Id: I008f2d2f6ac055704b721cdd451fc8bdfe448832
compile_multilib set to first.
To avoid missing dependent library (libkeymaster_portable.so) error,
enforcing to compile for 64-bit on a 64-bit platform, and 32-bit on
a 32-bit platform.
Bug: 314110490
Test: run vts -m keystore2_client_tests
Change-Id: I5e8bf94ed37209f69ace2d7dd2c0ca1b680fc86d
By default Android only allows processes to lock up to 65536 bytes of
memory, resulting from the command 'setrlimit memlock 65536 65536' in
system/core/rootdir/init.rc. The recent Keystore changes to create each
user's super keys at user creation time cause Keystore to sometimes lock
more memory and sometimes exceed this limit. To reproduce this issue
myself, I had to create almost 100 users. However, it apparently can
happen with fewer users too, based on CTS test failure report.
Fix this issue by setting the memlock limit for keystore2 to unlimited.
Note that the amount actually used remains fairly small, but I don't
think there's a reason to set an arbitrary limit here. A memlock limit
makes sense for unprivileged apps but not for system processes.
Bug: 296464083
Bug: 314474709
Bug: 314561033
Test: adb shell setprop debug.user.creation_override 1
for i in `seq 1 100`; do adb shell pm create-user --profileOf 0 --managed profile; done
adb logcat | grep -i keystore
# Saw ENOMEM error near the end without this CL, but not with it.
Flag: Not feasible to flag this CL, and it's a pretty safe change.
Change-Id: I3ef062d737ffb1431dca78c0d568ad6c2d713de6
Currently Keystore is notified of the device being unlocked and locked
for each user via onLockScreenEvent(lockScreenEvent, userId, password,
unlockingSids), where lockScreenEvent is UNLOCK or LOCK. This is a bit
confusing because the password parameter is only meaningful for UNLOCK,
and the unlockingSids parameter is only meaningful for LOCK. This
problem will get worse when we add a parameter that tells Keystore
whether unlocking via a weak biometric or trust agent is possible, as
that will be another parameter that is only meaningful for LOCK.
Therefore, this CL splits onLockScreenEvent into two methods
onDeviceUnlocked and onDeviceLocked, each with the appropriate
parameters. No change in behavior intended.
Bug: 296464083
Test: atest -p --include-subdirs system/security/keystore2 \
&& atest CtsKeystoreTestCases \
&& atest TrustTests \
&& atest com.android.server.locksettings
Flag: N/A, straightforward refactoring
Change-Id: Ie2afd118bddca6112a5469558569c63b68ee10fb
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
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
