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