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 checking storeStaticAuthenticationDataWithExpiration() is
only available on HAL version 3 and later (feature version 202101 and
later). This works on any HAL version.
Bug: 241912421
Test: atest VtsHalIdentityTargetTest
Test: atest android.security.identity.cts
Change-Id: Ic8274088035c31f73ad61645ee5e0281b3460837
Also fix a bug so the same AuthKey is used for several getEntries()
calls on a credential. This matches the behavior in the Jetpack.
Bug: 197965513
Test: New CTS tests and new screen in CtsVerifier
Change-Id: I344f44b5655f0977ee650b518ce669e3c8a7b47a
The root of the problem is that in some cases credstore would
pass auth- and verification-tokens to the Identity Credential
HAL without first having obtained a challenge via
IIdentityCredential.createAuthChallenge(). This makes it
impossible for the TA to validate the verification token for
freshness.
This is easily fixed by simply ensuring createAuthChallenge()
is called (and the returned challenge is used in the requested
verification token) whenever dealing with ACPs using user
authentication.
Additional issues / changes:
- During Android 12 development, an use-after-free bug was
introduced in Credential.cpp L120.
- keystore's getTokensForCredstore() had some bugs in how to
select an auth-token, in particular mixing authTokenAgeMillis
(milliseconds) with time_t values (seconds)
- as a result, keystore would sometimes return tokens older
than what credstore requested. This wasn't actually problem
because the TA would check it anyway.
- we now precisely define semantics in IKeystoreService.aidl
- Another potential use-after-free bug was found in
Credential.cpp L767
None of the fixes for these bugs affect CTS or VTS tests.
Bug: 181893400
Test: atest android.security.identity.cts on emulator
Test: atest android.security.identity.cts on crosshatch (w/ Android 11 era HAL)
Test: CtsVerifier's Identity Credential Authentication test crosshatch (w/ Android 11 era HAL)
Change-Id: I45a3fd16eff3b6a232d8b8c88f2e3dd3619a9c03
- Add Credential.proveOwership()
- Add Credential.deleteWithChallenge()
- Add Credential.updateCredential()
- Add Credential.storeStaticAuthenticationDataWithExpirationDate()
- Store this on disk. For entries stored without this parameter
assume they never expire.
- Add allowUsingExpiredKeys to Credential.selectAuthKey() and
Credential.getEntries()
- Unless set to true, never select an expired key
- Introduce ERROR_NOT_SUPPORTED and return this if HAL does not
support operation
Bug: 170146643
Test: atest android.security.identity.cts
Change-Id: Ic5dafc6498c9c59b82942def9d348d974f008589
Without this extra information passed upfront it's not practical to
implement a HAL which incrementally builds up cryptographically
authenticated data.
This information is conveyed by using two new methods on version 2 of
the Identity Credential HAL. If these methods are not implemented (if
a version 1 HAL is running) the invocation fails and we handle this
gracefully by just ignoring the error.
Bug: 154631410
Test: atest VtsHalIdentityTargetTest
Test: atest android.security.identity.cts
Change-Id: I17d516e41e800f58daa4c11dcca0305c80740d5b
The credstore system daemon is sitting below the Identity Credential
Framework APIs and on top of the Identity Credential HALs. Its main
job is to store credential data and provide a way for applications to
communicate with the secure hardware abstracted by the HAL.
This daemon runs as an unprivileged user, credstore.
The auth-tokens needed by credstore are supplied by keystore and this
CL includes the requisite changes to keystore for this to work.
Bug: 111446262
Test: CTS tests for Framework APIs
Change-Id: Ieb4d59852a143482436a1c418c25ed96e25c0047