On Thu, 20 Feb 2020 at 13:30, Sumit Garg sumit.garg@linaro.org wrote:
Hi Raghu,
On Thu, 20 Feb 2020 at 03:19, Raghu Krishnamurthy raghu.ncstate@icloud.com wrote:
Hi Sumit,
Thanks again. I looked through the implementation and it looks fine.
Thanks.
One thing that does not seem to be addressed is the question related to firmware update. How is the TF firmware update expected to work ? Does NS_BL1U require access to the decryption key ?
As per our earlier discussion on gerrit, I would expect BL1 to provide FWU_SMC_IMAGE_DEC_AUTH service.
Another thought on this, shouldn't NS_BL2U update complete FIP image as signed payload? In this case NS_BL2U authenticate complete FIP image using FWU_SMC_IMAGE_AUTH in one go. Also, this way updater doesn't need to be aware of any FIP parsing or this encryption feature.
Is there any specific use-case to authenticate each FIP payload individually during firmware update?
-Sumit
IIRC, the common alternative way for firmware updates is via UEFI capsule updates and a secure partition or a Trusted OS service could be leveraged for firmware authentication/decryption prior to flash update.
-Sumit
Thanks Raghu
On 2/19/20 3:51 AM, Sumit Garg wrote:
Hi Everyone,
I have tried to address most of the implementation concerns with updated patch-set [1] as follows:
*Concern*: Firmware encryption bit needs to be signed *Address*: Moved the firmware encryption bit from FIP ToC header to "io_uuid_spec_t" struct which is part of "plat_io_policy" that is embedded in the boot-loader (BL1 or BL2) and hence firmware encryption bit is signed.
Also, with this implementation fip_tool is no longer aware of encryption and just encrypted binaries are piped to fip_tool.
*Concern*: Capability to encrypt with different keys for different images *Address*: Passed "img_id" buffer reference as an argument of "plat_get_enc_key_info()" API. So that platforms may choose to either provide a unique key per firmware image or just derive a key from HUK per firmware using "img_id" buffer as a salt.
*Concern*: Coupling of FIP and encryption layer *Address*: Firstly I think we all can agree that encryption layer provides confidentiality protection specific to IO storage. Secondly FIP is actually a packaging layer that sits over actual IO layer and having the encryption layer coupled with FIP provides an abstraction layer for any FIP payload which in turn provides the following features:
- Allows the firmware certificates to be encrypted as well to protect
against cloning satisfying R050_TBBR_PROTECTION requirement. 2. Allows the firmware configuration data to be encrypted as well. 3. Provides a capability to have a secure key store as FIP payload which is protected using HUK.
*Concern*: Allow usage of alternative verify-then-decrypt method *Address*: A platform could disable this encryption layer and implement decryption as part of "bl2_plat_handle_post_image_load()".
Please let me know in case I missed any implementation concerns and feel free to provide your feedback on updated patch-set [1].
[1] https://review.trustedfirmware.org/q/topic:%22tbbr%252Ffw_enc%22+(status:ope...)
Regards, Sumit