This reverts commit abbaa445.

Reason for revert: frameworks change should not have gone into 24Q2
(cherry picked from https://android-review.googlesource.com/q/commit:ad79ede464a1d95508e4f7e65a29459c77219814)
Bug: 329008459

Ignore-AOSP-First: reverting incorrect merge into release branch
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:3b5a6bfb75f489033c5601c965a9236fb2a64903)
Merged-In: Ie63b8dfc8bb562b33e6e529d537bde64ae2c6d53
Change-Id: Ie9b5218a707cf3ef8cb34f5fadd68e34683a5b15

Many files that reference android.security.KeyStore don't actually do
anything with it.  This is apparently because the functionality of this
class got moved to other places, but it was forgotten to remove the
actual references to the class.  This CL removes all such references
from frameworks/base.  Where made possible by removing an import of
android.security.KeyStore, it also updates references to
java.security.KeyStore to be simply KeyStore.  java.security.KeyStore is
the real KeyStore that is part of the public API.

Bug: 326508120
Test: presubmit
Change-Id: Ie63b8dfc8bb562b33e6e529d537bde64ae2c6d53

Remove methods from android.security.KeyStore that have no real callers.

The methods with @UnsupportedAppUsage could be called via reflection by
apps targeting an old SDK level.  But since there is no valid use case
for these and they were already replaced with stubs in Android 12,
removing them is allowed by the non-SDK interface policy.

Bug: 326508120
Test: presubmit
Change-Id: Id742604786e71a212244f7800b9c245cea193057

Bug: 296475382
Test: atest CtsKeystoreTestCases:KeyInfoTest
Change-Id: I30cc00ec39dc1552eb2b7c12b0fab41e844c952e

Rename the MGF1 Digest Setter flag to "v2" so it can
be set as a read-only flag.

Test: atest CtsWebkitTestCases:android.webkit.cts.WebViewSslTest#testProceedClientCertRequestKeyWithAndroidKeystoreKey CtsKeystoreTestCases:android.keystore.cts.CipherTest#testKatBasicWithDifferentProviders CtsKeystoreWycheproofTestCases:RsaOaepTest
Bug: 308378912
Bug: 308069562

Change-Id: Id46ffc14f2b02cb51cd7df39f30ea757073a2144

Add a method to get the list of apps that have auth-bound keys bound to
a specific SID.

Bug: 302109605
Test: Manual, installed an app that creates auth-bound keys and observed
      it is included in the list of apps that have auth-bound keys.
      A CtsVerifier is forthcoming.
Change-Id: Id41398bd29e6f80f963b142bb16719761308198e

We add this error for AAID in cases where the call to keystore2
fails. We do not want to fail here because the error could
be transient. We return this error to indicate to the caller that
we should retry this call before failing completly. This stops
attestation from happening without a key and exposing the clients
generating information.

Test: atest CtsKeystoreTestCases
Bug: 291583874
Change-Id: Icd8facd3df38a70e810115a60a2950f85511f4c2

653ac0cd

Change-Id: I4afba276e84a4f535d1cfca8aa7863e463e61880

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.

Test: atest CtsKeystoreTestCases
Bug: 313856313
Change-Id: I529150af4ce70371ba8c279dc91550a12640f109

Revert submission 2517535-curve_25519_validation

Reason for revert: b/322323243

Reverted changes: /q/submissionid:2517535-curve_25519_validation

Change-Id: I75d731672140f827c4574ef1a23851522fa53e92

Added a ED25519 key pair generator algorithm in AndroidKeyStoreProvider.
This will allow user to generate ED25519 key pair using
KeyPairGenerator.

Key pair generator for algorithm XDH (Agree-Key) and ED25519
(Signing-Key) should only allow curve X25519 and curve Ed25519
respectively. This expectation is checked in
AndroidKeyStoreKeyPairGeneratorSpi.

Bug: 223547517
Test: atest CtsKeystoreTestCases:android.keystore.cts.Curve25519Test
Change-Id: Ib664637ffa90eec4fd4605007c53aca584eb3799

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 Keystore changes in
I1b0d9ec4f9e31dc91642e865045766bd17e34cad, 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.

