Check if the zero input data with AES-CBC-[NONE|PKCS7] padding mode
generates correct output data and length.
Bug: 200553873
Test: VtsHalKeymasterV4_0TargetTest, VtsAidlKeyMintTargetTest
Merged-In: I729c2bad65e9d8b194422032346e5ee3c4b0dce5
Change-Id: I729c2bad65e9d8b194422032346e5ee3c4b0dce5
The identifier is to be used in telemetry to identify problematic
implementations. Thus, it needs to be globally consistent, at least
within a given device type.
Test: None -- doc only changes
Bug: 231495834
Change-Id: Ia55db336fa099d8e1196f6bfe2bafb6fa5ead329
Merged-In: Ia55db336fa099d8e1196f6bfe2bafb6fa5ead329
EC_CURVE is a mandatory tag which is specified in the keymint HAL when
generating EC keys.
Bug: 232056693
Change-Id: Ibe2b85744d7e555b7c7b48aa9e57ce45bb19ef89
The data for a key agreement operation should always send in the
SubjectPublicKeyInfo structure, not a raw key for X25519.
Test: VtsAidlKeyMintTargetTest
Bug: 231959070
Change-Id: Ib5157da6a986d957162fab60dbe927017cfdd703
As the signature of the getKeyCharacteristics() does not
use Tag Mechanism for app_id and app_data, there is no way
to distinguish between appId / appData values that are
absent, vs values that are present but of zero length. Due to
this limitation a key with a zero-length app_id / app_data
cannot have its key characteristics retrieved using
getKeyCharacteristics()
Test: VtsAidlKeyMintTarget
Change-Id: I145dcba878171c174d48ad42fadeb49e045b5c55
The root of trust consists of a bitstring that must be derived
from the public key used by Verified Boot, from the lock state
and from the Verified Boot state of the device.
Test: VtsAidlKeyMintTarget
Change-Id: Ib20bf17066f087c6fc050a498cc7ed4a4cb08ae6
- Fix up some minor CDDL formatting issues.
- Add more definition around the BCC, hopefully clearing up partner
confusion around how to implement it.
- Explain when BccPayload entries may be omitted in the case of a
"Degenerate BCC"
- Add a bit more description to the DKSignature format
Bug: 227350250
Test: N/A -- doc changes only
Change-Id: I28337a80e2b49661cc37876400d7ac3b8759ba01
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
Added new VTS EcdsaMissingCurve to test if EC_CURVE not specified while
generating new EC Key, keyGeneration should fail.
Bug: 225135360
Test: run vts -m VtsAidlKeyMintTargetTest
Change-Id: I32bbba05ed5203690292f7150d14f9644c4be6df
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
