tree 18f947e7cbdbaeebfc7faf50b2774ba08570160e
parent 7786f5cda66bab63dfe49eba81c2ed485d3c67dd
author Shawn Willden <swillden@google.com> 1505958672 -0600
committer Shawn Willden <swillden@google.com> 1505958672 -0600

Fix handling of auth-per-op keys and software digesting

When keystore is using a keymaster1 hardware device that does not
implement all digest algorithms (as allowed by the KM1 spec), keystore
does digesting in software and uses the underlying keymaster1 hardware
to perform the core cryptographic operation.

When auth-per-operation keys (i.e. fingerprint-bound keys) are used, a
keymaster operation is created and associated with an "operation
handle" (64-bit integer).  This handle is embedded in the authentication
token generated by the fingerprint matcher, which is what "unlocks" the
key for that one operation.

When those two situations are combined, the SoftKeymasterDevice which
wraps the hardware was caching the keymaster-generated operation handle
for use in completing the operation, but generating its own operation
handle which it returned to keystore.  So the software layer's operation
handle got embedded in the auth token and when that auth token was
presented to the hardware, the hardware refuse to accept it, since it
did not contain the hardware's operation handle.

The fix is to have the software wrapper use the underlying hardware's
operation handle.

Bug: 65286954
Test: Manually tested with app linked on above bug
Change-Id: I320c5d03911942e873680ba0d7ea91044920e936