With the move to rkpd, we no longer need to make calls from framework
into the remote provisioner to tell it that a key was consumed.

Bug: 274823784
Test: atest KeystoreTests
Test: atest CtsKeystoreTestCases:android.keystore.cts.KeyAttestationTest
Change-Id: I510d471a980c62e5798e459729f73c231321d2a9

Make class final.
Add @NonNull annotation to ctor param

Fixes: 262381995
Test: atest android.security.identity.cts
Change-Id: Icae24f120090ec03e532ffdf139513a1cb852c80

This change adds support for specifying that an AuthKey should be
replaced if it's going to expire within a certain amount of time
configurable by the application. This also adds a way for the
application to learn about the expiration time of currently configured
AuthKeys.

Combined these two changes allow an application to get a perfect
picture of which AuthKeys are available, when they expire, and allows
the application to refresh AuthKeys well ahead of expiration dates.

Also remove wrong comment that storeStaticAuthenticationDate() variant
taking an expiration is only available in feature version 202101. It's
available on all feature versions.

Bug: 241912421
Test: atest VtsHalIdentityTargetTest
Test: atest android.security.identity.cts
Change-Id: Ib79da64abfa25b37ed73a37ce78fedd4ef7d1ece

This adds a new method which allows applications to use mdoc ECDSA
authentication instead of mdoc MAC authentication. Additionally, also
relax requirements on SessionTranscript so the APIs can be used even
when mdoc session encryption isn't being used.

Bug: 241912421
Test: atest VtsHalIdentityTargetTest
Test: atest android.security.identity.cts

Change-Id: I25336f1352102208887531d066ec432a9ae3cd36

This is a semi-automatic change.
See https://errorprone.info/bugpattern/JdkObsolete for the rationale.

Test: make
Bug: 221046110
Change-Id: I84591e3963b54e69570e77354e54027e17f17293
Merged-In: I84591e3963b54e69570e77354e54027e17f17293

Properly encode an P-256 EC Public Key in uncompressed form, in
particular ensure that the resulting blob is always 65 bytes long as
is expected.

Was able to reproduce this with about 4% failures running a
test. After the fix didn't get a failure in 1,000 runs.

Also remove unused Util.integerCollectionToArray() function.

Bug: 239857653
Test: atest --rerun-until-failure 1000  android.security.identity.cts.ProvisioningTest#testProvisionAndRetrieveMultipleTime
Change-Id: I9a8a5570fde5a80f74632606126cdfcc1f6c7c99
(cherry picked from commit dc379a45)
Merged-In: I9a8a5570fde5a80f74632606126cdfcc1f6c7c99

Properly encode an P-256 EC Public Key in uncompressed form, in
particular ensure that the resulting blob is always 65 bytes long as
is expected.

Was able to reproduce this with about 4% failures running a
test. After the fix didn't get a failure in 1,000 runs.

Also remove unused Util.integerCollectionToArray() function.

Bug: 239857653
Test: atest --rerun-until-failure 1000  android.security.identity.cts.ProvisioningTest#testProvisionAndRetrieveMultipleTime
Change-Id: I9a8a5570fde5a80f74632606126cdfcc1f6c7c99

Every time we create a credential, contact the Provisioner app and tell
it that a key was generated. This may not strictly be true, but the
provisioner has heuristics to ensure that it only contacts the backend
if necessary. So, at most, we're spinning a few extra cycles whenever
a new credential is created (which is a rare occurence) to ensure that
we have RKP keys available for future requests.

Test: CtsIdentityTestCases
Fixes: 224771551
Change-Id: I6dd20635e6933842a95242e6d0cbfb9bf8c8f734

Bug: 216319624
Test: Compiles
Change-Id: I9e80506cae4799c19f6ea21dc4f2b75981f1ab9d

This is a semi-automatic change.
See https://errorprone.info/bugpattern/JdkObsolete for the rationale.

Test: make
Bug: 221046110
Change-Id: I84591e3963b54e69570e77354e54027e17f17293

Bug: 216177025
Test: atest CtsIdentityTestCases
Change-Id: I507ab6b9ecd095ec53caaf859b236a8fdc7bfce9

This new PresentationSession interface enables an application to do a
multi-document presentation, something which isn't possible with the
existing API. As a practical example of this consider presenting both
your Mobile Driving License and your Vaccination Certificate in a single
transaction.

Also update the documentation for IdentityCredential to clarify that
the same AuthKey is used for multiple getEntries() calls on the same
credential.

