This KM4 key agreement check is causing some pain on early units
that aren't completely provisioned in both locked and non-Green
(unlocked) states.
This doesn't impact KM3 devices (Pixel 2016/2017 etc.)
Bug: 110301629
Change-Id: I5a737ac8a335863b1099c29cf3c0496adeb41e15
This had to be disabled because Qualcomm's keymaster4 returned a bad
value.
Bug: 77588764
Bug: 79698245
Test: VtsHalKeymasterV4_0TargetTest
Change-Id: Ieb150d7f17c36f01acf2eeb665792594251b51ae
To make it easier for clients (vold & keystore) to perform key
agreement, this CL adds a service method that does it. To make key
agreement consistent, this method sorts the HMAC sharing parameters
lexicographically. The requirement for sorting is documented in the
HAL.
Test: Boot device
Bug: 79307225
Bug: 78766190
Change-Id: Idb224f27f8e4426281d9a0105605ba22bf7c7e95
Bug: 38430282
Test: VtsHalKeymasterV3_0TargetTest pass with exception
of (AesEcbWithUserId, RsaAttestation, EcAttestation)
which are expected failures.
Change-Id: I48e7195f512190deb608f1a69783c92254eef1aa
Keymaster clients need to see all the available devices and figure out
which they want to use. This method finds them all and returns them
in a vector sorted from most secure to least, according to a heuristic
defined in Keymaster::VersionResult::operator<
This CL also makes a few other minor improvements to the support
library, providing more information in VersionResult and adding some
more convenience methods in AuthorizationSetBuilder.
Test: Build & boot
Change-Id: I876238ee9ff72573c30d60e1cec665dd610bcde6