Note: a future CL will take into account the progressive expiration of
unlock methods while the device is locked and upgrade the security of
UnlockedDeviceRequired accordingly.  The present CL focuses just on
choosing the correct protection at lock time, fixing a user-visible bug.

Test: Ran the following automated tests with and without the
      fix_unlocked_device_required_keys_v2 flag enabled:
          atest com.android.server.locksettings \
          && atest TrustManagerServiceTest \
          && atest TrustTests \
          && atest -p --include-subdirs system/security/keystore2 \
          && atest CtsKeystoreTestCases

Test: Manually tested each combination of biometric setup: none,
      fingerprint, face, and fingerprint+face.  Locked the device, then
      verified via logcat that Keystore protected the
      UnlockedDeviceRequired keys in the expected way, then verified
      that UnlockedDeviceRequired keys cannot be used (even in the case
      where the super keys were not protected).  Unlocked device using
      weakest method available, then verified that
      UnlockedDeviceRequired keys can be used.  To check whether
      UnlockedDeviceRequired keys can be used or not, used the CTS
      method mentioned in the Test of https://r.android.com/2878769.

      Also, enabled Extend Unlock with a bluetooth device, and verified
      that it's not counted as an unlock method.

      Also, verified that if Lockdown mode is triggered, the
      UnlockedDeviceRequired keys are fully protected.

Bug: 296464083
Change-Id: I34dc49f1338e94755e96c1cf84de0638dc70d311

This reverts commit 468c8fe6.
Additionally, this adds a guard for reading the flag: If
the calling app does not have the right permission to read the device
configuration, the code will assume it is not set.

Reason for revert: Fixed flag reading code

Bug: 314744703
Test: atest CtsWebkitTestCases:android.webkit.cts.WebViewSslTest#testProceedClientCertRequestKeyWithAndroidKeystoreKey
Change-Id: I29c58bc8c5960c0ab9af70f93440bd9a1db12dc7

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 actual change in behavior intended.  This change does
make TrustManagerService no longer call getBiometricSids() for unlocks,
so technically that is a slight difference; however, for UNLOCK events
Keystore ignored the SID list, so this just eliminates unnecessary work.

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: Ibfaa22ba27d13248c9c4c69a4d2efb2231792c31

This reverts commit e0c8ad86.

Reason for revert: 314140771

Change-Id: Ied1f3042aee8ac8642237a4cdcfa75be7a02e7e8

In case the MGF1 Digest setter flag is turned off (that is, it is not
possible to specify MGF1 Digests using the new API introduced), then the
old behaviour has to take place.

The old behaviour was to set all primary digests specified, as MGF1 Digests.
This behaviour has been added when the flag isn't set.

Bug: 308378912
Bug: 308069562
Test: atest CtsKeystoreTestCases:android.keystore.cts.CipherTest#testKatBasicWithDifferentProviders CtsKeystoreWycheproofTestCases:RsaOaepTest
Change-Id: I5d4541ce952e1bad7c8fdd55a00176274b0b66f3

When the keystore service is not available or
not initialized we do not want to crash the service.
So we throw and Exception that KeystoreService
is not availble when it should be possibly in an
incorrect state.

Test: atest CtsKeystoreTestCases
Bug: 304758094
Change-Id: If73856deb27b9f11a9b77f0ba32c3b4037332759

The MGF1 Digest setter should not accept a null vararg. It should not
take in null at all.

Bug: 302280420
Test: m
Change-Id: I9db395d09e2fd0e609cd9019f3d3aedbb3244ef3

The security improvements to Keystore's UnlockedDeviceRequired key
protection in Android 12 regressed its behavior by making it no longer
work for unsecured users, e.g. users with a Swipe lock screen.  One of
the things that broke it is that Keystore started superencrypting
UnlockedDeviceRequired keys, yet Keystore unnecessarily ties
superencryption to the existence of the user's LSKF.  That is, Keystore
creates a user's super keys only when an LSKF is set, and Keystore
deletes all super keys and superencrypted keys when the LSKF is removed.

