+ TF-A ML (for the benefit of other trying to use firmware encryption feature)
On Fri, 8 Oct 2021 at 00:09, pramod kumar email@example.com wrote:
This is Pramod, Presently working in Amazon Lab126. I'm working in ATF and was going through your patch which provides f/w image encryption/decryption support.
commit 7cda17bb0f92db39d123a4f2a1732c9978556453 Author: Sumit Garg firstname.lastname@example.org Date: Fri Nov 15 10:43:00 2019 +0530
drivers: crypto: Add authenticated decryption framework Add framework for autheticated decryption of data. Currently this patch optionally imports mbedtls library as a backend if build option "DECRYPTION_SUPPORT = aes_gcm" is set to perform authenticated
decryption using AES-GCM algorithm.
Signed-off-by: Sumit Garg <email@example.com> Change-Id: I2966f0e79033151012bf4ffc66f484cd949e7271
I see that this support comes under DECRYPTION_SUPPORT macro hence can't be used dynamically. I see the TBBR spec provides a flag for this which could be used to exercise this feature dynamically- [image: image.png]
Just wanted to understand that did you see any limitation to use this flag for making this feature support dynamically? Or do you have any plan to push follow up patches for this?
Actually there are security concerns associated if we use an unsigned encryption flag in the header (see earlier discussions ).
If this feature is made available, with the help of "disable_auth" flag, BL1 would be able to boot plane images even when TRUSTED_BOARD_BOOT is enabled in development mode.
I agree here that it would be useful to have such a flag in development mode. For TRUSTED_BOARD_BOOT in development mode, I guess you are referring to DYN_DISABLE_AUTH. If yes then I think such a macro makes sense for encryption as well in order to disable decryption at runtime in development mode, patches are very much welcome.