The Open Profile for DICE give possible guidelines on the requirements
for the DICE mode but Android needs those to be strictly specified.
Fix: 263144485
Test: n/a
Change-Id: Ia5fc937654504199cabf4709f1c15484242e0161
It's already documented that IRPC v3 doesn't make use of test mode keys
however VTS still required support for their generation. Fix this and
simplify implementation of the v3 HAL by expecting an error in all cases
that the deprecated test mode keys are seen.
IRPC v3 also fully deprecated the EEK meaning a v3 implementation must
unconditionally report CURVE_NONE for supportedEekCurve.
The VTS tests are enhanced with contextual version constants rather than
reusing constants with seemingly unrelated names.
Bug: 278013975
Test: atest VtsHalRemotelyProvisionedComponentTargetTest
Change-Id: I5709a0b1cd77eb28e677f64bb781fad58d91570a
Following feedback from partners, allow the component version in the
configuration descriptor to be either an int or a string.
Bug: 273552826
Test: n/a
Change-Id: Iecc9889592a2e634a3b9e40f14347b231b703c60
Deprecate the CSR format from v1 and v2 of the HAL, again. The older CSR
versions were allowed in order to ease migration from the
RemoteProvisioner app over to rkpd and that has now been completed.
Bug: 260920864
Test: atest VtsHalRemotelyProvisionedComponentTargetTest
Change-Id: I4d16eb64e4ffe602b4b252159202a4ddb56d63d7
RKP allows 0 ~ 64 byte challenge to be provided.
Test it by several different size inputs.
Bug: 272392463
Test: VtsHalRemotelyProvisionedComponentTargetTest
Change-Id: I488c75745dc68778ff6d862506a5beeec82f7ac1
Some of the DeviceInfo must match existing tags in KeyMint, but this
was not documented.
Test: n/a
Change-Id: I7733e2a4b0c08b0b89ece41390c0ce0711459d82
Since comments are stripped from the stable AIDL snapshots, the CDDL
describing the DeviceInfo contents is lost for the older versions. Add
the comments from older DeviceInfo versions as a reference for
maintainers of older HAL implementations.
Test: n/a
Change-Id: I7dd3d285b3d8422a6df4228ad0cf5797e78609c1
When we split the rkp interface, we only added one hash to rkp v2, but
on Android S devices, this interface was in keymint v2, and so it used
the keymint v2 hash.
In order for that old implementation to be recognized, we need to add the hash in specifically.
Note: v1 was missed in b/264549860, but this was v2.
Fixes: 271513408
Test: vts_treble_vintf_vendor_test
Change-Id: I58c7c41633000df933261a147edd3477afd09a36
The server-provided challenge is almost always smaller than 32 bytes,
so we cannot enforce that as a minimum. I fixed up the CDDL a while
back, but missed one mention of the 32 byte minimum in the description.
Test: n/a (it's a comment)
Bug: 272392463
Change-Id: Ia5994e2b7cf107ab131c6b028bee7881d0e657ac
The PartyInfo for a P-256 public key is encoded as (x||y) not
(0x04||x||y).
Test: VtsHalRemotelyProvisionedComponentTargetTest
Change-Id: Iae5dc624228d4e1e538e230968443925ec8b55fc
When we split the rkp interface, we only added one hash to rkp v1, but
on Android S devices, this interface was in keymint v1, and so it used
the keymint v1 hash.
In order for that old implementation to be recognized, we need to add the keymint v1 hash into rkp v1.
The hash added here is copied from this file:
hardware/interfaces/security/keymint/aidl/aidl_api/android.hardware.security.keymint/1/.hash
Bug: 264549860
Change-Id: I3fce46b3e9bd09d79fa8e2f203b4eb9ebb517c15
Test: vts_treble_vintf_vendor_test
- Rename keysToCertify to keysToSign to match param name in a few
places.
- Make clearer that P-256 is allowed in EEK.
- Make clearer that EEK curve should match that specified in
RpcHardwareInfo.supportedEekCurve.
- Add note about AAD for AES-GCM encryption.
- Add note about format of public key data in KDF context.
Test: None, comments only
Change-Id: Ie775a453b4d3941b7d24396da66681ab91978d81
Following requests from partners, document P-384 and SHA-384 as
officially supported signing algorithms and hash functions in the DICE
chain.
Bug: 265455904
Test: n/a -- documentation-only change
Change-Id: Id7b5eaf81be17fda9278dc7ad5f2b441931c6b83
The current RKP server produces challenges smaller than 32 bytes.
As existing devices in the field may have some length limitations
due to this, let's not start sending larger challenges to those
devices. Instead, drop the challenge to 16 bytes to maintain compat.
There should be plenty of entropy in 16 bytes.
Test: n/a
Change-Id: I1dfd9b4b06131df907683207e4b6bfb2d1c93d65
This updates the test: supportsValidCurve, for IRPC implementations
that supports only V3+.
Bug: 239476788
Test: atest VtsRemotelyProvisionedComponentTests with IRPC V3
implementation
Change-Id: Ic0f1223b30e31dc537155e19e800b3001ce0fc01
- STATUS_TEST_KEY_IN_PRODUCTION_REQUEST is still required for V3
- PubKeyEcdhP256 & PubKeyX25519 are unused in V3
- SignedDataSigStruct and DiceChainEntryInput should be an cbor array
when being the input of PureEd25519/ECDSA
Bug: 243454124
Test: VtsHalRemotelyProvisionedComponentTargetTest
Change-Id: Ice400bb15413eac164f2630cc2fbb66e6d3624b1
If the base set up fails, the RKP version number might not be valid so
we shouldn't try to work out whether the test should be skipped based on
the version.
Assert that there weren't any fatal errors from the base set up rather
than reporting that the test should be skipped as that can be a bit
confusing.
Test: atest VtsHalRemotelyProvisionedComponentTargetTest
Change-Id: Icaf946ef4cf6b31dcfe7187131538b9eb3892798
Check the VSR API level for the device under test and ensure that the
appropriate HAL version for the IRemotelyProvisionedComponent interface
is present. E.g. a VSR 13 chipset should have IRPC v2 or newer.
Bug: 251185719
Test: atest VtsHalRemotelyProvisionedComponentTargetTest
Change-Id: I136cac27953d1d5acaa45510ad9efec2a75d8038
Now that the RKP HAL AIDL has been moved to it's own directory, we
should keep the tests with the AIDL.
Test: atest VtsAidlKeyMintTargetTest
Test: atest VtsHalRemotelyProvisionedComponentTargetTest
Change-Id: Ia87d3ea0a1b9e6704f0dea8f98b0bbaa049472fe
Specifically, we want IRPC v3 to be able to serve old v2 clients. This
way we can ship parts IRPC v3 stack incrementally.
To that end, allow IRPC v3 to implement v2 behavior of
generateCertificateRequest and testMode.
Bug: 260920864
Test: atest VtsHalRemotelyProvisionedComponentTargetTest
Change-Id: I9e47697bd948c8fd6b82147165d0c67bdef9fbd3
This change clarifies some more items that have changed between v2 and
v3 of the IRPC spec, along with fixing and clarifying some more
messaging in the .aidl documentation.
Test: Someone else can intelligibly read what was written
Change-Id: Ia9fa1595a72c818f93ce6fb31ea38c97d997488b
Rationale here is that many IRPC implementations are memory constrained.
We add a way for implementations to report the maximum number of
supported keys. This way we can guarantee consistent behavior across
different devices.
For implementation of IRPC version 3 and later we define the lowest
number of keys supported to be 20. This specific value was chosen
because the current implementation of RemoteProvisioner already combines
keys into batches of exactly 20.
Bug: 254137722
Test: atest VtsHalRemotelyProvisionedComponentTargetTest
Change-Id: Ib6fb6d6ec7c74004524a5505a37aa82c9e44ef91
Rename from AuthenticatedMessage to AuthenticatedRequest in order to
make the direction of the message clear.
Move the challenge out of the endpoint-specific message and up into the
common authentication wrapper as it is uesd in the authentication
protocol.
Simplify the versioning by having the CSR version continue sequentially,
making the current version 3. Have the AuthenticatedMessage version
start from 1 as it's value isn't used to distinguish v2 and v3 CSRs
anyway and it will avoid confusion with the CSR version which has
already moved beyond this value.
Bug: 250910137
Test: n/a -- comments only
Change-Id: I13836e90fa76b1b22cb6627f3d987828ffeb0adc