To fix this, we're first making each user's Keystore super keys have the
same lifetime as the user's synthetic password (and always be encrypted
by it), which is very similar to how the CE storage key works starting
in Android 14.  Second, when a user's LSKF is removed, we're making
Keystore delete *only* the user's auth-bound keys.

This change implements the LockSettingsService side of the fix.  This
includes the following parts:

- When initializing a user's synthetic password, LockSettingsService now
  initializes the user's Keystore super keys.

- When upgrading to a build including this fix, LockSettingsService now
  does a one-time migration where it initializes the super keys for
  unsecured users.  This is necessary to handle existing users.

- When removing a user's LSKF, LockSettingsService now calls the new
  onUserLskfRemoved method of Keystore to delete auth-bound keys only.

- Finally, when an unsecured user's CE storage is unlocked,
  LockSettingsService now unlocks the user's Keystore super keys too.

Due to trunk-stable, these changes are actually behind a flag for now.

Bug: 296464083
Test: see If12824369fbad4a90e5cd0427e792655fd233b96
Change-Id: Ib92a439c2c27cef54c28189dfb5beef68756528e

KeyMint handles challenges up to 128 bytes. Document this in the
KeyGenParameterSpec Builder.

Bug: 307714384
Test: m
Change-Id: Ib2082edd12828649225c42de56e176540e997467

This obtains the time (via SystemClock.elapsedRealtime()) when the
user last authenticated using any of the passed authenticators.

Test: manual, atest AuthServiceTest, CTS
Bug: 303839446
Change-Id: Id22bee7b05271ce38816f932b3696cb450ab025d

Various issues here, but the most recurring one is referencing SystemApi
from public javadoc. Remove or rewrite such references.

Also common is trying to @link IntDefs. Usually this is not necessary,
as the presence of IntDef in the @param/@return auto-generates relevant
documentation.

Bug: 303184203
Test: m docs
Change-Id: Ie59e61881c45c73fbbe08250493bd35eca268ef6

Remove AndroidKeyStoreMaintenance#getState() and both overloads of
KeyStore#state().  None of these are used by platform code anymore.

The two KeyStore#state() methods do have @UnsupportedAppUsage, as do two
values of the State enum: UNLOCKED and LOCKED.  However, there is a
clear public API equivalent for apps that may be checking these states:
UserManager#isUserUnlocked().  Therefore, according to the policy on
unsupported usage of internal APIs, we can remove these internal APIs.

Also, the non-SDK dashboard has no runtime results for either method,
and only one static analysis result which is from unused code in one
app.  This is consistent with these methods being entirely unused.

Part of the motivation for removing these internal APIs is that upcoming
changes to the lifetime of keystore superencryption keys would change
the behavior of getState.  So it seems like a good time to remove this
unused/unsupported code instead of wasting time maintaining it.

Bug: 296464083
Test: atest -p --include-subdirs system/security/keystore2
Change-Id: Iff821bbdeac5ee0653c9c71867fd53d38cb4d48f

Test: m
Change-Id: I4a9fe5ff53ce3a7eaf02011df2d19b17111b7b8b

Test: N/A
Change-Id: I1154d866611a744a34631a9bc129419b1e9f99e6

Making changes to use aidl_interface build system in
KeyAttestationApplicationProvider to support Rust, CPP and Java
backends.
Defined AAID interface and its parcelables using AIDL types.
Removed custom parcelables defined for AAID.

Bug: 267452060
Test: atest android.keystore.cts.KeyAttestationTest
Change-Id: Iec558642867c13e2998d7f69f00b3f1adf4e2b62

Android 13 / T / API 33 introduced a new class in Crypto Object
in the Android Framework. This allows auth-per-op for ECDH
keys.

Bug: 282058146
Test: atest FrameworksCoreTests
API-Coverage-Bug: 282058146
Change-Id: I17877fed90ae0b3894b28967c28786a091557dd2