Also deprecate existing IdentityCredential.getEntries() method and
related methods and classes.

Bug: 197965513
Test: New CTS tests and new screen in CtsVerifier
Change-Id: I74534969143882552407917a82f44d43da12711c

"byt" -> "but"
"readerAuth" -> "readerSignature"

Test: N/A
Change-Id: Ie8e8c4fa4479d3694871fe00bb0d99698fa05966

Added SPDX-license-identifier-Apache-2.0 to:
  drm/java/Android.bp
  graphics/java/Android.bp
  identity/Android.bp
  identity/java/Android.bp
  keystore/java/Android.bp
  location/java/Android.bp
  location/tests/Android.bp
  lowpan/java/Android.bp
  media/mca/effect/java/Android.bp
  media/mca/filterfw/java/Android.bp
  media/mca/filterpacks/java/Android.bp
  mime/java/Android.bp
  mms/java/Android.bp
  opengl/java/Android.bp
  rs/java/Android.bp
  sax/java/Android.bp
  services/tests/servicestests/test-apps/PackageParsingTestManifests/Android.bp
  telecomm/java/Android.bp
  telephony/common/Android.bp
  tests/FlickerTests/test-apps/Android.bp

Added SPDX-license-identifier-Apache-2.0 SPDX-license-identifier-BSD to:
  telephony/java/Android.bp

Bug: 68860345
Bug: 151177513
Bug: 151953481

Test: m all

Exempt-From-Owner-Approval: janitorial work
Change-Id: I2ee0af9ce8f74de2172b359b41d2c52a8b8f7e6c

All the java code used to build the framework jar and run metalava
was previously defined in the toplevel Android.bp files. Move these
into the subdirs where the source actually lives.

This simplifies the rules themselves (no path and needless prefix) and
declutters the top level Android.bp.

Test: m
Change-Id: I97086e309eacb879d16facb8497d9940fa5ddaf6

Bug: None
Test: N/A
Change-Id: I0b0cfc16a87f94f66f3b96220bb266deef63b2ef

- Add PackageManager system features (with versions) for the normal
  and direct access store
- Deprecate IdentityCredentialStore.deleteCredentialByName() and add
  IdentityCredential.delete() as a replacement.
- Add IdentityCredential.proveOwnership()
- Add IdentityCredential.update()
- Add docs for ProofOfBinding CBOR in X.509 extension of certificate
  for AuthenticationKey
- Add IdentityCredential.setAllowUsingExpiredKeys()
- Add version of IdentityCredential.storeStaticAuthenticationData()
  which takes a an expiration date. Deprecate the old variant of
  this method.

Bug: 170146643
Test: atest android.security.identity.cts
Change-Id: I39a0ed65ed6efaa424ada7a9495e3b1da67cf452

Implement Enrollment-Specific ID, which is calculated using fixed device
identifiers, as well as the provisioning package and the Organization
Identifier set by the Device Policy Controller.

Test: atest FrameworksServicesTests:EnterpriseSpecificIdCalculatorTest
Test: atest com.android.cts.devicepolicy.MixedDeviceOwnerTest#testEnrollmentSpecificIdCorrectCalculation com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testEnrollmentSpecificIdCorrectCalculation com.android.cts.devicepolicy.MixedDeviceOwnerTest#testEnrollmentSpecificIdEmptyAndMultipleSet com.android.cts.devicepolicy.MixedManagedProfileOwnerTest#testEnrollmentSpecificIdEmptyAndMultipleSet
Bug: 168627890
Change-Id: I8b24efa6b8c82d6181f2b20bc8880ddeb6caa4c5

Key derivation for session encryption and MACing now involves mixing
in SessionTranscriptBytes. Update docs to reflect this.

Also, the standard changed such that instead of DeviceAuthentication
being MACed or signed, it's instead DeviceAuthenticationBytes which is
defined as #6.24(bstr .cbor DeviceAuthentication). The same also for
ReaderAuthentication, now ReaderAuthenticationBytes is the CBOR which
is signed by the reader.

Also make a note that the encryptMessageToReader() and
decryptMessageFromReader() should NOT be used and applications should
instead implement these themselves. This is because we don't have the
SessionTranscript available and it's way too late to start adding
public API now. For the next Android version these methods will be
deprecated. Realistically this shouldn't be a problem because
applications are expected to use the Jetpack anyway.

