On 27/01/2020 12:34, Joakim Bech via TF-A wrote:
on raw binaries are there so we can be sure that we're loading unmodified firmware coming from the one owning a private key corresponding to the public key hardcoded into the device (or via a hash of the public key). I think we all can agree
OK, I have finally managed to catch up on this thread. Apologies for the delayed response.
As Joakim mentions, I think both the mentioned cases ie. encrypt plain text -> sign and sign -> encrypt are valid and it depend on the threat model and security requirement.
I have had a brief look at the patch stack and coupling the feature to the FIP does not seem like a good idea to me( + the added complexity protecting the ToC). Currently meta data of the firmware images is passed OOB via the `bl_mem_params_node_t` descriptor to the BL images whereas this patch breaks that convention. It is better to follow the set convention and avoid dependency on FIP format (btw platforms need not use FIP format and can use other packaging formats).
The iv data to decrypt seems to be prepended to the encrypted file in the fip which is making custom manipulations file pointer manipulations which is raising some red flags.
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/8/driver...
IMO, this should not visible to be FIP driver. I am not sure of the best practice for sending iv data but if it has to be prepended, it should be FIP agnostic.
The TBBR assumes a single owner for all images whereas the TBFU supercedes this spec by allowing multiple owners for different images. We are in the process of enhancing the CoT for different Root of Trusts for different images and there needs to be capability to encrypt with different keys for different images based on ownership. The current implementation has some limitations like introducing a platform API invocation within the driver layer to get the single key which is not ideal IMO.
I haven't fully flushed out my ideas, but thoughts are based on enhancements done by Masahiro for adding decompression support for BL images. See https://github.com/ARM-software/arm-trusted-firmware/pull/1224 .
Basically, this patch series allows any filter to be setup before/after the images are loaded. It relies on pre-load and post load hooks which are platform specific to perform the filter operation. So, if a new image attribute `EP_ENCRYPTED` is added ep_info_exp.h, then BL2 needs to do the following in bl2_plat_handle_pre_image_load() { if EP_ENCRYPTED is set : load the image to SRAM and decrypt using crypto module }
This will cater for `decrypt-then-authenticate` flow.
The fip_tool no longer needs to be aware of encryption and the build process just needs to pipe the encrypted binaries to the fip_tool.
Similarly if `authenticate-then-decrypt` needs to be supported, then all that the platform needs to do is implement decrypt in bl2_plat_handle_post_image_load().
The platform can now use different keys to use for different BL images if it needs to do so.
Some usecases require the firmware images to be re-encrypted using HUK after firmware update (aka firmware binding) and following this design will allow this to be done as well.
Best Regards Soby Mathew