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
* changes:
Implement getInterfaceHash/Version for SoundTrigger
Add -Wno-missing-permission-annotation for soundtrigger3
V3 is the latest version of keymaster HAL interface
Freeze AIDL APIs for TM
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