Bug: 159482543
Test: atest android.security.identity.cts
Merged-In: I380a973a0cc78f1206fd7a33d0bd4896a0b16c6d
Change-Id: I8b2931b4f44a398bcbeb753fafa91a509cf68780

Key derivation for session encryption and MACing now involves mixing
in SessionTranscriptBytes. Update docs to reflect this.

Also, the standard changed such that instead of DeviceAuthentication
being MACed or signed, it's instead DeviceAuthenticationBytes which is
defined as #6.24(bstr .cbor DeviceAuthentication). The same also for
ReaderAuthentication, now ReaderAuthenticationBytes is the CBOR which
is signed by the reader.

Also make a note that the encryptMessageToReader() and
decryptMessageFromReader() should NOT be used and applications should
instead implement these themselves. This is because we don't have the
SessionTranscript available and it's way too late to start adding
public API now. For the next Android version these methods will be
deprecated. Realistically this shouldn't be a problem because
applications are expected to use the Jetpack anyway.

Bug: 159482543
Test: atest android.security.identity.cts
Change-Id: I380a973a0cc78f1206fd7a33d0bd4896a0b16c6d

Bug: 156911917
Bug: 158107945
Test: atest VtsHalIdentityTargetTest
Test: atest android.security.identity.cts
Merged-In: Iacdf89744bbd30c5a10d6cba873147e424ddb01b
Change-Id: I06a536425975b2a5ac7a6adc7bcec9645c370e79

Bug: 156911917
Bug: 158107945
Test: atest VtsHalIdentityTargetTest
Test: atest android.security.identity.cts
Change-Id: Iacdf89744bbd30c5a10d6cba873147e424ddb01b

Bug: 155100967
Test: atest android.security.identity.cts
Merged-In: I850e667676d3488be786447ed3ad33c80444f5e2
Change-Id: I95b909d3e87a1377c3ee5f264d3e519183c51bec

Bug: 155100967
Test: atest android.security.identity.cts
Change-Id: I850e667676d3488be786447ed3ad33c80444f5e2

This change contains no actual syntactical or semantic changes, just
clarifications on the inputs and outputs.

Test: N/A
Bug: 151082886
Merged-In: Ic7797aa53d292abdeb779cb55b404f8a433bce79
Change-Id: I90279c1ba434a9305b991863086b867309549ce8

This change contains no actual syntactical or semantic changes, just
clarifications on the inputs and outputs.

Test: N/A
Bug: 151082886

Change-Id: Ic7797aa53d292abdeb779cb55b404f8a433bce79

Bug: 150817385
Test: atest android.security.identity.cts
Merged-In: I4e005fa7a81ef363a80278224bb706441dad2241
Change-Id: I25e09df09e8a56dc7f639b2aa4636af0166d5050

Bug: 150817385
Test: atest android.security.identity.cts
Change-Id: I4e005fa7a81ef363a80278224bb706441dad2241

The DIS version of 18013-5 now specifically says

  The first encryption with a key shall use a counter value of 1. For each
  following encryption the counter value shall be increased by 1.

in section '9.2.1.4 Mechanism". The previous version said

  The counter value is an unsigned integer, which starts at 0 for both
  the mDL and the mDL Reader. For each encryption the counter value shall
  be increased by 1.

which for some strange reason was interpreted by someone to mean that
counters should start at 1.

Update our implementation to use 1 as now called for by the standard.

Bug: 111446262
Test: atest android.security.identity.cts
Change-Id: I09d1216713d57b54036e4f9aa6677dfa5713133c

Having this method return null is the expected and documented behavior
when either the IC HAL or credstore isn't available.

Test: atest android.security.identity.cts (with credstore not running)
Bug: 148495024
Change-Id: Ifa17c58a84057499b1aeb8404959d5c0badfe52a

Bug: 111446262
Test: CtsIdentityTestCases
Change-Id: Iafe8e76e6491ff92ee751702b8fb44aeda7355a8

The Identity Credential APIs provides an interface to a secure store
for user identity documents.  These APIs are deliberately fairly
general and abstract.  To the extent possible, specification of the
message formats and semantics of communication with credential
verification devices and Issuing Authorities (IAs) is out of scope for
these APIs.

The Identity Credential APIs rely on user authentication to protect
data elements in credentials which is implemented through
auth-tokens. This CL contains changes to CryptoObject to allow this.

Bug: 111446262
Test: CtsIdentityTestCases
Change-Id: I48f21a561b762d86c9ca8d229962782572412f47