This document goes a little more in depth on the motivating factors and
background mechanisms that occur with RKP, that are not appropriate for
direct inclusion in the HAL docs in the .aidl files.
Fixes: 234159998
Test: Readable
Merged-In: I141fb098c536a5468b1113af64dcf6185ea7ae9f
Change-Id: I141fb098c536a5468b1113af64dcf6185ea7ae9f
This change syncs aosp/master with the change in http://aosp/2117528,
allowing devices that launched with the (incorrect) version of
ATTEST_KEY VTS tests in Android S to continue to pass the test.
Bug: 197096139
Bug: 230074335
Test: VtsAidlKeyMintTargetTest
Change-Id: If88642e238e64ca9ec80303a4a72f7171c63464f
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
