deffcb7efaac94b2c674247cb9888a0af3d7e256 |
|
08-Jan-2018 |
Shawn Willden <swillden@google.com> |
Move Key into Operation The Keymaster implementation creates a Key object and then passes it to an Operation object, which copies parts of it. The Key object is not needed after the Operation has been created, so much of that copying is unnecessary. This CL begins changes that by passing an rvalue reference to the Key to the Operation, and modifying operations so they move the pieces of the Key that they need out, wherever possible. Test: make (local unit tests), VTS and CTS Change-Id: I6c9a27d9ee85ccaeed1efb0fcc3ed0f8694c5771
/system/keymaster/legacy_support/ecdsa_keymaster1_operation.h
|
ed45c3c8bab0de7d974c801ec553e8927aa678d9 |
|
08-Jan-2018 |
Shawn Willden <swillden@google.com> |
Fix potential DoS on devices with old keymaster1 hardware. The Keymaster1 specification allows implementations to provide less than the full suite of digest algorithms. At minimum they need only provide SHA256. If keystore detects that keymaster1 hardware provides less than a full set, it creates a software keymaster wrapper around the hardware. If an operation requests a digest algorithm that the hardware does not support, the wrapper performs the digesting in software and passes the pre-digested data to the hardware for the final operation. Each of these two keymaster instances (the software wrapper and the wrapped hardware) manage their own operation table. The hardware needs its table to figure out which in-progress operation to update or finish. The software wrapper needs its table to figure out which hardware operation handle to forward to the hardware for update or finish. Note that the software wrapper's table is only used for operations that require software digesting. The bug causes the software wrapper to fail to remove entries from its table when they're completed. After 16 such operations the table is full, preventing any future operations from being started until the device is rebooted. Test: CTS Bug: 71703554 Change-Id: Ifc1e2a9af9532e6a8f1cd3d0ad3ca079f126a0b7
/system/keymaster/legacy_support/ecdsa_keymaster1_operation.h
|
dc877aea40979bb5a18206cd9cec7bb4f31442e2 |
|
15-May-2017 |
Janis Danisevskis <jdanis@google.com> |
UniquePtrize Operations Have Operations handled by UniquePtrs. Also add keymaster::remove_reference and keymaster::move to express proper move semantics without requiring stl. Test: VtsHalKeymasterV3_0TargetTest Bug: 67358942 Change-Id: I2b1802835316daa93e424c1ce1f49a03d00d93ff
/system/keymaster/legacy_support/ecdsa_keymaster1_operation.h
|
f3dc0b841da2c8938e4a8081ef6c6199ed92c876 |
|
15-May-2017 |
Janis Danisevskis <jdanis@google.com> |
Moved operation handle generation into the begin operation I moved the generation of a operation handle into the operation implementation. Random number generation is highly implementation dependent, and the bookkeeping of operations is very generic. An AndroidKeymaster implementation that uses another legacy keymaster implementation does not need either. But while the bookkeeping is very lightweight and self contained, the random number generation pulls in dependencies (here openssl) which are not needed. Therefore, I decided to move the generation of operation handles out of the OperationTable (bookkeeping). And into the begin operation, where dependencies to crypto functionality already exists. Edit: This patch now also includes the fix for Bug: 65286954 Previously fixed by CL: I320c5d03911942e873680ba0d7ea91044920e936 Bug: 65286954 Test: VtsHalKeymasterV3_0TargetTest Bug: 67358942 Change-Id: Idd27915e4f3db816d3257144fb9e1c664920ffba
/system/keymaster/legacy_support/ecdsa_keymaster1_operation.h
|
f54cc93ccf57a94f9a2c660dbf3e06494adf178d |
|
11-May-2017 |
Janis Danisevskis <jdanis@google.com> |
Reorganize keymaster directories Keymaster files have been reorganized into the following directories - android_keymaster The core android keymaster logic including some utilities that have no special libray dependencies - km_openssl Openssl based implementation primitives of android keymaster. These primitives can be used to implemented an openssl based software implementation of AndroidKeymaster. - legacy_support Primitives implemented in terms of older keymaster hal version. These primitives can be used to implement AndroidKeymaster in terms of keymaster 0 or 1 hals. They are used to provide wrappers around old keymaster hals, filling in missing features with software implementations. - contexts Implementations of various contexts from pure software to legacy hal hybrids. - key_blob_utils Support code for formatting keymaster key blobs including support for legacy android keymaster blob formats. Test: VtsHalKeymasterV3_0TargetTest Bug: 67358942 Change-Id: Ia8eacd301a5c5fa5f5f625caafcec5d07e168249
/system/keymaster/legacy_support/ecdsa_keymaster1_operation.h
|