bootutil/crypto: Handle hashing errors and refactorings#2579
Conversation
kkrentz
requested review from
almir-okato,
davidvincze,
de-nordic and
nordicjm
as code owners
kkrentz
force-pushed
the
hashing-pr
branch
7 times, most recently
from
11cd7cc to
59140a8
Compare
kkrentz
force-pushed
the
hashing-pr
branch
4 times, most recently
from
27a1a66 to
7298a73
Compare
d3zd3z
left a comment
d3zd3z
left a comment
There was a problem hiding this comment.
So, this will need to be rebased on a recent version to be workable. I apologize for missing it back when it was fresher.
Some concerns here:
- The included target where error handling might make sense (cc310) doesn't return status on it's hash functions. Presumably, this Pr is to support out of tree HW devices?
- The new
bootutil_sha_finishdoesn't have any testing. Admittedly, this is probably best checked by inspection, though.
| uint8_t tag[BOOTUTIL_CRYPTO_SHA256_DIGEST_SIZE]; | ||
| uint8_t tag[IMAGE_HASH_SIZE]; | ||
| uint8_t shared[EC_SHARED_LEN]; | ||
| uint8_t derived_key[BOOT_ENC_KEY_SIZE + BOOTUTIL_CRYPTO_SHA256_DIGEST_SIZE]; |
There was a problem hiding this comment.
Is there a concern about still having the SHA256 digest size here?
There was a problem hiding this comment.
Thank you for your review. The new bootutil_sha_hmac creates tags of length IMAGE_HASH_SIZE. Nevertheless, we could leave BOOTUTIL_CRYPTO_SHA256_DIGEST_SIZE because the encryption and signature mechanism must share the same hash function. On the other hand, I now chose to declare tag more appropriately as uint8_t tag[EC_TAG_LEN]. Besides, I added an assertion to ensure that the encryption and signature mechanisms are sharing the same hash function.
kkrentz
force-pushed
the
hashing-pr
branch
2 times, most recently
from
377be1d to
083f12b
Compare
The current API actually requires checking each call to bootutil_sha_init, bootutil_sha_update, bootutil_sha_finish, and bootutil_sha_abort for errors. This would result in a lot of clutter and is not done at the moment. This commit wraps these functions so as to silently ignore subsequent calls in a series upon errors. As a result, only bootutil_sha_finish needs error checking. Signed-off-by: kkrentz <konrad.krentz@gmail.com>
This simplifies the API for generating HMACs and deriving keys. Signed-off-by: kkrentz <konrad.krentz@gmail.com>
This introduces a shorthand for doing bootutil_sha_init, bootutil_sha_update, and bootutil_sha_finish at once. This simplifies matters in bootutil_find_key. Besides, there was no error handling in bootutil_find_key, which is also fixed. Signed-off-by: kkrentz <konrad.krentz@gmail.com>
Using the currently configured crypto back end, this implements HMAC and HKDF. This implementation serves as a fallback solution for crypto back ends that do not provide these functions. As there are plans to remove TinyCrypt from MCUboot, no effort is made to use TinyCrypt when MCUBOOT_USE_TINYCRYPT is set. Instead, this configuration falls back on the general-purpose HMAC and HKDF implementations. Signed-off-by: kkrentz <konrad.krentz@gmail.com>
Thus far, hashing errors were silently ignored when hashing images. Signed-off-by: kkrentz <konrad.krentz@gmail.com>
If Mbed TLS is configured to leverage HW acceleration, this might cause issues in MCUboot. However, I did not track this down. Anyway, I would like to have error handling to make proper use of the HW acceleration of my TI chips. |
2 participants
This PR complements invocations of hashing-related function with error handling. This is important in various occasions, such as when verifying the signature of an image in "pure" mode. In this case, an error during hashing may cause the computed hash digest to become the all-zero string. However, an arbitrary ECDSA signature over the all-zero hash digest will turn out authentic.
Also, this PR adds a new file called
sha.c, which encapsulates shorthands for common invocation patterns of SHA and HMAC, as well as an HKDF implementation. This simplifies matters in other files and having HKDF at a reusable place helped us integrate TCG's Device Identifier Composition Engine with MCUboot, too. This is because DICE uses the "expand" subroutine of HKDF.Besides, this PR makes HMAC available regardless of the crypto backend. Currently, only mbedTLS and TinyCrypt provide this function, thereby limiting firmware encryption to configurations with one of these crypto backends.