| Age | Commit message (Collapse) | Author |
|---|
|
This CL does not yet take advantage of the simplifications that allowing
input to finish() provides. That will require updating the Java layer
first, to remove some assumptions and code that assume update() must
eventually consume all input.
Change-Id: Ie85896027a1d55ddec06750d19addbb1f5e462c8
|
|
Change-Id: I30f4851399808c44f1af281e87acbe3e162ad3d0
|
|
Change-Id: I23acaee5dbbb7d8b6f7ada63d18291c6858f4ead
|
|
Bug: 22914603
Change-Id: I7650f1b691665bce3024556c2ea38e122c9cb2cf
|
|
Attestation is still not wired up in SoftKeymasterDevice, so we can't
test it yet. Unit tests will come with the CL that wires it up.
Bug: 22914603
Change-Id: I706c8f82e97f4d6c3b5d3726a266ba8d0175396b
|
|
This CL also implements the necessary context bits for
SoftKeymasterContext, in a necessarily completely insecure way. The
software attestation intermediate key and intermediate and root
certificates are hardcoded. Software attestation is meaningless, but
needed to make the APIs work the same for both software and hardware.
Bug: 22914603
Change-Id: I1c3439409829c0991db2f0b54e11fb59b5e9bd87
|
|
Bug: 22914603
Change-Id: I6f21da2bd7050519dd2b58a10ecacfef71d174c4
|
|
This refactor separates declaration and definition of the tag
instances, so they don't get duplicated in every compilation unit.
Also, if tag names are enabled it provides a dynamically-generated map
from tags to names. This is only for testing/debugging use, but it's
very convenient for that. The test utils are updated to take advantage
of it.
Change-Id: I13ad2564e4a850c6b268a2cd1b3f5a37037ea6b7
|
|
Change-Id: I2b6731aaacc3e45aebf6cbaa63155762cfeeb9b8
|
|
This CL adds a keymaster2 API to SoftKeymasterDevice. It just
delegates to the keymaster1 implementation, and will return errors if
any keymaster2 features are used. This will allow conversion of
keystore to the keymaster2 API, after which the keymaster1 API will be
removed from SoftKeymasterDevice (though it will still be able to wrap
a keymaster1 hardware implementation).
Note that this CL does not update the unit tests to test the
keymaster2 interface. That will come in a future CL.
Change-Id: I2efd696d733c99e916f98ae68586310d3b2abf78
|
|
Change-Id: Idfa0ef92119317794921e1bf5089a153bcbf71ca
|
|
Bug: 25166155
Change-Id: Ibaf0ef42744094b2dde26539e8f51d381061eb1e
|
|
SoftKeymasterDevice was incorrectly directly sending deletion requests
to wrapped hardware. In some cases the key blob passed in by
SoftKeymasterDevice is a hardware blob encapsulated by a wrapper, and we
need to remove the encapsulation before passing it on.
Bug: 25676862
Change-Id: Ic315c6b08d9ec15aa0be8f28f485a221bc7f1135
|
|
Change-Id: I5af3215e96bb015049574aa18327cd7f7499dbd3
|
|
curves."
This reverts commit 41998988331ff38e922a59ef008896beb3145ba0.
Change-Id: Ifed6b4e5a69310770373a396271f02da5c9d8934
|
|
Change-Id: Iea5877eba0a9b13610d3d1b33d04b5657edc3550
|
|
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
|
|
KM_DIGEST_NONE and KM_PAD_NONE have implicit meanings of "any digest"
and "any padding", respectively, as well as the expected meanings of "no
digest" and "no padding". This CL changes that so they mean only "no
digest" and "no padding".
Bug: 22556114
Change-Id: I7b0b4c079067d85ba1aa39ae7edf0c6b17a9a500
|
|
HMAC and AES-GCM keys must be bound to a mininum MAC/tag length at
creation, and operations may not specify a length smaller than the
minimum, or provide a length smaller than the minimum during
verification.
Bug: 22337277
Change-Id: Id5ae2f4259045ba1418c28e9de8f4a47e67fd433
|
|
Bug: 22294523
Change-Id: Ifab60b904e37c7ecca0b8138817af3d3b48199c0
|
|
Note: Moving List.h into system/keymaster is unfortunate, but required
to allow Trusty to use it. b/22088154 tracks cleaning this up.
Bug: 19511945
Change-Id: Ia1dfe5fda5ea78935611b0a7656b323770edcbae
|
|
Bug: 22077675
Change-Id: I29f4a913abc485b5b80cae5eb1eb9914fa6802a5
|
|
Bug: 21888473
Change-Id: Iafd7e6dbb3d7a36ad9dbad279e501fdfb26f812a
|
|
Bug: 22008538
Change-Id: I096cd977b34e9767845aaeece2da5f04c7fc86fe
|
|
Android is built with exceptions disabled, but "operator new" and
"operator new[]" still throw std::bad_alloc on failure rather than
returning new. In general this is a good thing, because it will cause
an immediate crash of the process rather than assigning a null pointer
which is probably not checked. But most memory allocations in Keymaster
are checked, because it's written to run in an environment where new
does *not* throw. This CL updates the code to explicitly use the
non-throwing new.
A handful of throwing news remain, but only in places where a crash on
failure is appropriate.
In addition, this CL also inserts buffer wrap checks in key locations
and changes the development-machine Makefile to build in 32-bit mode, to
make memory problems more apparent.
Bug: 21888473
Change-Id: I8ebc5ec12053e4f5274f6f57ce312abc10611cef
|
|
This brings KeymasterEnforcement up to date and cleans it up, making the
code more consistent with the rest of keymaster. It also makes it
possible to use from Trusty, by virtualizing some time-related functions
that don't work the same in Trusty-land.
Bug: 19511945
Change-Id: I1141c953f227f3ef8a78751d9f04bf4e4922d1f5
|
|
Methods with simple argument or return types eschewed message objects,
but this complicates the TrustyKeymaster implementation by requiring it
to build its own system for marshalling and unmarshalling.
Bug: 14674558
Change-Id: I5a88523c9d1a76c8629ff6f93040ceb3c2a9426b
|
|
Also, handle AAD correctly.
Bug: 21786749
Change-Id: I26a413f39daf3bd946ed494c7c3b5c6f559fb30b
|
|
Bug: 21593823
Change-Id: Id9ed06b1c6805b1cff36577910715eda7727eef4
|
|
Change-Id: I14498aa57b375f045ea8bcf2122660b64a0554d7
|
|
Change-Id: I8472a75ea60c73794ce31cacab9bcaad8482358f
|
|
Change-Id: I5f6ee245259788cb8c873d814e167f5d5bcdc08b
|
|
Change-Id: Ia9586684f8abd5678f8fb07daf262dc9696f665e
|
|
The keymaster0 signing API includes a void* to a structure that depends
on key type (RSA or EC). Previously we've tried to determine what the
key type is and to extract proper parameters, by calling
get_key_characteristics and examining the result. But this is all
pointless. The possible contents of that signing structure is fixed, so
we may as well just set the values directly. This does mean that we set
KM_TAG_PADDING for EC keys, even though ECDSA doesn't use padding.
That's okay, though. Keymaster1 implementations should ignore
extraneous tags. And in any case, we'll soon stop even providing the
keymaster0 APIs, so the issue will disappear.
Change-Id: Id4ee756dedc716978323767d51b4e3db357da662
|
|
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
|
|
I should have known better than to make these singletons to begin
with. Globals create problems. This undoes that mistake.
Change-Id: Idf61d5f72e3c34b5c4ddb27cc94b05f506561743
|
|
Bug: 20912868
Change-Id: I515a125f1247357d2cd9b4633c3b223590848093
|
|
The previous way had a problem when used in statments like:
if (foo)
LOG_D(...);
When built without debugging, this became:
if (foo)
;
Which is sort of okay, but the compiler complains. The new way also has
the advantage that the compiler always sees and checks the log
arguments. Given that it ends up compiling something like:
do {
if (0)
Logger::Debug(...);
} while (0);
It should optimize the entire block out, and should even discard the
literal string used for the format. So it's better all around.
Change-Id: I895141077f627a2d08dcb0d7d2d0799067a2c957
|
|
This reverts commit 13fbe3e93247943c26e7ca2ed27b6d650282b8bf.
Bug: 20912868, 19799085
Change-Id: Iadd6ce5cbe94956c2a2fe277f1bf5b108e4bcf57
|
|
This reverts commit 8ba2a043f0d44ad3f58d4af518f9391c03eca9c3.
I need to update the Volantis non-secure code in sync. Reverting while I get that done.
Change-Id: I0fb9f928e7e624ad678050a04bb873b43b1c9a48
|
|
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
|
|
So we can do it differently in the keymaster0 adapter.
Bug: 20912868
Change-Id: If4c602cc0fab3e59cd2e395a97e21dd8cb3a176f
|
|
Change-Id: I05de61353fc806b90232fab7c1d1cf76aefa35fc
|
|
Change-Id: Ia8e36e41e04f15befccbb7b4138f599849facd28
(cherry picked from commit 0c14b2c5f42abdab58118106d5a7117a88d4a324)
|
|
Bug: 20917242, 19509156
Change-Id: I5b3509bea78754192f0d5e2a76de24621fc43621
|
|
Bug: 20917242
Change-Id: Ifd1d64e67f85ee42caae768c4512804bbbe20ad0
|
|
This created a build breakage in Trusty, and so was reverted in AOSP. Reverting here to sync.
This reverts commit 4749c43a3b4f48be951924fb473e1fcd0279c508.
Change-Id: I9473f58ace295d9454693759c88c85fe9f70ae01
|
|
Change-Id: I66162b4e4e2cdc2e8ba78fd7a0b76a8f72d430dd
(cherry picked from commit f61d93895db9a7ca073a774500ca63b0055e3657)
|
|
Bug: 20559317
Change-Id: I65c5886b449ec416e5e8a4aa7e5dc9bc5cc517d9
|
|
Padding and digest are now repeatable, so it doesn't make sense to have
builders that take only one. MAC length is also no longer a key
characteristic, so it doesn't belong in the key builders.
Bug: 19509156
Change-Id: Ie4d524ef2c46a0dd62a628d95bed456bcf85a4f3
|
