Bug: 343627215
Test: None, comment change only
Change-Id: I362e30991ca951670ae29e9a1d9b51cf31c2ef71

Revert submission 2864688-apc-deprecate

Reason for revert: fix inadvertent partial deprecation

Reverted changes: /q/submissionid:2864688-apc-deprecate

Change-Id: I820e2916acfc711c6a092ac1371548f54fd170af

Since android.security.KeyStore is no longer used, remove it.  This
prevents this class, which had a name that made it sound much more
important than it actually is, from being confused with the classes via
which the Android Keystore is actually accessed these days.

Bug: 326508120
Test: build
Flag: NONE mechanical refactoring with no behavior change
Change-Id: I2f8471971b2816a4a830a48cb99ff118c21a6ad8

To make it possible to remove the obsolete and misleadingly named helper
class android.security.KeyStore, the UID_SELF constant will be moved to
KeyProperties.  This CL completes the first half of the move by adding
the constant to the new location.  A later CL will delete the constant
from the old location once all users have been updated.

Bug: 326508120
Test: build
Flag: NONE mechanical refactoring with no behavior change
Change-Id: I5aa839a19d548d9d5a86afc30ab39431c0b93aa5

This method no longer has any callers, so remove it.

(As with other methods in android.security.KeyStore, this did have
@UnsupportedAppUsage.  However, there is no reason for apps to use this.
Therefore, removing it is allowed by the non-SDK interface policy.)

Bug: 326508120
Test: Build
Change-Id: I76facc1d54bf656188d1d4c5745224fc49836132

Adds deleteSecrets() to RecoverySystemService. This method is called
from rebootRecoveryWithCommand () before the --wipe_data command is
passed to recovery and the device is force-rebooted.

deleteSecerts() calls IKeystoreMaintenance.deleteAllKeys() in order to
quickly destroy the keys protecting the synthetic password blobs
used to derive FBE encryption keys.

The intent is to make FBE-encrypted data unrecoverable even if the full
data wipe in recovery is interrupted or skipped.

Bug: 324321147
Test: Manual - System -> Reset options -> Erase all data.
Test: Hold VolDown key to interrupt reboot and stop at bootloader
screen.
Test: fastboot oem bcd wipe command && fastboot oem bcd wipe recovery
Test: fastboot reboot
Test: Device reboots into recovery and prompts to factory reset:
Test: 'Cannot load Android system. Your data may be corrupt. ...'

Change-Id: I5eb8e97f3ae1a18d5e7e7c2c7eca048ebff3440a

Currently the IKeystoreAuthorization service is intended to be accessed
through the helper class android.security.Authorization.  However,
because Authorization provides only static methods, it can only be
unit-tested by static mocking, which is only available in
mockingservicestests.  BiometricService works around this in two
different ways: (a) using IKeystoreAuthorization directly, and (b) using
android.security.KeyStore, which is an obsolete class which is now
almost empty and just contains a couple random helpers.  I'd like to
remove it to avoid confusion with java.security.KeyStore.

This CL solves the testability problem in a consistent way by renaming
Authorization to KeyStoreAuthorization and changing all public static
methods to instance methods.  It updates all callers of the keystore
authorization service to go through a KeyStoreAuthorization instance.
Finally, it updates the unit tests for TrustManagerService and
BiometricService to inject a mock KeyStoreAuthorization.

Bug: 326508120
Test: atest TrustManagerServiceTest
Test: atest FrameworksServicesTests:{BiometricServiceTest,AuthSessionTest}
Test: atest CtsBiometricsTestCases:BiometricSimpleTests
Flag: N/A.  Refactoring with no behavior change intended.
Change-Id: I68504f447b1b880c08a60cf027b13f77a6567ec9

There's no such thing as a NO_ERROR Keystore error code anymore, let
alone one whose numeric value is 1.  The field
android.security.KeyStore.NO_ERROR is a remnant from Keystore1.
NO_ERROR existed in Keystore1 because Keystore1's binder methods used a
binder exception code of 0 ("success") even on failure, so they had to
use the return value to convey a Keystore error code or NO_ERROR.
Keystore2 instead uses binder's support for service-specific errors, and
there is no NO_ERROR error code because the success case is conveyed via
the binder exception code being 0 instead of EX_SERVICE_SPECIFIC.

Therefore, this CL removes the obsolete field
android.security.KeyStore.NO_ERROR and its two users.  These users were:

- AndroidKeyStoreCipherSpiBase checked for NO_ERROR "errors" from
  createOperation().  But this case is unreachable, and the operation
  cannot continue without the CreateOperationResponse anyway.  So this
  obsolete code can just be removed.

- AuthenticationClient checked the return value of
  KeyStore#addAuthToken() against NO_ERROR.  But this method actually
  just wraps Authorization#addAuthToken() which returns 0 on success, as
  per its javadoc.  So this was a bug, though it didn't matter much
  since it just caused a misleading log message.  Check for 0 instead.

Finally, NO_ERROR did have @UnsupportedAppUsage.  But since there's no
use case for it, removing it is allowed by the non-SDK interface policy.

Bug: 326508120
Test: atest CtsKeystoreTestCases
Change-Id: I735e005d7ca39e231667dd95da533519085ba4ef

Bug: 277946433
Test: 'm offline-sdk-docs' and view in web browser
Change-Id: I40b7811963169da5195a482088bf18d9d70db010

Remove KeyStore#onDeviceOffBody(), since its only caller was removed by
http://ag/24518980.  Also remove
AndroidKeyStoreMaintenance#onDeviceOffBody() which was only called by
KeyStore#onDeviceOffBody().

Bug: 289849354
Test: Build
Change-Id: I3db2672b8038e947a974f703aa2c273ecb65414e

Bug: 289849354
Test: Build
Change-Id: I8e61eb8c9b0ef94c70ce797497b472e2985973d6

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