Improvements to FIT ciphering

Philippe REYNES
2020-09-10T16:08:14Z

Hi Patrick,

Sorry for the late answer, I was very busy in the beginning of september

>>
>> 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.

I think that we should keep the compatibility with previous code.
If a company/project has started to used iv in the u-boot device tree,
may be they want to continue without changing the format.

Idea 1:
if there is a property "iv-name-hint" in the FIT image, mkimage uses
the old format, and put the iv in the u-boot device tree. Otherwise,
mkimage generate a random iv an put it in the FIT image (recommanded solution).

Idea 2:
We manage four cases according to the properties in the its file:
- property "iv-name-hint" and no flag "iv-in-fit" :
=> the iv is static and added in the u-boot device tree (actual scheme)
- property "iv-name-hint" and flag "iv-in-fit" :
=> the iv is static and added in the FIT image
- no property "iv-name-hint" and no flag "iv-in-fit" :
=> the iv is generated and added to the u-boot device tree
- no property "iv-name-hint" and flag "iv-in-fit" :
=> the iv is generated and added in the FIT image (recomanded scheme)

>> > 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've got a lot of work too, so I can't do all those features.
But I'll try to work on the (random) IV generation and set it in
the FIT 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 :)

I'll do my best to start this work.

> Best regards,
>
> Patrick

Best regards,
Philippe