Add a separate setter for the digests used by the MGF1 mask generation
function (for RSA OAEP operations).

Previously the MGF1 digests were specified according to the primary
digests specification, which is not accurate enough.

With the new setter:
* If the user does not explicitly specify MGF1 digests, then the
  default (SHA-1) will be specified in the tag passed to Keystore.
* If the user does explicitly specify MGF1 digests, only those
  digests will be specified in the tag passed to Keystore.
  The SHA-1 digest will not be added.

Bug: 284140060
Test: atest android.security.keystore.KeyGenParameterSpecTest android.security.ParcelableKeyGenParameterSpecTest
Test: atest CtsKeystoreTestCases:android.keystore.cts.CipherTest#testKatBasicWithDifferentProviders
Change-Id: I1521e9b4399ece33c2d17b79133543d490d3b377

Test: m
Change-Id: I9a0c7b5e912b882a1815afb1eddc02f7cb7872c5

This has strictmode annotations for when calls are
made into Keystore DB to make reads or writes.

Test: atest CtsKeystoreTestCases
Bug: 180135124
Change-Id: I819e1c63875a4af16a6fbe991a9f7c9c95ea8e6a

See https://source.android.com/setup/contribute/respectful-code for reference

For this round, the fixes are only applied to the following to minimize breaking dependencies:
  * comments (excluding javaDoc annotations)
	* private constants
	* private functions
	* parameters within functions

BYPASS_INCLUSIVE_LANGUAGE_REASON=Just updating a few select inclusive language violations.
No-Typo-Check: Changes focused on inclusive language violations.
BUG: 295342157
Change-Id: I70dcadc67c13c34edda553897847249e92c26239

Deduplicate the addition of the SIDs and USER_AUTH_TYPE, and consolidate
the handling of isUserAuthenticationValidWhileOnBody() into one place.
No change in behavior.

Test: atest KeystoreTests
Change-Id: Ic57e3506a62d90ee0fd7b5860d4cda44aa1b5acf

- Make core/java/android/security/keystore/OWNERS include
  keystore/OWNERS instead of duplicating it

- Make core/tests/coretests/src/android/security/keystore/ owned by
  keystore/OWNERS instead of no one

- Make core/java/android/security/Confirmation*.java owned by
  keystore/OWNERS instead of an individual person

- Remove core/java/android/security/keystore/recovery/OWNERS, as it was
  redundant with OWNERS of its parent directory

- Remove Xoogler jdanis@

Change-Id: I64c1c624dcc92fbf20a6d4fb667cf47240edf4d5

SecureKeyImport is failed because of MGF_DIGEST tag mismatch.
wrapping key has MGF_DIGEST tag when generate or import key
but importWrappedKey logic does not have MGF_DIGEST tag on WrappedKeyEntry
So MGF_DIGEST tat mismatch error occur when decrypt wrapped key using wrapping key

Insert SHA-1 value on MGF_DIGEST tag because ImportWrappedKey should have spcified format
that keymint is compulsorily checking main digest SHA-256 and MGF digest SHA-1.

And MGF_DIGEST tag will add only wrappingkey has MGF_DIGEST value
in order not to affect keys generated prior to Android14.

Bug: 277853193
Test: android.keystore.cts.ImportWrappedKeyTest#testKeyStore_ImportWrappedKey
Change-Id: Id7229a763e3041ffbe73989a2bb24306b7beb7a5
Signed-off-by: Jaeyoon Lee <joyful.lee@samsung.corp-partner.google.com>

This reverts commit dde5ebaa.

Reason for revert: Will re-introduce http://b/278157584

Even though KeyMint v2 supports the MGF_DIGEST tag, it does not include it in the key characteristics. This would not be a problem for keys generated on an Android U device with KeyMint v2 but it will be a problem on a device that was upgraded to Android U where keys were generated before the upgrade (so the MGF_DIGEST tag was not added).
Because we have no way of knowing if the MGF_DIGEST tag was specified when the key was created on KeyMint implementations older than v3, we should not add the tag on begin().

