Certification may require the use of a larger elliptic curve.
Devices that took a dogfood/beta version of Android S without this
change will experience two problems:
* old P256 keys will be present unused in the database
* in the unlikely event that a screen-lock bound key was created
while the device was locked before taking the update with this change
and then not used until after, the key won't be decryptable.
Since these problems don't affect production users, I don't think
the significant complexity that would be needed to fix them is worth it.
Bug: 191759985
Test: keystore2_test
Test: atest android.keystore.cts.CipherTest#
testEmptyPlaintextEncryptsAndDecryptsWhenUnlockedRequired
Merged-In: If1938bb8eddc148c7f8888006e7eb7c8e9a5a806
Change-Id: If1938bb8eddc148c7f8888006e7eb7c8e9a5a806
With binder::Strong being Sync now. Asp is obsolete.
Test: atest CtsKeystoreTestCases
Merged-In: I55a593f26bc6097122d2bab789aaaf90ee55cacc
Change-Id: I55a593f26bc6097122d2bab789aaaf90ee55cacc
The JSON format is suitable for uploading as test data. It also
includes the build fingerprint, which is required by the backend
to associate the CSR with a particular device family.
Bug: 191301285
Test: Manually run the tool with various --output_format flags
Change-Id: I1d787271c52a25df2d16a6d88dd7b278407ff4b7
Merged-In: I1d787271c52a25df2d16a6d88dd7b278407ff4b7
This CL adds metrics related to attestation pool status and out of key
error, from keystore side.
Ignore-AOSP-First: No mergepath to AOSP.
Bug: 184301651
Test: Statsd test drive script.
Change-Id: I7025c897449e050dda42e2b290dea336c5ad0d52
Keystore 2.0 assumed that the version number in the HWInfo struct
corresponds to the HAL version. This is actually not the case as per the
KeyMint spec. The legacy wrapper sets the version number as expected but
genuine Keymint implementations might not. This match ignores the
versionNumber filed of genuine KeyMint implementations and replaces it
with the HAL version.
Bug: 187862706
Test: N/A
Merged-In: I392d4ec3c00f22f11920abe44cc3375b7266508e
Change-Id: I392d4ec3c00f22f11920abe44cc3375b7266508e
Certification may require the use of a larger elliptic curve.
Devices that took a dogfood/beta version of Android S without this
change will experience two problems:
* old P256 keys will be present unused in the database
* in the unlikely event that a screen-lock bound key was created
while the device was locked before taking the update with this change
and then not used until after, the key won't be decryptable.
Since these problems don't affect production users, I don't think
the significant complexity that would be needed to fix them is worth it.
Bug: 191759985
Test: keystore2_test
Test: atest android.keystore.cts.CipherTest#
testEmptyPlaintextEncryptsAndDecryptsWhenUnlockedRequired
Ignore-AOSP-First: problem in sc-dev, no merge path from AOSP
Change-Id: If1938bb8eddc148c7f8888006e7eb7c8e9a5a806
It turns out there are more clients that use Keystore in a creative
way. This patch renames the VpnProfileStore to LegacyKeystore and
extends the functionality such that it allows access to all blobs with
alias prefixes that were not known to Keystore. It also brings back the
option to specify a uid argument. Specifically, for AID_SYSTEM to
manipulate the WIFI namespace.
Test: TBD
Bug: 191373871
Merged-In: Iaf81e7ccaee3c09a465dcec0fd5899b781c31db5
Change-Id: Iaf81e7ccaee3c09a465dcec0fd5899b781c31db5
It turns out there are more clients that use Keystore in a creative
way. This patch renames the VpnProfileStore to LegacyKeystore and
extends the functionality such that it allows access to all blobs with
alias prefixes that were not known to Keystore. It also brings back the
option to specify a uid argument. Specifically, for AID_SYSTEM to
manipulate the WIFI namespace.
Ignore-AOSP-First: No mergepath from AOSP
Test: TBD
Bug: 191373871
Change-Id: Iaf81e7ccaee3c09a465dcec0fd5899b781c31db5
Keystore2 atoms need to be routed to statsd via a proxy.
The proxy needs to call this API in order to pull metrics from
keystore.
Ignore-AOSP-First: No mergepath to AOSP.
Bug: 188590587
Test: Statsd Testdrive script
Change-Id: I28f8675fe5467b0760418c4d2d87808e45657be1
Currently, KS2 will always fetch and provide an attestation key for a
key being generated. This behavior is currently hidden by the fact that
for a factory provisioned KM, the behavior to just generate or generate
and attest to a key is the same from the KS2 perspective. KM figures out
if it should actually attest to the key by checking if an
ATTESTATION_CHALLENGE tag is present.
Alternatively, KS2 provides a user provided attestation key, which
should only be used if an attestation challenge is present. This would
also fail, probably expectedly, if the user provided their own
attestation key during key generation and didn't specify a challenge.
The issue arrises when RKP is enabled, as KS2 will always assign and
fetch an RKP key for a process that's generating a key, even if
attestation isn't requested. This causes key generation to fail for
non-attested keys.
This patch first checks to see if an ATTESTATION_CHALLENGE is present
before attempting to attest to the key.
Ignore-AOSP-First: CP from AOSP
Fixes: 191951059
Test: atest com.android.keychain.tests.BasicKeyChainServiceTest
Change-Id: Ibf9d31ca6519477c1aba6ab4a8dfe98b4f1f0d81
Currently, KS2 will always fetch and provide an attestation key for a
key being generated. This behavior is currently hidden by the fact that
for a factory provisioned KM, the behavior to just generate or generate
and attest to a key is the same from the KS2 perspective. KM figures out
if it should actually attest to the key by checking if an
ATTESTATION_CHALLENGE tag is present.
Alternatively, KS2 provides a user provided attestation key, which
should only be used if an attestation challenge is present. This would
also fail, probably expectedly, if the user provided their own
attestation key during key generation and didn't specify a challenge.
The issue arrises when RKP is enabled, as KS2 will always assign and
fetch an RKP key for a process that's generating a key, even if
attestation isn't requested. This causes key generation to fail for
non-attested keys.
This patch first checks to see if an ATTESTATION_CHALLENGE is present
before attempting to attest to the key.
Fixes: 191951059
Test: atest com.android.keychain.tests.BasicKeyChainServiceTest
Change-Id: Ibf9d31ca6519477c1aba6ab4a8dfe98b4f1f0d81
Merged-In: Ibf9d31ca6519477c1aba6ab4a8dfe98b4f1f0d81
