On Tue, Aug 25, 2020 at 1:57 AM Philippe REYNES philippe.reynes@softathome.com wrote:
I agree that IV should be set in the FIT.
So in the dts, we may have: cipher { algo = "aes256"; key-name-hint = "aeskey"; iv = "aesiv"; }; or (I propose) : cipher { algo = "aes256"; key-name-hint = "aeskey"; iv-name-hint = "aesiv"; iv-in-fit; };
I think that both solution should work ...
Have you planned to implement this change/feature ? (otherwise I will try to found some time for it, it is a really nice improvement).
Hi Philippe,
here is what I had in mind, in the .its we would put:
cipher { algo = "aes256"; key-name-hint = "aeskey"; };
when mkimage processes this it opens /dev/urandom to generate a unique IV. It then uses this IV to perform the encryption and writes it IV to the .fit image like so:
cipher { algo = "aes256"; key-name-hint = "aeskey"; iv = <0xa16e090c 0x7e116bf8 0x75c44329 0x3278c74d>; }
I don't think there is a need for a "iv-in-fit" property and "iv-name-hint" can be deprecated.
However, if adding "hashed-nodes" and "hashed-strings" properties to the image signature is acceptable we can still support signing ciphered images with no problems.
I think that everything should be added to the signature. I think it's simpler and more safe.
Have you planned to implement this/propose a patch please ? (of course, if not, I will try to found some time)
Unfortunately right now it is crunch time at $DAYJOB to meet a deadline by the end of September, so I don't have much (if any) time to dedicate to working on U-Boot right now.
There are actually five issues on my list to address in U-Boot/mkimage:
* mkimage needs to generate encryption IV using /dev/urandom * FIT image signatures need to include cipher node * AES-GCM cipher support * mkimage -B option doesn't zero padding bytes * mkimage -B option unnecessarily pads the end of the image
I was planning on working through these when I get time, but I have not started on any of them yet. So, if you have time (and energy), please, go ahead :)
Best regards,
Patrick