Check the VSR of the device to select the DICE validation rules that
will be appropriate to use for VTS.
Test: TH
Change-Id: Iff19debd1e442a0b318da1a4d8a08d470efba0ae
The original change to add this test didn't make it into the Android 13
version of the VTS test, so the version gate needs to be updated to be
v3+
Bug: 292318194
Test: VtsAidlKeyMintTargetTest --gtest_filter="*EcdsaMissingCurve*"
Change-Id: I94bf816688e57c7c04893a23cf0399129de94229
Allow for devices that claim to need external timestamps, but don't.
Test: VtsAidlKeyMintTargetTest
Bug: 300211206
Change-Id: Ie450d9969c337d5274502f3600e14c0b481e8b34
Earlier, attestation properties didn't match on GSI images, hence
EcdsaAttestationIdTags VTS test case was skipped on GSI images.
Recently attestation properties reading priority changed as
ro.product.*_for_attestation -> ro.product.vendor.* -> ro.product.*
that means on GSI images ro.product.vendor.* properties could be used
and hence attestation should work. Incase ro.product.vendor.* properties
are not same as provisioned values to KM. They should be set as
ro.product.*_for_attestation on base build.
Bug: 298586194
Test: atest VtsAidlKeyMintTargetTest:PerInstance/NewKeyGenerationTest#EcdsaAttestationIdTags/0_android_hardware_security_keymint_IKeyMintDevice_default
Change-Id: Ie945bd8f7060e0e768daf9681d121ea5f170a6e1
This solution was adopted from Cuttlefish's host side Keymint
implementation: I22bde00aed311c6774f83acc08a2c21e6e75141f.
Bug: 296983430
Test: Tested with Cuttlefish that the logs are present in logcat.
Change-Id: I942b0200bb164a2a865b255c6f26d628cbd345a4
On top of checking that the patch level are a UINT, also check that they
follow the YYYYMM or YYYYMMDD format in the CSR v3 as is required by the
server validation logic. This check is not applied in the factory as the
value might not yet be correctly provisioned.
Bug: 269813991
Test: atest VtsHalRemotelyProvisionedComponentTargetTest
Change-Id: I5c62ba176dae390ea0a387bba6cb975226e3873a
It turns out we had a bug (b/263844771) in how RKP support was
detected, and that was fixed. However, due to this bug, some S chipests
shipped without RKP support which is now required by the tests.
This change drops the RKP requirement from S chipsets. There should be
no new S chipsets, so this effectively grandfathers in the previous
ones that were skipped by the RKP VTS tests.
T+ tests (both VTS and other suites) will verify that RKP support is
there, so there is no gap introduced by this change.
Bug: 297139913
Test: VtsAidlKeyMintTargetTest
Change-Id: I387e5f058ada698747aac103c1745682291f2d1c
The test case for an auth-per-operation HAT with an invalid HMAC
is wrong -- it is re-using the previous HAT, which fails for a
different reason (has an old challenge).
Fix the test to use the HAT that's wrong in the intended way.
Bug: 297333975
Test: VtsAidlKeyMintTargetTest
Change-Id: I15fe9b0c1b53452df0f67dd44534fdb80a6c2a9c
Update TimeoutAuthenticationMultiSid test to support
generateKey for Strongbox implementations without
factory attestation.
Bug: 293211157
Test: run vts -m VtsAidlKeyMintTarget
Change-Id: I27bf08d2fd2d9e0217a90ee8ccb789adfd9d5f7f
The invalid value used for the second IMEI attestation test is
potentially wrong in two ways:
- It doesn't match the provisioned value.
- It's not a valid IMEI, not least because it is longer than 16 bytes.
Make the test value shorter so the second failure doesn't apply and
the test can reliably expect CANNOT_ATTEST_IDS.
Bug: 292959871
Test: VtsAidlKeyMintTargetTest
Change-Id: If8c6b9e08b48e6caf5c767578e1ac43964214619
continuing the execution of the test.
If generateKey fails and execution continues then it leads to issues
while verifying the attest records and causing the crash.
Test: atest VtsAidlKeyMintTargetTest
Bug: 292300030
Change-Id: I66bd650423e9e5bbbfe8411a1455c4ea5846f1ff
Removed the check to skip the attest-id tests on GSI, modified the
attest-id tests to support this.
Bug: 290643623
Test: atest VtsAidlKeyMintTargetTest
Change-Id: Id79d7fb4c70ed94ed76bc57f3d66ce47e9b67b48
When deliberately testing invalid ID attestation, use the helper
function (which checks the error return code is correct) in one more
place.
Test: VtsAidlKeyMintTargetTest
Bug: 286733800
Change-Id: I6ea5bd7ee19b3b172330117bfde1b16745debba7
Avoid the ADD_FAILURE at the end if attestion ID failure uses an allowed
return code.
Test: VtsAidlKeyMintTargetTest
Bug: 286733800
Change-Id: I0dcac312ac4516a078b2742721e3a19074da52b1
Updated VTS tests to verify mgf-digests in key characteristics of
RSA-OAEP keys. Added new tests to import RSA-OAEP keys with
mgf-digests and verified imported key characteristics.
Bug: 279721313
Test: atest VtsAidlKeyMintTargetTest
Change-Id: I06474a85c9e77fded264031ff5636f2c35bee6b4
Update the default KeyMint version to v3.
Note this affects the pure software implementation of KeyMint that is
not used for anything that tests currently run against.
Bug: 275982952
Test: m (that it builds)
Change-Id: I6ab10329af590bd2a045710dfff47c6e78740464
Generalize the existing helper function to allow more variants.
Remove a couple of pointless invocations of the existing helper.
Bug: 286733800
Test: VtsAidlKeyMintTargetTest
Change-Id: Ic01c53cbe79f55c2d403a66acbfd04029395c287
If some check in a VTS test case fails, the test function may exit early
and not call CheckedDeleteKey(&some_keyblob), thus "leaking" a key blob.
This isn't normally an issue, but if the key blob happens to use a
feature that uses some secure storage (e.g. ROLLBACK_RESISTANCE or
USAGE_COUNT_LIMIT=1) then this may leak some scarse resource.
To avoid the chance of this, use an RAII holder to ensure that
manually-managed keyblobs (i.e. key blobs that are not held in the
key_blob_ member of the base test class) are always deleted.
Bug: 262212842
Test: VtsAidlKeyMintTargetTest
Change-Id: Ie8806095e249870484b9875eb660070607f339a3
It should definitely be the case that a different SPL triggers key
requires upgrade, but the converse isn't true -- if no SPL change, it's
OK for the device to request upgrade anyhow.
Bug: 281604435
Change-Id: Ic03ce51fb4b18ff669595ab430f9fccd1da48997
Added a check to make sure IMEI is not "null".
Bug: 281676499
Test: atest VtsAidlKeyMintTargetTest
Change-Id: Ia1569a30412d633eee4d4de8cd00dea077d1c23d
