Correct the permission check for the Keystore maintenance method
that returns the list of app UIDs which have keys that are
bound to a specific SID.
The previous check relied on SELinux policies. But the Settings
app that calls this method has a permission - MANAGE_USERS -
that is more appropriate to check.
Bug: 302109605
Test: Manual.
Change-Id: Ia26256cf995d16d03d0bb92d8b237f7bbea30d07
This is needed to upgrade the android_logger crate from 0.12.0
to 0.13.3.
with_max_level provides the same functionality as with_min_level.
The renaming is admittedly confusing, but the new name is accurate
and it makes sense that they deprecated and then removed the
previously poorly named with_min_level.
See crate documentation [1] and code [2].
[1]: https://docs.rs/android_logger/0.12.0/android_logger/struct.Config.html#method.with_min_level
[2]: https://docs.rs/android_logger/0.12.0/src/android_logger/lib.rs.html#227
Bug: 322718401
Test: build and run CF with the change.
Test: m aosp_cf_x86_64_phone
Change-Id: I8d9d7c42100ede48496f9846068ed312fb8a15cb
Android Protected Confirmation is deprecated due to the high
support/maintenance cost for Android device makers and low adoption rate
among app developers. APC requires Android device makers to have a
substantial amount of device-specific UI code running in the trusted
execution environment. That has proven to be expensive to maintain and
non-scalable, as there cannot be a single implementations device makers
can share or use as a reference. Additionally, app developers have not
adopted this feature, as the Android platform offers other mechanisms
for authentication a user's intent. These mechanisms, such as
authentication-bound Keystore keys, are less secure than Trusted UI, but
are more wide-spread. While we explore alternatives to APC that are
viable to the device makers ecosystem, we sunset the APC API.
Bug: 313856313
Test: atest keystore2_test && atest CtsKeystoreTestCases
Change-Id: If065697ed13e3de706b8dde5cc5e2b6018592018
Add a method to the Keystore maintenance interface to list the UIDs of
apps that are affected by a given secure user ID.
With this method, it would be possible to tell if removing a given
user's LSKF or enrolling new biometrics will invalidate Keystore keys,
thus affecting some apps.
Bug: 302109605
Test: atest keystore2_test
Change-Id: If5888506e0c72a56eca3339778889c7d8038acc5
Starting in Android 12, unlocking the device with a class 1
("convenience") biometric, class 2 ("weak") biometric, or a trust agent
unexpectedly doesn't allow the use of UnlockedDeviceRequired keys. The
cause of this bug is that the cryptographic protection that Keystore now
applies to UnlockedDeviceRequired keys incorrectly assumes that the
device can only be unlocked using LSKF or via a biometric that
participates in Keystore (has a SID and uses HardwareAuthTokens).
Actually, Keyguard also allows the device to be unlocked using weaker
biometrics that do not particiate in Keystore, if they are enrolled.
Similarly, there are also cases where a trust agent can actively unlock
the device, e.g. unlocking a phone using a paired watch.
In combination with the system_server changes in
I34dc49f1338e94755e96c1cf84de0638dc70d311, this CL fixes the bug by
making Keystore retain the UnlockedDeviceRequired super keys in memory
if a weak unlock method is enabled at device lock time. This does mean
that UnlockedDeviceRequired is enforced only logically when a weak
unlock method is enabled, but this is the best we can do in this case.
This CL also adds methods by which Keystore can be notified of the
expiration of unlock methods, causing the security level of
UnlockedDeviceRequired keys to be upgraded. A future CL for
system_server is planned to use these.
Test: see I34dc49f1338e94755e96c1cf84de0638dc70d311
Bug: 296464083
Change-Id: I1b0d9ec4f9e31dc91642e865045766bd17e34cad
Since there's now a case where AES_gcm_decrypt() is expected to fail
(trying to use HKDF-derived key to decrypt an old super key that's
encrypted by an PBKDF2-derived key, before falling back to PBKDF2),
remove the corresponding error message from the C++ function. The error
message is misleading in this case. In other cases, the error message
does not provide useful information since it seems to be the only way
that AES_gcm_decrypt() can actually fail (seeing as the length mismatch
should never happen), and the caller uses the boolean return value to
create the real Rust error which is then logged/handled appropriately.
Bug: 296464083
Bug: 314391626
Test: Verified that on device that has old super keys, the
"Failed to decrypt blob" message is no longer logged.
Change-Id: I1a85572626d90b74aa3ccd31bd112d7b06fbe028
Since the Keystore password is a high-entropy synthetic password, key
stretching is not required. Therefore, improve the performance of
encrypting and decrypting Keystore user super keys by using HKDF instead
of 8192-iteration PBKDF2. PBKDF2 continues to be used for decrypting
old keys, when AES-GCM decryption using the HKDF-derived key fails.
Bug: 296464083
Bug: 314391626
Test: atest -p --include-subdirs system/security/keystore2
Test: Upgraded a device and verified the old super keys can still be
decrypted.
Test: Verified via logcat that super key creation got faster.
Change-Id: Ib7976671ecf886e6308b66e6b1fdfb4b21346afb
Rename Password::derive_key() to Password::derive_key_pbkdf2(), and
rename generateKeyFromPassword() to PBKDF2(). This helps distinguish
these functions from the HKDF functions, including the existing ones as
well as the Password::derive_key_hkdf() added by the next CL.
Bug: 296464083
Bug: 314391626
Test: atest -p --include-subdirs system/security/keystore2
Change-Id: I76e5ee5a5c6452951727be6fce1a43a2322a3950
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
