History log of /system/keymaster/asymmetric_key.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
aa58329b5bc3b30c6a01221b2a89808ebf347650 28-Jan-2016 Shawn Willden <swillden@google.com> Revert "Revert "Add attestation support to Key classes.""

This reverts commit 722d8a41268d9a6819b27d217b177709571b5548.

Change-Id: If085e5e9a9b77763420d9c7883414a4ca368d2b2
/system/keymaster/asymmetric_key.h
722d8a41268d9a6819b27d217b177709571b5548 28-Jan-2016 Shawn Willden <swillden@google.com> Revert "Add attestation support to Key classes."

This reverts commit 4d0465999644336d636442a86795293298b22035.

Change-Id: I53d386e0d95c25e794ef88801d80e80ccfeea768
/system/keymaster/asymmetric_key.h
4d0465999644336d636442a86795293298b22035 06-Jan-2016 Shawn Willden <swillden@google.com> Add attestation support to Key classes.

Also make it a bit easier to define pointers to OpenSSL types.

Bug: 22914603
Change-Id: Iccfe04a58e7d5e45f0dc0e83b72856fcb04e83f0
/system/keymaster/asymmetric_key.h
d599b15c0693950bdc72fb867872044fdc484ef5 28-Jul-2015 Shawn Willden <swillden@google.com> Do digesting, and sometimes padding, in SW when HW doesnt.

The keymaster1 specification only requires HW modules to implement
SHA256 out of the list of keymaster1 digest modes. That would force
many keys to be software only, and would break legacy scenarios. This
change uses SoftKeymasterDevice to front keymaster modules that don't
implement the full suite of digests, quietly inserting KM_DIGEST_NONE
and KM_PAD_NONE into key generation/import requests when necessary, then
performing the digesting, and sometimes padding, in software, then
delegating crypto operations to the hardware.

This is only done for RSA and EC keys. Software digesting isn't
possible for HMAC or AES-GCM keys.

Note that this is not the complete fix for the bug. Some changes in
keystore are also required, coming in another CL.

Bug: 22529223
Change-Id: I740572eb11341fb0659085309da01d5cbcd3854d
/system/keymaster/asymmetric_key.h
398c158a0206217025f327c2d26bb6c86659f5a0 28-May-2015 Shawn Willden <swillden@google.com> Move assymetric key factory declarations to includes.

This exposes EcKeyFactory and RsaKeyFactory so they can be used for
constructing the Trusty KeymasterContext. Note that there are no code
changes, just reorganization.

Change-Id: I8e8e068fb875f9d9c5c35320a545347dc33bc507
/system/keymaster/asymmetric_key.h
0629810b145187575bc26c910dded0d24c64569d 26-May-2015 Shawn Willden <swillden@google.com> Another refactor, deleting AbstractFactoryRegistry.

I should have known better than to make these singletons to begin
with. Globals create problems. This undoes that mistake.

Change-Id: Idf61d5f72e3c34b5c4ddb27cc94b05f506561743
/system/keymaster/asymmetric_key.h
0cb6942d3efb6c056f96321c82a4b3d86af601d6 26-May-2015 Shawn Willden <swillden@google.com> Revert "Revert "Large refactor to move context out of AndroidKeymaster.""

This reverts commit 13fbe3e93247943c26e7ca2ed27b6d650282b8bf.

Bug: 20912868, 19799085
Change-Id: Iadd6ce5cbe94956c2a2fe277f1bf5b108e4bcf57
/system/keymaster/asymmetric_key.h
13fbe3e93247943c26e7ca2ed27b6d650282b8bf 23-May-2015 Shawn Willden <swillden@google.com> Revert "Large refactor to move context out of AndroidKeymaster."

This reverts commit 8ba2a043f0d44ad3f58d4af518f9391c03eca9c3.

I need to update the Volantis non-secure code in sync. Reverting while I get that done.

Change-Id: I0fb9f928e7e624ad678050a04bb873b43b1c9a48
/system/keymaster/asymmetric_key.h
8ba2a043f0d44ad3f58d4af518f9391c03eca9c3 18-May-2015 Shawn Willden <swillden@google.com> Large refactor to move context out of AndroidKeymaster.

