On Tue, Aug 25, 2020 at 1:57 AM Philippe REYNES
<philippe.rey...@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
