If vendor/boot patchlevel is shorter than the expected YYYYMMDD format,
fail properly rather than crashing the VTS test process.
Bug: 201946955
Test: VtsAidlKeyMintTargetTest
Change-Id: Icf3541e1b76675871672edec8590ec1821770acf
Believe that all KeyMint implementations are now in compliance with
the HAL specification and so we can enable the checks that all
generated keys include vendor and boot patchlevel.
Test: VtsAidlKeyMintTargetTest
Change-Id: I99741af308023fe12268e9875e252470fbaaaf9e
There are multiple ways this predicate can fail, so add some logging
statements when errors occur so that tests are easier to debug.
Test: VtsAidlKeyMintTargetTest
Change-Id: I49ec12271bdebeab3aa6b9c7ae5d491075b3b649
This alters the HAL documentation to specify that StrongBox must ONLY
support AES 128 and 256 keys.
Bug: 191736606
Test: Read the documentation and confirm that it is clear.
Change-Id: I484d51700df28eb073b7928b6dc7a3b52c59caee
This makes sure that when developers add a new version of an interface,
or when interfaces are being frozen, the runtime/buildtime situation of
clients depending on those interfaces remains the same. This is required
for AIDL to continue working at scale.
Bug: 188871598
Test: build
Change-Id: I358c19c91e8b20d47967aa3b26a8aa5dd6a97ab6
This reverts commit eb8b0577e8.
Reason for revert: Broke a different TEE implementation
Bug: 196922051
Change-Id: I9f136d237bd06bfe2a1cc29d11bb1fbe0b8ace5e
Merged-In: I9f136d237bd06bfe2a1cc29d11bb1fbe0b8ace5e
Test was producing an invalid set of parameters in a different way than
intended.
Bug: 197222749
Test: VtsAidlKeyMintTargetTest
Change-Id: I07f706fec81d91e8eee9c0561428142559c54f12
Test failed to set default key validity, which caused keygen to fail.
Wasn't noticed because this test is typically disarmed.
Note: This test will destroy all user data on the device (which is
why it is typically disarmed).
Bug: 187105270
Test: VtsAidlKeyMintTargetTest --arm_deleteAllKeys
Change-Id: I67e317fdfca15c95c6420918948d1416e97de482
Merged-In: I67e317fdfca15c95c6420918948d1416e97de482
This change clarifies the language to specify that StrongBox devices
must only support key sizes of 128 and 256. Additionally, it changes the
new AesInvalidKeySize test to only enforce against StrongBox instances
on devices that launch on S or later, not previously launched devices.
Ignore-AOSP-First: CP to AOSP
Bug: 191736606
Test: Test passes on a StrongBox enabled device
Change-Id: I1a27a0d61e5247ad90c8f5b1423f2a1567016bac
Explicitly detect empty cert chains returned by GenerateKey rather
than crashing when trying to dereference the first entry.
Bug: 195605180
Test: VtsAidlKeyMintTargetTest
Change-Id: Idad2703b458952ff599c6ccdd04a941aef7aedde
Not all devices have an IRemotelyProvisionedComponent HAL, so on those
devices 0 of the tests in VtsRemotelyProvisionedComponentTests will be
run.
Bug: 194770385
Test: Ran tests on two devices: one with and one without the HAL.
Change-Id: I8624096158f29058189dfab7cd876804ae178e60
Merged-In: I8624096158f29058189dfab7cd876804ae178e60
Not all devices have an IRemotelyProvisionedComponent HAL, so on those
devices 0 of the tests in VtsRemotelyProvisionedComponentTests will be
run.
Fixes: 194770385
Test: Ran tests on two devices: one with and one without the HAL.
Change-Id: I8624096158f29058189dfab7cd876804ae178e60
The ndk_platform backend will soon be deprecated because the ndk backend
can serve the same purpose. This is to eliminate the confusion about
having two variants (ndk and ndk_platform) for the same 'ndk' backend.
Bug: 161456198
Test: m
Change-Id: Ibe8beeaf0d1b33968fb782f1f70c17ae9e9bf871
VtsHalRemotelyProvisionedComponentTargetTest was picking up the same
config file (AndroidTest.xml) as VtsAidlKeyMintTargetTest. When atest or
TF was used to run VtsHalRemotelyProvisionedComponentTargetTest, it
actually ran VtsAidlKeyMintTargetTest.
Add a separate test config file so that we run the correct test binary.
Test: atest VtsAidlKeyMintTargetTest
Test: atest VtsHalRemotelyProvisionedComponentTargetTest
Bug: 192824779
Change-Id: I7ba0f8d364690209722f9a06c6c0ce2957781beb
Merged-In: I7ba0f8d364690209722f9a06c6c0ce2957781beb
VtsHalRemotelyProvisionedComponentTargetTest was picking up the same
config file (AndroidTest.xml) as VtsAidlKeyMintTargetTest. When atest or
TF was used to run VtsHalRemotelyProvisionedComponentTargetTest, it
actually ran VtsAidlKeyMintTargetTest.
Add a separate test config file so that we run the correct test binary.
Test: atest VtsAidlKeyMintTargetTest
Test: atest VtsHalRemotelyProvisionedComponentTargetTest
Fixes: 192824779
Change-Id: I7ba0f8d364690209722f9a06c6c0ce2957781beb
The TAG_ALLOW_WHILE_ON_BODY authorization is not required to be
supported, and if it is not supported it's a noop. Don't expect the tag
to fail with UNSUPPORTED_TAG on devices that don't support it.
Test: VtsAidlKeyMintTargetTest
Bug: 192222727
Change-Id: I2e80ca59151e79f595a65cae94ac966b4ba7020d
Merged-In: I2e80ca59151e79f595a65cae94ac966b4ba7020d
The TAG_ALLOW_WHILE_ON_BODY authorization is not required to be
supported, and if it is not supported it's a noop. Don't expect the tag
to fail with UNSUPPORTED_TAG on devices that don't support it.
Test: VtsAidlKeyMintTargetTest
Bug: 192222727
Change-Id: I2e80ca59151e79f595a65cae94ac966b4ba7020d
Now that we have the production Google Endpoint Encryption Key, we can
update the tests to use the correct GEEK cert chain where applicable.
Test: VtsHalRemotelyProvisionedComponentTargetTest
Test: VtsAidlKeyMintTargetTest
Bug: 191301285
Change-Id: I84b557c6bad34741ffe6671fc941d9e266b73241
Merged-In: I84b557c6bad34741ffe6671fc941d9e266b73241
Now that we have the production Google Endpoint Encryption Key, we can
update the tests to use the correct GEEK cert chain where applicable.
Ignore-AOSP-First: No merge path to aosp, will manually merge
Test: VtsHalRemotelyProvisionedComponentTargetTest
Test: VtsAidlKeyMintTargetTest
Bug: 191301285
Change-Id: I84b557c6bad34741ffe6671fc941d9e266b73241
Fix the device-unique attestation chain specification: The chain should
have two or three certificates.
In case of two certificates, the device-unique key should be used for
the self-signed root.
In case of three certificates, the device-unique key should be certified
by another key (ideally shared by all StrongBox instances from the same
manufacturer, to ease validation).
Adjust the device-unique attestation tests to accept two or three
certificates in the chain.
Additionally, the current StrongBox KeyMint implementation can not yet
generate fully-valid chains (with matching subjects and issuers), so
relax that check.
Bug: 191361618
Test: m VtsAidlKeyMintTargetTest
Merged-In: I6e6bca33ebb4af67cac8e41a39e9c305d0f1345f
Change-Id: Iebefafe72148c919d10308eff7a19fc1bc40c619
We will use the 'Attestation IDs State' field in DeviceInfo to
determine whether a device is still provisionable or not. Once a
production device has left the factory, certain attestated device ids
should be fixed, and 'Attestation IDs State' should reflect this
by reporting "locked".
Remove stale, duplicated DeviceInfo description from ProtectedData.aidl
Test: None, just a doc change
Bug: 192017485
Change-Id: I4e0a840a8f415b3b410801805a158c46be30ec6a
Merged-In: I4e0a840a8f415b3b410801805a158c46be30ec6a