AndroidKeymaster made a number of assumptions about its context that are
really only valid for TEE-based usage. In addition, KeyFactory made
some similarly TEE-focused assumptions about key blob creation and
parsing.

Both concerns have been moved to a new KeymasterContext class, which is
responsible for building and parsing key blobs in a manner appropriate
for the context in which AndroidKeymaster is running, as well as
providing other context-specific services, such as random number
generation.

In addition, the refactor reduces the need for the KeyBlob and
UnencryptedKeyBlob classes, which encode too many assumptions about blob
formatting and encryption, to the point that they can be removed and
replaced by a handful of utility functions which are much cleaner and
more flexible.

How to review this CL:

I looked hard at breaking this up into smaller CLs, but it's mostly not
feasible. However, it's probably easier to approach it by starting with
the fundamental changes, and then looking at the cascade effects.

1. Look at keymaster_context.h. The core of the change was pulling this
set of features out of AndroidKeymaster. Note that the revised approach
to key blob creation does not involve the KeyBlob and UnencryptedKeyBlob
classes, but instead goes directly from raw key material plus ancillary
data (e.g. auth sets) to a serialized buffer ready to return to
keystore. The same is true in reverse direction for parsing key blobs.

2. Look at key.h. The revised KeyFactory GenerateKey, ImportKey and
LoadKey methods are essential. GenerateKey and ImportKey no longer
produce a Key object, because all that's needed is a returnable blob.
LoadKey produces a Key object, but it starts with raw key material,
rather than an UnencryptedKeyBlob. Also note the change to the Key
class; because Key objects are only created by LoadKey, when there's a
need to use a key, there's only one constructor.

