This failure is also diagnosed by CTS, but it should be validated in VTS
as well.
Merged-In: Ia7654ff8813942fbca9dfa838337e9de5839a9e2
Bug: 33945114
Test: adb shell data/nativetests64/VtsHalKeymasterV3_0TargetTest/VtsHalKeymasterV3_0TargetTest
Change-Id: Ia7654ff8813942fbca9dfa838337e9de5839a9e2
Support for 256 bit RSA keys are not mandated by keymaster specs and
must not be used in the VTS tests.
Bug: 62581389
Change-Id: If315088db2752ac2efe31fdb95db7ca13c3ce225
The attestation version cannot be infered from the keymaster version
because we provide software attestation for legacy keymaster 1 keys.
This patch changes the attestation test to expect either attestation
version 1 or 2.
Bug: 37351644
Test: VtsHalKeymasterV3_0TargetTest
Change-Id: I4db83a543db20191d288b2ca8308aa6597cd8e22
DeleteKey may legitimately return ErrorCode::UNIMPLEMENTED rather than
ErrorCode::OK, but the VTS test didn't allow that in all cases. In many
case the return code was also left unchecked.
Test: adb shell/data/nativetest64/VtsHalKeymasterV3_0TargetTest/VtsHalKeymasterV3_0TargetTest
Bug: 62193967
Change-Id: I19a90a87850675b0700baf7409e57098e0584d54
android.hidl.base@1.0 and android.hidl.manager@1.0 are built into libhidltransport.
Test: links
Bug: 33276472
Merged-In: I08aaad80f7e2fc262aa3a8b66fe932e8133a928d
Change-Id: I08aaad80f7e2fc262aa3a8b66fe932e8133a928d
Keymaster 3.0 VTS test required that deleteKey returns
ErrorCode::OK even if the key blob parameter is invalid or garbage.
The rationale is that deleteKey shall have the invariant that
key blobs are unusable after the deleteKey call. If it was unusable
before, this invariant is upheld.
This patch makes the legacy wrapper for the Keymaster HAL translate
an ErrorCode::INVALID_KEY_BLOB retuned by the legacy delete_key to
ErrorCode::OK.
Bug: 37351644
Test: Manually run VtsHalKeymasterV3_0TargetTest with legacy keymaster
HAL installed (tested with sailfish)
Change-Id: Ib22c8b8e10334770a1d4a5570acf16c2c52a6c60
This is a follow-up to change I5a9fd839497976cdb1e44cbe4a2d5b7730732b4c,
where manufacturer and model were added to the set of attestable device
IDs.
Bug: 37522655
Test: GTS com.google.android.gts.security.DeviceIdAttestationHostTest
Change-Id: Ied4246f4fc490feb2093f04c268aab83c8e1326d
The keymaster service is required by vold which starts very early
during boot up. This leads to the dependency loop:
init->installkey->vdc->vold->keymaster-service->init
This patch resolves this issue by adding service keymaster to the class
early-hal which will get started right after hwservicemanager on devices
that get treble.
Bug: 35764921
Test: Device boots. And lshal shows that service keymaster has two
clients, keystore and vold.
Change-Id: Id0b6722de900b5513d46adb81d76b02fa6e155df
The tests added verify that a generated key is no longer usable
after it was
- explicictely deleted with deleteKey, or
- all keys where deleted with deleteAllKeys.
Bug: 32022681
Test: make vts -j30 BUILD_GOOGLE_VTS=true TARGET_PRODUCT=aosp_arm64 &&
vts-tradefed run commandAndExit vts --skip-all-system-status-check
--primary-abi-only --skip-preconditions
--module VtsHalKeymasterV3_0TargetTest -l INFO
Change-Id: I172ee5d3ccf1850c3c92d3a1a9e991f46b07a0e3
Note: Recent Google devices have keymaster implementations that don't
pass this test suite. See https://goo.gl/6hsGwa for a summary.
Bug: 32022681
Test: This is the test suite.
Change-Id: Ib200b68e0c7844df02eb9f086385d6c36e306d45
Auth tokens have an unfortunate dual character. To most of the system
they are opaque blobs that are intended only to be obtained from one
HAL (e.g. gatekeeper or fingerprint) and passed to another
HAL (keymaster), but keystore actually needs to extract some bits of
information from them in order to determine which of the available blobs
should be provided for a given keymaster key operation.
This CL adds a method that resolves this dual nature by moving the
responsibility of parsing blobs to the HAL so that no component of the
framework has to make any assumptions about their content and all can
treat them as fully opaque. This still means that the various HAL
implementers have to agree on content, but they also have to agree on an
HMAC key which much be securely distributed to all at every boot, so
asking them to agree on an auth token format is perfectly
acceptable. But now the Android system doesn't have to care about the
format.
Bug: 32962548
Test: CTS tests pass, plus manual testing.
Change-Id: I78aa6e4ea9c5d8f34906b0969909387e2c5894e6
This is needed to support the keystore statistics gathering initiative.
It will allow us to get information about what kinds of keymaster
implementations exist in the ecosystem, and which ones fail in which
ways.
Bug: 36549319
Test: Will add to VTS tests
Change-Id: I49ee4623656060d69a6de7723b11cd715150451a
delete_key is optional and may not be implemented by
a legacy hal. So the function pointer must be checked for
nullptr prior to being used.
Bug: 36500704
Test: run VTS tests with legacy hal that does not implement delete_key
Change-Id: Ie51dd173314826ef260319153c7df96d88b8a42f
Discussions have shown that in addition to brand, device and product,
we should also allow devices to attest their manufacturer and model.
Bug: 36433192
Test: GTS com.google.android.gts.security.DeviceIdAttestationHostTest
Change-Id: I5a9fd839497976cdb1e44cbe4a2d5b7730732b4c
The getService() and registerAsService() methods of interface objects
now have default parameters of "default" for the service name. HALs
will not have to use any service name unless they want to register
more than one service.
Test: marlin boots
Bug: 33844934
Change-Id: I6533e4fe0e63e2d0b0158148f5e438bb4b6b5886
KeyStore.generateKey() takes an entropy parameter. This is optional
and can be null. That is how KeyStore used to work but a recent
refactor made us always feed the entropy to keymaster, even if it
is empty (null or byte[0] on the Java side). This CL makes us ignore
such empty entropy again.
We only noticed this because a recently added GTS test that happens
to set the entropy to null is failing on some hardware (other
keymaster implementations silently ignore this invalid attempt to
set entropy).
Bug: 35156555
Test: gts-tradefed run gts --module GtsGmscoreHostTestCases
--test com.google.android.gts.security.DeviceIdAttestationHostTest
Change-Id: Iadaf40e69350c17dd18e4dc2a1dab97fa911e1bf
We need google shims on the vendor partition because they are providing
an implementation of a vendor defined interface. They were written by
google just as a courtesy/to make the transition easier. They're
basically a set for vendors to assemble their hal implementations
from.
Bug: 34135607
Test: marlin persist.hal.binderization on/off
Change-Id: I2e2af5af39264cf290259755bb9b2eb9827a21f5
