VTS tests were currently passing a challenge size of 32 in all cases.
However, the server currently sends a challenge of length 40, which may
or may not change in the future. A 64 byte upper limit provides a
standard size along with flexibility in case the challenge format
changes in the future.
Test: atest VtsHalRemotelyProvisionedComponentTargetTest
Change-Id: I678bb915f139e4c23354180870a66ce33a9cfd8c
The AesEcbPkcs7PaddingCorrupted test has been incorrect since it was
originally introduced -- it was feeding the original message as input to
the decryption operation, rather than the corrupted ciphertext. As a
result, the expected error code was also wrong -- INVALID_INPUT_LENGTH
is appropriate for a too-short cipher text (length 1 in this case),
whereas a corrupt-but-correct-length cipher text should give
INVALID_ARGUMENT.
Fix the test, and add a separate test to cover what was inadvertently
being tested before. Add a sentence to the HAL spec to describe what
expected and tested by CTS/VTS.
Bug: 194126736
Test: VtsAidlKeyMintTargetTest, VtsHalKeymasterV4_0TargetTest
Change-Id: Iaa5e42768814197f373797831093cf344d342b77
Updated VTS testcases where Device IDs Attestation expected as optional
and made it mandatory if KeyMint version >= 2 or device first shipped
with api_level 33.
Bug: 221190197
Test: run vts -m VtsAidlKeyMintTargetTest
Change-Id: I8870a9301d36abdc4fa6585b9f8d62cc1cfd3d96
The signature is not CBOR-encoded, it's the raw bytes of the signature
encoded as specified for the specific algorithm.
I've made the references to PureEd25519() / ECDSA() into comments,
since I believe they're not actually legal CDDL but are aimed at
humans. And I've made the two occurrences consistent with each other.
Test: N/A
Change-Id: Ia42362ff3d0ce5458322663256cbd34d258afe76
This change makes sure the DeviceInfo CBOR map is canonicalized before
the signature check instead of just separately checking the
canonicalization in a separate call. Additionally, some ASSERTs have
been changed to EXPECTs in validation of the DeviceInfo map more
generally, where it makes sense to avoid failing immediately.
Test: atest VtsHalRemotelyProvisionedComponentTargetTest
Change-Id: I69806c887656772ea6b5e2e3f0af50957e6b05e3
This CL adds a VTS test for the DICE HAL, and a test specific for
demotion testing. Demotion testing leaves the device in a permanently
modified state untill the next reboot, which is why it needs a special
test config. The current test config restarts the device before testing,
in a followup the device also has to reboot after the test.
Bug: 198197213
Test: atest VtsAidlDiceTargetTest
atest VtsAidlDiceDemoteTargetTest
Change-Id: I4278a1352df749da50dc8e5d118fc37336026061
Change Id62fdce65131ee00c88e5849955a937f1c171748 split up the AES
incremental encryption tests into individual tests for each encryption
mode. This meant that each generated key is only valid for a single
mode, which in turn means that for non-GCM mode keys it is not valid
to specify MIN_MAC_LENGTH.
Bug: 223934835
Test: VtsAidlKeyMintTargetTest
Change-Id: I38f34f60116bde3d23f203365d62e5b25d7b254b
As the current KeyMint version is 2 (200), reflect that in the default
XML.
Devices that ship with older KeyMint/KeyMaster version should override
the default android.hardware.hardware_keystore.xml file with the
version they support.
Test: android.keystore.cts.KeyAttestationTest#testAttestationKmVersionMatchesFeatureVersion
Bug: 222406513
Bug: 216543583
Change-Id: I6f2229019929cff747cec3907fc2a9b8ebebdcf4
Don't run tests if the appropriate KeyMint device is not available (e.g.
on something that only has Keymaster). Move to use GTEST_SKIP
consistently.
Bug: 221909227
Test: VtsAidlKeyMintTargetTest
Change-Id: I5dab238519e57e6752b795f3a983681cf4337bdd
On some devices it is infeasible to provision the KeyMint RoT bits in
the Android Bootloader. This provides an alternate path to provision
them from the TEE during early boot.
Bug: 219076736
Test: VtsAidlKeyMintTargetTest
Change-Id: If69f7e25e58edbf4d2190084e2c0a03a94bfa5d6
Merged-In: If69f7e25e58edbf4d2190084e2c0a03a94bfa5d6
* Timed out runs do not show any warning messages.
* These test files cannot finish clang-tidy runs with
the following settings:
TIDY_TIMEOUT=90
WITH_TIDY=1
CLANG_ANALYZER_CHECKS=1
* When TIDY_TIMEOUT is set, in Android continuous builds,
tidy_timeout_srcs files will not be compiled by clang-tidy.
When developers build locally without TIDY_TIMEOUT,
tidy_timeout_srcs files will be compiled.
* Some of these test modules may be split into smaller ones,
or disable some time consuming checks, and then
enable clang-tidy to run within limited time.
Bug: 201099167
Test: make droid tidy-hardware-interfaces_subset
Change-Id: I1de28f1572fff368f67eab512fffec9f2e5c2a9b
A VTS testcase is added to validate Asymmetric key generation fails if TAG_CERTIFICATE_NOT_(BEFORE/AFTER) is missing.
Also updated DeviceUniqueAttestationTest to set validity in
AuthorizationSetBuilder using .SetDefaultValidity().
Bug: 205679495
Test: run vts -m VtsAidlKeyMintTargetTest
Change-Id: Ibf63a6c8e173326502c7bf1b8f3af8666ecb1caf
This change allows the os_version in the DeviceInfo map to be optional
for StrongBox implementations. It also adds the appropriate changes to
the VTS test to relax this requirement.
Bug: 215444522
Test: atest VtsHalRemotelyProvisionedComponentTargetTest
Change-Id: I1695b7c4e7a9bd884fa88c14f9c22bacd38cdbd3
The algorithm choice was listed as -8 for ES256, when it should be -7.
Fixes: 217691766
Test: Everyone harmoniously agrees by +2'ing.
Change-Id: I7f73efff42ee6d2b3bfb94b74c1208170805b870
This change specifies that the DeviceInfo map returned by the IRPC HAL
implementation should be canonicalized. Additionally, it adds coverage
to the VTS tests to ensure this requirement is enforced.
Test: atest VtsHalRemotelyProvisionedComponentTargetTest
Change-Id: I276f38497a307c407d305b62a3e9af78a403054e