Change-Id: I7b34799b95eb2ff054ec4d090ccbd93e6442dcfe

Mixed build of Android T + U GSI misses to add RSA_OAEP_MGF_DIGEST in
key begin operation parameters and hence RSA cipher operation fails.
This was due to Keymint 200 implementation in Android T supported
RSA_OAEP_MGF_DIGEST tag but did not included into key characteristics and
the check in AndroidKeyStoreRSACipherSpi fails on Android T + U GSI
builds.

To fix this issue additional condition added to check if key
characteristics do not have RSA_OAEP_MGF_DIGEST tag but the KeyMint
version is 200 then it has to include in operation parameters.

Bug: 289859292
Bug: 289749312
Bug: 287891167
Bug: 287532460
Test: atest  CtsKeystoreWycheproofTestCases:com.google.security.wycheproof.RsaOaepTest
Test: atest CtsKeystoreTestCases:android.keystore.cts.CipherTest#testKatBasicWithDifferentProviders
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:d8b18413ade6ba13817caae52abdffc609a92d89)
Merged-In: I13ca50a45e733276d1451d17904780eff86bf296
Change-Id: I13ca50a45e733276d1451d17904780eff86bf296

When a key requires user authentication and one of the authentication
methods permitted is the device's screen lock credentials, the
root SID is added as an authenticator, and change of biometrics
enrollment will not invalidate the key.

Bug: 275900161
Test: m docs
Change-Id: I180f28883a5ac62e8bfa0b0596396085ff676637

If a key does not have the MGF_DIGEST tag in its key characteristics,
do not include the MGF_DIGEST tag for it (even if the algorithm string
specifies it).

This fixes an issue with keys that were generated on Android 13, where
the MGF_DIGEST tag was not propagated from the SPI layer. Such keys will
not have the MGF_DIGEST tag and so it will not be added by the SPI layer
even if the algorithm string specifies it. This maintains Android 13's
(incorrect) behaviour of ignoring the MGF Digest specification, but is
necessary to use those keys (otherwise KeyMint will error out
on begin() due to an incompatible MGF digest specification).

Bug: 278157584
Test: atest CtsKeystoreWycheproofTestCases:com.google.security.wycheproof.RsaOaepTest
Merged-In: I0f1fa7983f9c771bec3196c6a617eb7044ac2e79
Change-Id: I6a4c15ca04aa78c2191d47394811ba9338ee7f0b

If a key does not have the MGF_DIGEST tag in its key characteristics,
do not include the MGF_DIGEST tag for it (even if the algorithm string
specifies it).

This fixes an issue with keys that were generated on Android 13, where
the MGF_DIGEST tag was not propagated from the SPI layer. Such keys will
not have the MGF_DIGEST tag and so it will not be added by the SPI layer
even if the algorithm string specifies it. This maintains Android 13's
(incorrect) behaviour of ignoring the MGF Digest specification, but is
necessary to use those keys (otherwise KeyMint will error out
on begin() due to an incompatible MGF digest specification).

Bug: 278157584
Test: atest CtsKeystoreWycheproofTestCases:com.google.security.wycheproof.RsaOaepTest
(cherry picked from https://android-review.googlesource.com/q/commit:05d046390769a8ba6f113ea6b191d9addf183627)
Merged-In: I0f1fa7983f9c771bec3196c6a617eb7044ac2e79
Change-Id: I0f1fa7983f9c771bec3196c6a617eb7044ac2e79

All error codes defined in ErrorCode.aidl file are expected to be
mapped in KeymasterDefs.java file, excluding -62 which is handled by
Keystore and not required to define on Jaya layer.
So missing error codes from KeymasterDefs are added and also categorized
in KeyStoreException class.

Bug: 206432492
Test: atest CtsKeystoreTestCases:android.keystore.cts.KeyStoreExceptionTest
Change-Id: I9df69e03379d0437457037e16de76feb27ea8aaf