3. Look at asymmetric_key.h, rsa_key.h and rsa_key.cpp. rsa_key.cpp
provides a good example of how the new structure works. GenerateKey and
ImportKey do all of the work necessary to produce an OpenSSL RSA key and
extract the internal representation (using EvpToKeyMaterial; defined in
asymmetric_key.h because it's the same for EC keys). Then, with the raw
key data in hand, they call KeymasterContext::CreateKeyBlob to wrap the
key data in a key blob that can be returned to the caller -- whatever
that wrapping means in the current context. There's a subtlety not
apparent here which is crucial to the rationale for the refactoring:
RsaKeyFactory uses KeymasterContext::get_instance to retrieve the
context, but key factories which depend on operating in a particular
context can use a different way to get their context object, which may
have a larger interface. RsaKeymaster0KeyFactory will do this.

4. Look at soft_keymaster_context. In
particular, SoftKeymasterContext::CreateKeyBlob and ParseKeyBlob.
CreateKeyBlob allocates authorization tags from key_description to
hw_enforced and sw_enforced, then encrypts the key material and
serializes it to a blob. This approach is compatible with the keys
softkeymaster has been producing, but I'm going to change it (post M),
because there's no reason to bother encrypting SW keys with a SW key.
ParseKeyBlob reverses the process to recover the unencrypted key
material and the auth lists. One debatable point was the decision to
implement BuildHiddenAuthorizations and SetAuthorizations here, since
all contexts will need something similar, and they really should all do
it the same. I may refactor later to pull that functionality up to
KeymasterContext; it will depend on what I learn implementing
TrustyKeymasterContext and HybridKeymasterContext (used for the
keymaster0 adapter).

5. Look at ocb_utils and auth_encrypted_key_blob. These contain the key
encryption and key blob serialization code which was formerly split
between AndroidKeymaster::SerializeKeyBlob, UnencryptedKeyBlob and
KeyBlob, now divided into separate encryption and serialization
utilities. Note the refactored key_blob_test.cpp, updated to use the
new utilities rather than UnencryptedKeyBlob.

6. Look at soft_keymaster_device.cpp. Since KeyBlob no longer exists to
provide a nice way to peer into a blob to extract the algorithm, for use
in determining how to parse the keymaster0 signing key params (which
come in as a void*, yuck), we now have to use get_key_characteristics to
recover the params. This was the right way all along; the device layer
should not depend on being able to parse key blobs.

7. The rest.

Bug: 20912868, 19799085
Change-Id: Ieb74b8da39974f674eb8baa959bde75011fdd2e8
/system/keymaster/asymmetric_key.h
4d306ec792b4348253aa77dff965bff5def1dccb 04-Mar-2015 Shawn Willden <swillden@google.com> Factor PKCS8 to EVP conversion out of AsymmetricKey.

Bug: 19508876
Change-Id: I7d5a7363a43c47dc33b0de53040b593de096e1c3
/system/keymaster/asymmetric_key.h
567a4a04f43d35b785d50508e6459b01f2ab4d14 31-Dec-2014 Shawn Willden <swillden@google.com> Switch to using global logger

Change-Id: I7af02342320a9a431cd9845baaf5dbcf61d460c2
/system/keymaster/asymmetric_key.h
a278f6156b9e57e1de8ca380b14fef113ad10be8 23-Dec-2014 Shawn Willden <swillden@google.com> Refactor key creation to use a registry of key factories.

Change-Id: I6ebab7b44e4a5dbea282397ab8aca437e71bdca0
/system/keymaster/asymmetric_key.h
96599217f08532912bc0e26c1887549f6130669a 26-Sep-2014 Shawn Willden <swillden@google.com> Push padding and digest handling down to specific key types.

AsymmetricKey handled checking for digest and padding, but that doesn't
make sense because not all asymmetric key types need both. This is in
preparation for adding asymmetric encryption/decryption support.

Change-Id: I7b9a4fc37b6d31ab25c56015c1df7d114affe882
/system/keymaster/asymmetric_key.h
2c8dd3e93d66fed41561933105e6050ff0655d76 18-Sep-2014 Shawn Willden <swillden@google.com> Refactor: Separate asymmetric key types.

Change-Id: I3368798a8ecea319bb0bfcd6ff24e9a7b6287c80
/system/keymaster/asymmetric_key.h
658d7a69a20e9c570df0a7fb08ee98412a9bf74e 18-Sep-2014 Shawn Willden <swillden@google.com> Use calculate_key_size_in_bits method, rather than duplicating
calculation.

Change-Id: Id94a8856589945dda36a2302b9494e834217db04
/system/keymaster/asymmetric_key.h
72014adef83b0346859dbe82d77b09b4756d8e64 17-Sep-2014 Shawn Willden <swillden@google.com> Refactor KeyBlob to separate encryption functionality.

This CL is in preparation for another which will refactor libkeymaster
into libkeymaster and libkeymasterclient, the latter for use by programs
which merely interface with keymaster and don't do any crypto on their
own, but do need to parse key blobs to extract authorization list
entries. To make that possible it moves KeyBlob's key encryption and
decryption capabilities into a subclass, PlaintextKeyBlob.

Change-Id: Ic6a65b6f237c122796ea70458655111316f902d8
/system/keymaster/asymmetric_key.h
81effc68a04810b76f0b10594d92df4ffbf35c6c 27-Aug-2014 Shawn Willden <swillden@google.com> Finish key import implementation.

This is the last bit of GoogleKeymaster that remained incomplete (for
the v0.3 functionality).

Change-Id: I27be52ae032883c004b2df21f0c7b229af512922
/system/keymaster/asymmetric_key.h
2f3be368e5ad911cc0b014421dd3682130260ffc 25-Aug-2014 Shawn Willden <swillden@google.com> Add the beginnings of logging infrastructure.

Change-Id: Ic36134402bfbb098d2242c463a3b4265d1d65209
/system/keymaster/asymmetric_key.h
437fbd195e7de57b7dc0c449c04458bd90ef50de 20-Aug-2014 Shawn Willden <swillden@google.com> Add key importing, RSA only.

Change-Id: I639e797939a28b2b2a815541c9926dc194657c54
/system/keymaster/asymmetric_key.h
f268d742dbefe0e84b4046db7669c4ffbc110f7d 19-Aug-2014 Shawn Willden <swillden@google.com> Refactor export to use new key infrastructure, and work with all key types.

Change-Id: Ie1f621f9db855665d57cde93c24881415de33ca2
/system/keymaster/asymmetric_key.h
d67afae61f822463120c36fea846362450dd7d71 19-Aug-2014 Shawn Willden <swillden@google.com> Refactor key and operation details.

Change-Id: I80267e6184955ecd98b08ceab91f4afd50c67614
/system/keymaster/asymmetric_key.h