Fixes:
- Revert to pre-RKPD behavior of getting an attestation key each time
a credential is created.
- Revert to pre-RKPD behavior of falling back to factory key.
- Check RKPD feature flag each time before calling into RKPD.
- Correct service name used to call into RKPD.
- Add another thread to handle async responses from RKPD.
- Switch to new RKPD build flag "remote_provisioning.enable_rkpd".
Bug: 261214100
Test: CtsIdentityTestCases
Change-Id: Idc11abb3c0e46de1a77609969e8539e9e96549d5
Call out to keystore and request remotely provisioned attestation keys.
This reduces our dependence on factory-provisioned attestation keys.
Test: CtsIdentityTestCases
Bug: 194696876
Change-Id: Ief07750ef6b2a465060c64207063568b9a51af68
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
Currently we're using file-specific tags which makes it hard for
people looking at logcat to infer it's actually from credstore and it
also complicates filtering. Just use "credstore" everywhere.
Also change logging level from ERROR to INFO in the message
"Registered binder service" which is logged on startup.
Bug: None
Test: Compiles + manual inspection via logcat
Test: atest android.security.identity.cts (on goldfish)
Change-Id: I336d1a4e4e10b87fd3f08a5046cf5e13f09c9cb6
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
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
