1. Using second IMEI as attestation id without using first IMEI.
Test should generate a key using second IMEI as attestation id
without using first IMEI as attestation id. Test should validate
second IMEI in attesation record.
2. Using first IMEI as well as second IMEI as attestation ids.
Test should generate a key using first IMEI and second IMEI as
attestation ids. Test should validate first IMEI and second IMEI
in attestation record.
Test: atest -c VtsAidlKeyMintTargetTest
Bug: 263197083, 264979486
Change-Id: I61c3f32e15a8d478a838d14e7db9917a33682267
The code needed to be adpated because the public fields the code
accessed previously now become private. We need to access them
via the trait now.
This cl also deletes unused dependence libdiced_open_dice_cbor in
the dice service and tests targets.
Bug: 267575445
Test: m android.hardware.security.dice-service.non-secure-software
Test: atest VtsAidlDiceTargetTest VtsAidlDiceDemoteTargetTest
Change-Id: I16e18226c0bce8a90ed764ba598e90e7c1c854ab
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
This is part of the project of merging the two existing dice
wrapper libraries into the library libdiced_open_dice to
improve maintainability.
Bug: 267575445
Test: m android.hardware.security.dice-service.non-secure-software
Test: atest VtsAidlDiceTargetTest VtsAidlDiceDemoteTargetTest
Change-Id: If9ee66a320775897342f53d58ee11405a8e70c6f
Skip attestation key tests if the feature
FEATURE_KEYSTORE_APP_ATTEST_KEY is disabled on device,
as done in KeyMint CTS.
Bug: 244460948
Bug: 265740739
Test: VtsAidlKeyMintTargetTest
Change-Id: I8199e5c7570b10b71f127c7439b889c0b3327865
- 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
attestation id.
Get IMEI value from Telephony Service and use it as attestation id.
Bug: 261847629
Test: atest VtsAidlKeyMintTargetTest
Change-Id: I0212def48d761a45f514161e5576a954bf388c56
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
Updated the digest to SHA_2_256 in manaul key upgrade tests
so that these tests works for StrongBox as well.
Test: VtsAidlKeyMintTargetTest
Change-Id: I971f6e13272450d39537cc44c59f8ed8dbd19bf0
libcert_request_validator is now called libhwtrust so update the
references to match.
Test: atest VtsHalRemotelyProvisionedComponentTargetTest
Change-Id: I3c73e2749996ef684da4567a3c86daf8b9c0fd09
Remove one of the DICE chain validation implementations and replace it
with a call to the libcert_request_validator library which has the most
complete validation and is planned to be the only implementation we
support.
VTS will now check both degenerate and proper DICE chain more completely
and will be consistent with other tools like `bcc_validator`. P-384 will
become a supported key type in the DICE chain.
The whole static library is included so that clients that statically
link remote_prov_utils don't need to be aware of the dependency.
Bug: 254510672
Bug: 265455904
Test: atest VtsHalRemotelyProvisionedComponentTargetTest
Change-Id: I067f7e8710e379a4b404ef9d2c04fe6410f73dc4
Clarify that the tag for the 2nd IMEI must denote an IMEI different to
the tag used for the first IMEI, and may be used independently of it.
Bug: 264979486
Test: N/A
Change-Id: I45a46d1052e45a965c8be391d11157cc4481545b
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 made it easier to run libkeymint_remote_prov_support_test.
Bug: 264302050
Test: atest libkeymint_remote_prov_support_test
Change-Id: Ided4e9bb442274ea7711d283bc947c35f34ebc35
To help with error reporting on the RKP servers in the future it
will be helpful to be able to address CSRs by serial number when
possible.
Bug: 264302050
Test: libkeymint_remote_prov_support_test and sent JSON to server
Change-Id: I2808441c200d0679e618580abc464cd3c71c220e
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
It's not enough to verify that the system is running KeyMint 2+. We
also need to verify that the vendor partition has RKP support.
Since VSR 13+ requires KeyMint 2+, change the test assumption so that
we don't run the test against systems that may have shipped with an
older VSR chipset (which won't support RKP).
Bug: 263844771
Test: VtsAidlKeyMintTargetTest (on old and new device)
Change-Id: Iac15f69db1152851f5a92d3929cb258b1b1a6b02
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
