This integration was technically a requirement on keymint v2, but we
weren't enforcing it with a test. So realistically we are only able
to start enforcing the test with keymint v3.
Test: atest VtsAidlKeyMintTargetTest
Change-Id: Ia4feb8ce4b7fd1e47a5c6c9b06ddb12276a9c5ee
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
As we've updated the KeyMint version to 3, update the default feature
version to 300. That allows external developers to tell which KeyMint
version is running on the device.
Bug: 244732345
Test: atest android.keystore.cts.DeviceOwnerKeyManagementTest
Change-Id: I9b333eeb77a62a79e8e664d40b5564767643aa3d
This add a cpp default so that the latest cpp code can be
used across the codebase. When this is changed we dont
need to bump versions across multiple files and can just
change it in this one file.
Test: Run and tested using `atest keystore2_test` for Rust test and CTS test with `atest CtsKeystoreTestCases`
Bug: 244730020
Change-Id: Ifae1c5f2403210c2dec1bc337553fbbde73ed4c8
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
Previous versions of VTS had to allow a Device ID attestation failure
to return INVALID_TAG even though this is inconsistent with the KeyMint
spec. This was due to previous KM implementations returning this before
the test was added to validate the precise error code being returned
from Device ID attestation.
For VSR-14 and newer devices, the test will now enforce that only
CANNOT_ATTEST_IDS is returned from a failed device ID attestation call.
Test: atest VtsAidlKeyMintTargetTest
Change-Id: I6acff3fd32f3f251f946e3603283535f36d99a5d
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
Update the comment describing the attestation record:
* KeyMint version bump to V3
* Inclusion of the 2nd IMEI.
Bug: 244732345
Test: That it builds
Change-Id: I19f89bc9936b747647dc690d4702c60d2bbe92c5
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
The key validity can be ignored when generatKey on Android-12 (S).
Bug: 257445538
Test: Pass on S builds
Change-Id: Iafd8d080f324c7d8d6affbb9d28d4f265f13e2ab
Conform to the latest CDDL changes. Organize parsing to observe the
AuthenticatedRequest structure.
Return the deserialized CSR payload rather than the DICE chain keys
because it simplified the return types. The return value is only used
by one VTS test that checks sequential CSRs consist of the same request.
The test was incomplete before and it now only looks as the CSR payload
whereas it previously only look at the DICE chain keys.
Bug: 250910137
Test: atest libkeymint_remote_prov_support_test librkp_factory_extraction_test
Test: atest VtsHalRemotelyProvisionedComponentTargetTest
Change-Id: I1ba2e0cec22e25312fb890923a4c93043e9046cd
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
Define a KeyMint tag for a second IMEI to be included in the attestation
record.
Also clarify that the IMEI tag is meant to include one, and only one,
IMEI.
Bug: 244732345
Test: android.keystore.cts.DeviceOwnerKeyManagementTest
Merged-In: I70ecbb0245ba2e517e5d0db0cfdce4525846f3e5
Change-Id: I70ecbb0245ba2e517e5d0db0cfdce4525846f3e5
Our old NetBSD regex implementation didn't care, but the current NetBSD
implementation rejects unquoted `{` and `}`s that aren't actually part
of a repetition. glibc shares this behavior.
Interestingly, the new NetBSD code was itself an sync with FreeBSD, so
although macOS right now allows this (as Android did), they may well
switch too.
Anyway, this way of writing the regular expressions is strictly correct,
so regardless of whether or not we can actually land this change to the
regex implementation without causing app compat chaos, we should fix
this test.
Bug: http://b/258469149
Test: treehugger
Change-Id: I85bf5d8f557a4fe5ac5ebeea565892d36da30b55
We are now checking the imports of frozen versions of interfaces and
need mark keystore2 as `frozen: false` so the aidl_interfaces that
import it will import the latest unfrozen version.
Test: hal_implementation_test
Bug: 257338648
Change-Id: Ibcb151abd2fc13e3f7dfbcf515d0f62839d1caf9
Execute only relevant benchmark tests for StrongBox.
Bug: b/229819550
Test: run VtsAidlKeyMintBenchmarkTest in the adb shell
Change-Id: I3bf95dc5d4bcd1da027e09b1bbde7e6173749481
"ImportWrappedKeyTest.WrongDigest" tried to wrap a keyBlob by one digest
type and unwrap it by another digest type.
It's been OK for KeyMint implementations to allow unsupported
parameters/characteristics at key generation time, and only police their
use, at begin() time. However if an implementation wants to secure it at
the key generation/importing time the first digest type must be
supported by all implementation.
Bug: 249276913
Test: VtsAidlKeyMintTargetTest
Change-Id: I6bc000026e9e4aec0aa82078a98c75e2d7c56847
Imported interfaces are versioned, i.e. bumping an interface version
necessiates bumping the version of importing interfaces.
Keystore and Identity import KM. We are uprevving KM, so all three need
to be bumped at the same time.
Test: m
Change-Id: I46b253e72f2f245bd628ed2ae1f2f4e0572827e7
Check against version of the interface reported by the HAL rather than
the one from generated code.
AIDL interface are meant to be backwards compatible. Having the HAL
report its version dynamically makes it easier to maintain legacy
behavior while evolving the interface, e.g. we bump IRPC to v3
across our codebase, but devices that already shipped may still behave
as v1/2 devices.
Bug: 235265072
Test: VtsHalRemotelyProvisionedComponentTargetTest
Change-Id: I49e3a09723590ac1a7c432b11450c1438563c787
The certificate signing request (CSR) CDDL schema comprises and
authentication wrapper and an inner payload containing details of the
request. Seperate these two parts more clearly in the schema with a view
to reusing the authentication wrapper for other messages.
The change of Csr to be defined in terms of the AuthenticatedMessage
generic type has no effective change on the schema.
A version field is added to CsrPayload, formerly SignedDataPayload, so
that the AuthenticatedMessage and CsrPayload schemas can evolve
independently.
The cert_type field of DeviceInfo is moved up a level into CsrPayload.
This means DeviceInfo only contains device information and not other
fields related to the CSR.
The payload of AuthenticatedMessage is not self-describing. The expected
schema of the payload will be inferred from context, for example the
server endpoint the message is sent to.
Bug: 250910137
Test: n/a - comments only
Change-Id: I2c981ec8fe63995779ce119168ad3d9b40d5b8c5
Change the cert_type field from an enum of strings to a tstr type with
the known types documented in comments. The types are part of the
protocol between the HAL implementation and the provisioning server that
is opaque to the Android platform, so there's not need to bump the HAL
version in order to add new certificate types.
Replace the undefined Dcc type/acronym with the term "DICE chain" for
smoother reading.
Make the behaviour of generateCertificateRequest() in the v3 HAL more
explicit by explaining that a ServiceSpecificException should be raised
with the same error code that is currently documented.
Bug: 240312857
Test: n/a - comments only
Change-Id: If5acc388b25fa24d240c936ddefd08943fc6dd8d
