History log of /hardware/interfaces/keymaster/3.0/IKeymasterDevice.hal
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
031b6050b17358538e27211c0cdb1021235290e5 28-Mar-2017 Shawn Willden <swillden@google.com> Revert "Add auth token parsing to IKeymasterDevice.hal"

This reverts commit 62f63c7ddbd08737e298a97975754225e5da0126.

Reason for revert: b/36637075

Bug: 36637075
Change-Id: Ie0e8d0b480047a7c68f266e7e5d8a31722f85128
/hardware/interfaces/keymaster/3.0/IKeymasterDevice.hal
62f63c7ddbd08737e298a97975754225e5da0126 17-Feb-2017 Shawn Willden <swillden@google.com> 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
/hardware/interfaces/keymaster/3.0/IKeymasterDevice.hal
d4417fb98233bf090755fb2eba580c8e33d1714b 23-Feb-2017 Shawn Willden <swillden@google.com> 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
/hardware/interfaces/keymaster/3.0/IKeymasterDevice.hal
aac0fc739eeee0e94cac113f3e37ebc878547341 23-Jan-2017 Bartosz Fabianowski <bartfab@google.com> 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
/hardware/interfaces/keymaster/3.0/IKeymasterDevice.hal
34d8809c7e61416820de2acb21b70ca914f6e622 12-Oct-2016 Janis Danisevskis <jdanis@google.com> Add interface definition for binderized Keymaster HAL

Test: accepted by hidl-gen
Bug: 32020919,32962548
Change-Id: Ib0decb231527e944e6b673017b721ea4601b7b2a
/hardware/interfaces/keymaster/3.0/IKeymasterDevice.hal