Commit graph

6 commits

Author SHA1 Message Date
Janis Danisevskis
5a07ed4802 Switch to new NG AndroidKeymaster3Device
Test: VtsHalKeymasterV3_0TargetTest
Bug: 67358942
Change-Id: Idc7ac599c359b3af2e4866b9eb446a05e96132a0
2017-10-03 16:13:21 -07:00
Shawn Willden
031b6050b1 Revert "Add auth token parsing to IKeymasterDevice.hal"
This reverts commit 62f63c7ddb.

Reason for revert: b/36637075

Bug: 36637075
Change-Id: Ie0e8d0b480047a7c68f266e7e5d8a31722f85128
2017-03-28 00:44:17 +00:00
Shawn Willden
62f63c7ddb Add auth token parsing to IKeymasterDevice.hal
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
2017-03-24 22:22:34 -06:00
Shawn Willden
d4417fb982 Add digest support and implementation name to getHardwareFeatures
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
2017-03-25 02:09:14 +00:00
Bartosz Fabianowski
aac0fc739e Add device id attestation
This adds device id attestation to the Keymaster 3.0 HAL. Device
id attestation must only be offered if the device can permanently
destroy device ids on request. The default implementation cannot
do this because it lacks storage that would survive device wipes.
Hence, the implementation refuses all device id attestation requests.

Bug: 34597337
Test: CTS CtsKeystoreTestCases and GTS DeviceIdAttestationHostTest

Change-Id: I6ff6146fad4656b8e1367650de922124b3d7f7b2
2017-01-24 23:06:30 +01:00
Janis Danisevskis
0f35e5a013 Add default implementation for binderized Keymaster HAL and service
The default implementation loads the device's legacy keymaster hal
and wraps in a softkeymasterdevice if the capabilities of the
device is less than keymaster 2.

Test: builds
Bug: 32020919
Change-Id: Ia7e274673b77c2712c386d573715ed3725b0c158
2016-12-20 09:09:29 -07:00